Forum Discussion
I'm looking at the same problem here. I have a SQL query I am running, and if there is a result I want the output to be included in the alert. The output consists of multiple strings.
I have currently done this via a configsource module, but it requires the user to login to LM to actually see the output.
If I use LM logs, and the issue occurs again at each collection (which is currently at 60 mins) it would mean another alert would be raised. (Unless someone has any ideas on how to NOT raise the same alert in LM logs? ie. only raise once)
If I use a datasource module, I could potentially have the instance name contain the details (like the SQL troubleshooter), but it is quite a bit of information in the output.
If I use an eventsource module, that would also probably work fine, but I read in the LM documentation that eventsources will be deprecated in favour of LM logs, and the last thing I want to do is create an eventsource that will need to be rewritten as another module at some point.
Anyone have any suggestions?
Thanks
- Mike_Moniz2 months ago
Professor
Do you have a link to where it says EventSources will be deprecated? I haven't seen that (but I'm not on top of all the news). Especially since LM Logs is a paid add-on and therefor removing EventSources would then be removing base functionality.
- Dave_Lee2 months ago
Advisor
I've taken a similar approach to this with a few things where I've wanted to put some meaningful text into the alert itself. Rather than using the instance description, I tend to put the extra information into instance properties though
For example, I have a data source that checks if WMI is working properly on Windows Servers. If it can connect over WMI it runs a few checks to ensure that we have the necessary permissions (checks it can receive OS information, checks it can query services state, etc).
This runs in Active Discovery, rather than data collection, just so I can write text info out to instance properties. So, if all is good, then it writes the instance property wmicheck.statusCode=0. If not, then it writes wmicheck.statusCode=1 and wmicheck.statusCodeReason=<what the script found was the problem>. The Active Discovery runs every 24 hours.
Then I have the collection script just read the value of the "statusCode" instance prop and alerts if it is 1, but I can include ##auto.wmicheck.statusCode## in the alert message to get the details of where the problem is.
- Stephen_C2 months ago
Neophyte
Hi Dave,
The problem I have with that is that active discovery only runs in 3 intervals (15mins, 1 hour, 1 day), And I don't want to risk the instance property having outdated information.
It would be so much more useful if we could just write to a property directly from a data collection, without going the round-about way of using the API. Or even better just be able to pass the text as a token to the alert message.
- Dave_Lee2 months ago
Advisor
I failed to mention, we also populate an auto.wmicheck.lastChecked instance that records when it last ran. It doesn't make the AD collection intervals any more flexible, but at least gives a user an idea how out of date the information is.
Agreed, it would be great if we could somehow pass some custom text with an alert value.