Steve Francis

LogicMonitor Staff
  • Content count

    267
  • Joined

  • Last visited

Community Reputation

20 Excellent

3 Followers

About Steve Francis

  • Rank
    Community All Star
  1. custom speed for interfaces

    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. custom speed for interfaces

    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. Interface utilization percentages

    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. custom speed for interfaces

    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 its a bit more descriptive. The bandwidth properties are still ActualSpeed and ActualSpeedUpstream. Let me know if you have any issues.
  6. Dependencies or Parent/Child Relationships

    Published, locator 24KKNG Updated the documentation article above. Please let me know if there are any other issues.
  7. Dependencies or Parent/Child Relationships

    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. Dependencies or Parent/Child Relationships

    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. Dependencies or Parent/Child Relationships

    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. custom speed for interfaces

    Sorry - ActualSpeed and ActualSpeedUpstream should be set in Mbps. Should've documented that.
  11. Dependencies or Parent/Child Relationships

    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. Dependencies or Parent/Child Relationships

    Yes - it puts the whole device into SDT - so all interfaces, etc.
  13. Dependencies or Parent/Child Relationships

    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. Dependencies or Parent/Child Relationships

    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. Dependencies or Parent/Child Relationships

    Huh - thought I put that through the review already... Let me fix that today..