Steve Francis

LogicMonitor Staff
  • Content Count

    267
  • Joined

  • Last visited

Everything posted by Steve Francis

  1. So if I understand you correctly - you could get the reported interface speed by adding a complex datapoint (RawSpeed, say) with this value: if(lt(##auto.BasicSpeed##,4294967295),##auto.BasicSpeed##/1000000,##auto.Speed##) Is that what you mean?
  2. It's in core with v102 release. (So next week) I renamed the StatusRaw datapoint to OperStatus. (Good idea, thanks.) This datasources uses groovy to do the Admin/operational state alerting, as it also does regex matching, so I didn't run into the lack of neq - an oddly never have before. I'll open a ticket to get that added..
  3. The updated interfaces datasource - which you can get from the Registry via locator code RMP2DL - has a graph showing utilization as a percentage. (It will be in the core repository next release.)
  4. Well, you can't directly exceed them. Our web checks protect themselves from being in an infinite loop, redirecting in a circle, by imposing this maximum of 10. Which in real life is more than websites should normally subject their users to. (It's not a great user experience in terms of latency, etc to be redirected a bunch of times.) So the best solution would be to remove some of the redirects (why go from A to B to C to D, instead of just A to D?) If there are architectural reasons you can't do so, you could start your LM web check further down the redirect chain.
  5. Hey - I took the liberty at looking at the logs for your account -looks like you didn't actually import the new datasource version. (Which our UI makes easy to do... something we're fixing.) You want to make sure you import from the Exchange, not the repository, then give it the locator code RMP2DL This is a slightly updated version of the one I mention above - a few efficiency improvements in the code. The only substantive change is the filter property to filter in interfaces by description has been changed to the property interface.description.alert_enable as
  6. Published, locator 24KKNG Updated the documentation article above. Please let me know if there are any other issues.
  7. Yep - I made a mistake in the device filtering, so it was only finding dependents that had the depends_on set directly on the device, not those that were inheriting it via groups (although I was sure I tested that...) Anyway, I've found the error, and fixed it, and will publish tomorrow after a bit more testing. Sorry about that..
  8. OK, I can extend this to support Services... I've got a few other things I'm in the middle of, so it may be a week or two...
  9. AS it's currently written, it doesn't support Services as either the dependent or primary. (It could be made to support that, with some extra scripting. Let me know if that's important.) And yes, you can set the depends_on property at the group level (and then override on devices, if needed.)
  10. Sorry - ActualSpeed and ActualSpeedUpstream should be set in Mbps. Should've documented that.
  11. So this set of datasources doesn't directly know anything about connections. It requires the user to set the depends_on property. If A is in Alert, and B depends on A (via the property), then B and all its interfaces will be in SDT.
  12. Yes - it puts the whole device into SDT - so all interfaces, etc.
  13. That looks like you are using the old locator code (as the new one is not v1.0.0). Can you try with locator JZ62NH? That should be what the above article shows -maybe there was some caching....
  14. Fixed -these are now importable. (Note that the locators changed - I edited the article above to the current ones. There was a slight improvement to using the globally unique displayname as the host reference in the depends_on property - the above article also reflects that...)
  15. Huh - thought I put that through the review already... Let me fix that today..
  16. If you have an iframe that the video clip can be referenced in, you can put it in an HTML widget on a dashboard.
  17. Note: as of v100, Instance level properties now work as tokens in alert messages. Development tells me they did prior to v.100 - which I thought I tested, and found the didn't - but in any case they definitely work in v.100.
  18. Agree - this has taken way too long to get into the product officially. (It is in the works, but as Mike said, is at least 6 months away. We're working on improving our processes and efficiencies, too...) In the interim, these two datasources available from the registry with these locators can achieve dependencies on a device level. Feedback appreciated! SDT_Dependent_Devices: locator 24KKNG SDT_Assign_Primary_For_Dependencies: locator NFTHXG Creating Device Dependencies With these two datasources, LogicMonitor supports device dependencies in order to help reduce ale
  19. I remember the days when 100 broadcast packets per second could hang a 486... Nowadays my inclination would be to just set a warning on "> 1000". Excess non-unicast is still bad, but unlikely to be traffic impacting bad - and if it is, discards and other thresholds should trigger. So that would allow investigation in the case of a legitimately problematic non-unicast level, but not generate alerts for situations that are not impacting things, and would otherwise be considered noise alerts. And we should add a "top 25" graph for inbound non-unicast traffic on all interfaces to ou
  20. I opened a ticket to allow ILPs to be used as tokens in alert messages - thanks for that. What was wrong with removing the operStatus filter? We're actually thinking of removing that in another update, once we can group interfaces automatically based on status (so you wouldn't have to look in the down ones... What non-unicast threshold would you want? As a percent of unicast, or ...?
  21. Are you still seeing this? What version of collector? We haven't heard this elsewhere.... (there is a small delay - on the order of minutes - for such configuration changes to be pushed down to the collectors...)
  22. Yeah, as Tom suggests, (and you, in your opening post), dual NIC or VLAN collectors is probably the solution. Should work fine - LogicMonitor collectors just use the host's routing table, so no issue there.
  23. There is no way to apply regex expressions to instances that don't exist, as you note. I ran into a similar problem recently, which I solved by adding in a groovy complex datapoint that takes the instance name or description or what-have-you, tests it against a regular expression that is set as a property (so you can set it at group levels, and have it be inherited), and if it matches, evaluates the alert as normal, and if it doesn't, returns a value that makes the alert not trigger. Like in this case, testing agains an interface description, and using a property interface_descriptio
  24. With the last release, we finally added the ability to manually set instance level properties through the UI, which lets us solve this issue. There is a new version of the snmp64_If- datasource - this is available in the registry, but not yet in core. Improvements in this datasource: Now we support setting instance level properties through the UI (from the Info Tab for any instance via the Manage icon on the custom properties table), we can solve setting custom speed for interfaces. Setting an instance level property ActualSpeed and/or ActualSpeedUpstream (if different fro
  25. This has been available for while - we apparently neglected to update this thread, though, sorry! https://www.logicmonitor.com/support/devices/device-datasources-instances/instance-level-properties-2/