Neophyte
ProfessorMight not apply for this situation, but you can just output some text/error messages in the DataSource and LM will normally just ignore it. But it will show when you use the Poll Now button. So when a check fails, along with some error code in a DataPoint, I also output detailed messages they can indirectly view. I then have the person reviewing the alert use the Poll Now button to get further information. Only really helps if the alert is still active but can save some time in triage. But that might be less useful if the primary purpose is to report on errors though.
LegendYep, i use this all the time. Great suggestion Mike_Moniz
Also, if the DS is scripted, you can use the script to evaluate the text to determine if there is a problem (regex). If it's not scripted, you can use s groovy scripted datapoint, but that's making things a bit complicated. All this does for you is check the text for a problem and output a 0 or 1 based on the text content. Combined with Mike's method above, you should be able to see everything through a DataSource (provided your engineers have poll now permissions, mine don't).
NeophyteThanks Stuart, but for me it is not about evaluating the text as such. There is some code that is run and the output will be text - but it will not be a static text string or from a set of static text strings. I thought that initially the error code would be enough, but it seems not.
Hopefully I am making some sense!
Can you perhaps provide an example of a configsource that can output text and a datapoint value?
LegendAll configsources output the text. The "configcheck" is the "datapoint", which simply evaluates to true or not. The output of your script is the text that LM calls the "config file" and the config check looks at the blob of text and evaluates to see if it has what you want in it (or has what you don't want).
NeophyteThat sounds like a great idea - but it's not really practical in my example...support would need to log in to the tool and still do an action after getting the incident, instead of just working off the incident. Thanks anyway!
ProfessorQuite true. I generally suggest they look at LM for any alerts anyway since it can provide a lot of context and broader picture, especially when there multiple alerts across multiple tickets.
