Joe Skup

More AD "discovery schedule" time options dropdown selections

Recommended Posts

I've made a custom script datasource that mainly leverages Active Discovery (if any instances are found in the resultset, it alerts) and so I don't need the data collection interval at all--I just use a Datapump collector and alert on true, when instances are detected.

My datasource would benefit from additional "Discovery schedule" options that are < 15 minutes.

Run AD every 3 minutes, for instance, would be ideal.

Currently, the only dropdown selections are: (1) once per day, (2) once per hour, (3) once per 15 minutes, or (4) when the datasource changes.

I am using once per every 15 minutes, which is the highest resolution option that is currently available for instance discovery.

This work, but because my alerting simply depends on the presence of a resultset in the discovery routine of the datasource, then--at best--I am only "polling" for data/alerts every 15 minutes.

Thank you for considering this request.

- Joseph

Edited by Joe Skup
  • Upvote 1

Share this post


Link to post
Share on other sites

Hi Joe -

Active Discovery wasn't designed for this purpose. Instead you might consider repurposing your AD script as a Data Collection script that reports the number of instances, and use the "delta" alert threshold to notify you when your instance count has changed.

Hope this helps....

Share this post


Link to post
Share on other sites

Hi Matt,

Thanks for the quick response! I understand that AD wasn't designed for this purpose. But I think as the IT ecosphere and needs evolve, monitoring tools should also follow. ;-) Instance-level properties and PropertySources were a huge improvement in this direction, so thank you for supporting this new feature!!

I've thought about reducing my needs to a simple datapoint value. But--in this case--that information is just a little too vague..

Sure, it gets the job done for alerting purposes. But I'd like to be able to know which members show up in the AD resultset, and at the same time also populate some extraneous information about these instances. Ie, the error message that is being displayed for these members..and other information which I am now successfully recording via Instance-level properties. This allows me to export that information as ##alert message tokens## > data placed directly in the JIRA tickets which are created from these alerts using custom HTTP delivery/"integration" webhook.

That is working perfectly and it is more useful information for the engineers on my team who are responding to these JIRA tickets, vs a simple value.

Thanks for the help but my request still holds! And thanks for considering.

- Joseph

Share this post


Link to post
Share on other sites

I agree with Joe, anything that can reduce time to resolution is a good thing.  It's not always possible to reduce a monitoring check down to a single *meaningful* data point.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now