mnagel

Members
  • Content count

    195
  • Joined

  • Last visited

  • Days Won

    38

Community Reputation

54 Excellent

2 Followers

About mnagel

  • Rank
    Community All Star
  • Birthday July 17
  1. Currently, dashboard tokens cannot be used in all widgets (e.g., alert widgets), or they are not overwritten in all widgets if there is support (e.g., table widgets). For these to be useful so a clone results in correct results, all widgets must support tokens. Thanks, Mark
  2. netflow data access via API

    Yep, I concluded they were autoset based on current time, which is typically what I want (verify if we have recent data, generate alerts based on usage, etc.). But sure, if I want to do a sliding analysis over previous windows, those params will be needed.
  3. netflow data access via API

    @mosh Correct -- there is no access to this information via the API and no alerting capability, so if data is not populating for any reason, it is an unpleasant surprise when the data is needed. I run into this all the time, but have been able to create alert rules for key datapoints that let me know when stuff is broken (e.g., I found recently SNMP breaks when you have intermediate firewalls since the code re-uses a single session and sometimes passes data too infrequently to keep the "connection" active). Very nice! I have an initial script now that pulls top flows for netflow-enabled devices, so now I must see what I will do with this. Minimally, detect lack of data and either opsnotes additions for exceptional usage or email alerts (or both). Definitely important to include the size parameter, though. Core of current in-progress script: my $devices = $lmapi->get_all(path => "/device/devices", fields => "id,displayName,enableNetflow"); for my $device (@$devices) { if ($device->{enableNetflow} == JSON::true) { for my $flow ($lmapi->get_all(path => "/device/devices/$device->{id}/flows", size => 10, sort => '-usage', time => '2hour')) { print Dumper($flow); } } }
  4. I just posted some updates to the above repo after some time battling limitations in the underlying ConfigSource code. Unfortunately, I have had very little success getting fixes implemented, and I am loathe to take over full local support of the ConfigSource code until merge/library support is ready, so I implemented workarounds to avoid frequent false checkins within my git sync tool.
  5. netflow data access via API

    @mosh Correct -- there is no access to this information via the API and no alerting capability, so if data is not populating for any reason, it is an unpleasant surprise when the data is needed. I run into this all the time, but have been able to create alert rules for key datapoints that let me know when stuff is broken (e.g., I found recently SNMP breaks when you have intermediate firewalls since the code re-uses a single session and sometimes passes data too infrequently to keep the "connection" active).
  6. Ad-hoc script running

    @Tom LasswellThe ops notes idea was not mine, someone else posted that in this forum recently. I just liked it :). I am not sure I would be OK with using configsources for this based on the cost element. They obviously lend themselves to this very well since very little else records text in the system, but the billing model was designed for its intended purpose. Using it this way would be a major cost increase. I was thinking of using an eventsource, though, which could do the trick without impacting the cost structure.
  7. Ad-hoc script running

    @Mike Suding I just read that post and it sounds hopeful, but I am confused about where this would end up so it is usable? It looks like it would dump into the collector log? I know you and I have talked about this and there have been some discussions recently about leveraging Ops Notes more readily to record information like this. Ideally, the information can be stashed somehow (Ops Notes do seem like a good place if that could be supported within LM more readily), but also easily accessible so the information can be presented in alerts. FWIW, we have a script we developed that get top 5 metrics via WMI alone (usage: /wm/bin/wmitop5 [--top N] [--sort-by {cpu|hnd|thd|mem} [-A authfile] host) -- this is used within our alert templating system via the callback function. This is for our pre-LM legacy tool, and I really miss templating and callbacks :(.
  8. The newer filter capability is appreciated, but would be even better if more complex logic could be applied (AND/OR/NOT for multiple filters) to really focus on specific types of traffic while excluding others. For interfaces, glob matches would be very helpful. For src/dst address match, please allow for prefix matching as well as host matching. Thanks, Mark
  9. Among other reasons, it would be very desirable to have access to Netflow data via the API for at least these reasons: * detect missing netflow data due to misconfiguration or similar; this includes both persistent lack of data and data gaps * detect and alert on unusual traffic in a customized manner Missing data without awareness is probably the single biggest weakness in LM, and with Netflow there is literally nothing that can be done short of visual inspection of every device in the UI. Thanks, Mark
  10. SonicWall ConfigModule

    Glad to hear it is in development! Either way is fine -- I will need to export and import into multiple portals. Thanks, Mark
  11. I would very much like this as well, but LM is pretty much (with a few exceptions) tied to numeric metrics. ARP/MAC/neighbor tracking requires that there be a way to manage textual data and it just isn't baked in. The only way I see this happening with the product as it stands is by using auto properties, but it would be pretty awkward and the UI would not really make it usable (but the data would be present). For now, I am looking at augmenting LM with NeDi at locations where this feature is critical.
  12. The collection interval for the HPE_Network_Config ConfigSource in the repository is 1 day when all others are a more reasonable 1 hour. Since this is not an external parameter, making this change forces divergence from the base ConfigSource, which is especially painful for those since reviewing changes is near impossible given code size and lack of context diff in the change viewer. Please update the module to use a 1 hour collection interval like all others. Fixing those other issues (module parameters, context diff) would be equally welcomed.
  13. SonicWall ConfigModule

    Please add support for SonicWall to LMConfig.
  14. Can we please let the computer be a computer instead of me having to figure out how long it is until a particular date/time each time I want to set STD to expire? Thanks, Mark
  15. In lieu of the more desirable logicmodule inheritance/override capability requested previously, please at least allow definition of parameters like "Collect Every" for configsources without having to lose changes on updates. I found that the HPE configsource had its interval set to one day, which is way too long, especially given pretty much every other CS has it set to one hour. This ability would be helpful for all logicmodules, but especially configsources given they must in practice be managed by LM and updated frequently.