Stuart Weenig

Members
  • Content Count

    19
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

3 Neutral

About Stuart Weenig

  • Rank
    Community Whiz Kid
  • Birthday 02/29/1980

Recent Profile Visitors

24 profile views
  1. Ah, I see what you mean. I think there is a FR in to have the changed lines, before lines, and after lines as tokens so they can be included in the alarm message. I'm going to silently nod about the rest (pun intended).
  2. I'll probably be doing a session at LevelUp about running non-groovy/non-powershell scripts, which opens the door to doing python like this: https://www.adampalmer.me/iodigitalsec/2014/11/21/performing-dns-queries-python/ Really, it would be nice if we could build checks like this in the same way that we can build website checks, making them internal and/or external checks.
  3. Totally agreed that LMConfig should be included in base. That one's above my paygrade. Unless I miss your meaning, I think LMConfig does alert on changes: Not sure i'm following you on this. I have used what you would probably call a more-difficult-than-necessary workaround and pulled properties into a datasource as a datapoint. Would still have to be numeric, but could be shoehorned to work. The real question is whether you think of LM as a platform or a product. It can't be both. If you think of it as a product, you're at the mercy of product management to implement the stuff you want, which isn't likely to happen unless you flex sales opportunities. If you think of it as a platform, the only real limitation should be your imagination and ability to put up with getting as close as possible to your goal while perhaps getting there a different way. Don't get me wrong. hostProps.set is desperately needed.
  4. Totally agreed that LMConfig should be included in base. That one's above my paygrade. Unless I miss your meaning, I think LMConfig does alert on changes: Not sure i'm following you on this. I have used what you would probably call a more-difficult-than-necessary workaround and pulled properties into a datasource as a datapoint. Would still have to be numeric, but could be shoehorned to work. The real question is whether you think of LM as a platform or a product. It can't be both. If you think of it as a product, you're at the mercy of product management to implement the stuff you want, which isn't likely to happen unless you flex sales opportunities. If you think of it as a platform, the only real limitation should be your imagination and ability to put up with getting as close as possible to your goal while perhaps getting there a different way.
  5. Yeah, if you don't want to pay for the tool specifically designed to do it, you get workarounds that are usually intensive/clunky. LM can also do it out of the box: LMConfig. That said, what's the pain you're trying to solve? Are you trying to know which devices are on which firmware? Are you trying to catch when someone upgrades a device without you knowing? You could do a property source to get the firmware (if it's not already there) and create auto-populated group(s) on the desired firmware(s) and another where the firmware isn't what you want it to be. For that matter, regarding my previous though around building a datasource and comparing against properties, you could so something similar. Use a property source that runs only once a day to automatically generate ##intended.version##. Then run the DS more frequently comparing current to ##intended.version##. Differences would result in a value that could open an alarm.
  6. +1, would like the ability to add any layer by URL to the KML/KMZ data. Would let you add your own maps as well as weather from myriad sources.
  7. You could set a property for the intended version (as a string), then use groovy to compare the current value to the intended value and return a 0|1. I'm not positive it would work without groovy, but you theoretically could do it without groovy and just look for the presence of a string matching a token. Groovy would def work though.
  8. Yes, that would make what I described above much easier. I mentioned it before, but I'm lobbying internally for there to be baked in methods for doing lm_api gets. That would pave the way for lm_api RW methods like lm_api.setProp("propname","propvalue"). Obviously, this only need to be added for use within the collection script as the discovery script already has this available for instance level properties and property sources has it available for device level properties. That FR gets a +1 from me.
  9. Having them as tokens is different than storing them as properties. It's pretty easy to have active discovery scripts set properties for stdout and stderr, but as you mention, the info tab would get even more cluttered. But if they were available as tokens, they could be used in alarm messages.
  10. Agreed. It's not optimal. However, it is how I would build it were I requested to build it. I was asked to build something similar when a customer wanted to see the same instance's datapoint for the same time of day but one week earlier. The right answer is to use the alert clear interval. I'm working internally to get the product team to build simple LM_API_GET functions into the groovy libraries so that we can just ask for data simply by doing "lm_api_get('device/devices')" or "lm_api_get('alert/alerts')" and just get back the data in a map. Ideally, it would preclude needing to create API tokens (since the collector already has access through the front door) and would also avoid all error handling related to authentication and http status codes.
  11. Something like "repeat [daily|weekly|monthly] every X [days|weeks|months] on the Yth day of the [day|week|month]", yeah? Something like that would address the first case, i think. This might be a new feature, but scheduling SDT on the Xth [weekday] of every month is possible, I think. Pick "repeat" and "monthly (on day of week)" and choose the [first|second|third|fourth|last] [monday|tuesday|wednesday|thursday|friday|saturday|sunday] and pick your time. That addresses the second example you mentioned, right @ChickenTenderer? I don't have an answer regarding this particular enhancement request as is, but I may be speaking at LevelUp about writing automation into change management so that only related CIs go into SDT at the beginning of a change window and come out at the end. I know it doesn't address setting once and forgetting. But, would this be interesting for you as a topic at LevelUp? Also, as always there's a more tedious way of doing what you're looking for. You could, either through the GUI or through the API, create multiple schedules that repeat.
  12. Do you need a whole datasource to do this? What timeframe are you looking at for your threshold window? The alert trigger interval does just what you're looking for, if I understand your problem. It can be set to a maximum of 60 poll cycles. If you're polling at 5 minute intervals, that at least gives you a 5 hour window. Since you're not as interested in immediate alerts, you could up the poll interval which would up that threshold window. Alternatively, you could construct a Groovy based complex datapoint to call the LM API to get the data from the last X polls or X minutes/hours/days ago and store that value. Then you could add a complex datapoint to calculate the average temperature increase as the slope of the line intersecting those two points.
  13. I don't think this kind of functionality is built in today, so it's good to pursue something. So, multiple alerts in LM will be associated with a single ticket in AutoTask. How is that relationship stored? Does the AutoTask ticket contain the LM alarm IDs? Each alarm should have an ##EXTERNALTICKETID## pointing to the AT ticket, but they'd each point to a different one. Do you open a parent ticket in AT and associate the ones LM opens with that parent ticket? And the status of the parent ticket would be dependent on the child tickets? I guess I'm missing how they are associated together because your ASCII pic has what appears to be 6 identical AT ticket numbers.
  14. Yeah, it's not great that we have to resort to it as often as we do. I'm working internally to get a new type of "collector" (i.e. the dropdown when building a datasource where you normally pick SNMP, WMI, BATCHSCRIPT, JDBC, etc.) called LMAPI. The idea would be to make it much easier to just call an LM API resource (without having to setup all the things you have to now) and parse through the data with a simple groovy script. One thing I do with my LM API calls (well for all API calls that aren't associated with a particular device) is that I create a resource in the portal called "[portalname].logicmonitor.com". Among several advantages is the ability to monitor that resource with an auto balanced collector group, meaning that collectors can go offline without suddenly losing the data. Ownership of the keys is also addressed there.