Datasource that outputs text and an error code?
I have a requirement to create datasources that outputs text and an error code.
We have scripts that run on Linux which outputs text (the actual text varies depending what the problem is and may contain other variable text such as a directory name etc.) and an error code.
The error code is easy enough to have as a datapoint, but I am struggling to find a solution for the variable text.
I initially thought of creating instances but they would only be added/deleted at specific intervals.
What is the best way to handle variable text as an output AND values as datapoints with thresholds?
Stephen Cavernelis
Posted 2 years ago·Last reply 2 years ago
15 comments
mmatec01
·2 years agoWhat Mike and Stuart stated, all of the above is true. Sad but true. However....what caught my attention -
And the answer is unequivocally yes! We do it all the time here. Now, it takes little of bit elbow grease but it works great.
And it is all based on the fact you can use ##<DEVICEPROPERTYNAME>## as one of the DataSource Tokens in your alert message. Yeap, it is stated so right there on Tokens Available in LogicModule Alert Messages support website. So then, why not craft your own custom Device Property name that you can pass to the alert message?
In your DataSource you define a customized Alert message for one of the DataPoints and you can pass the value of your device property (ie token) into the Subject and/or Description. Like this;
Notice I use ##MB.SWIFT.AUTOCLIENT.SUMMARY## custom token that I manipulate in my DataSource to update its value with free text. The trick is - you need to update this property BEFORE you output whatever DPs you are collecting in your DataSource.
And how do you do that? Use LM API and /device/devices/{device_id}/properties/{prop_name} endpoint.
Maybe little bit kludgy but again, once you figure out the syntax and workflow in your script it works remarkably well.
LM User
·2 years agoThat's true. Which only goes to show how little effort it would take for logic monitor to actually implement this.
I still say it's not really doable. Possible, but not doable. You could do it for one, but there are quite a few that I would need it on. Building that into 30 plus data sources would be a real pain. Not to mention maintenance.
Stephen Cavernelis
OP2 years agoThanks - this would work, but it would hammer the API with the amount of datasources we would have per device...not to mention all the calls, and we are already doing a frequent amount of calls already.
Although in saying that, would you share the code you use within the datasource to update the property? My groovyscript is still a bit iffy.
mmatec01
·2 years agoI don't think you would hammer the API because you don't run the API call unless the issue is detected. Right? Not every poll needs to employ API call. Only when exception is found that results in raising alert. I actually have a logic inside my script to fetch the property value at the beginning of poll and only update it if the issue is detected and the new property value needs to be output. Hopefully you don't run into too many alerts per device per DataSource per day, if you do, you create Alert fatigue and that's not good either.
As far as the script I use PowerShell as my choice of scripting language and I would have to scrub it in order to publish it. But there are tons of examples out there for both, groovy and PS on how to update API enpoints.
Lastly, I am again acknowledging, it would be nice if this capability was available out of the box. But since it is not, and based on business requirements, I have to do custom solution instead.
Stephen Cavernelis
OP2 years agoI was also actually wondering if it is possible to pass the error message from a variable into the alarm message...in the same way that tokens work. That would solve all my problems!
LM User
·2 years agoThat's been a feature request for years that LM has not fulfilled. Here are the tokens that can be passed into an alert message. First problem is that the output of the script isn't included in the alert (for datasource nor configsource alerts). Once they figure out how to do that, they could easily make a token that you can use to include in the alert body.
Stephen Cavernelis
OP2 years agoI have made so many feature requests myself over the years I am beginning to wonder if I am starting at the beginning again because it has been so long!
LM User
·2 years agoMe too. Lm is starting to make changes to their future request behavior. But nothing has visibly changed yet. But, hopefully they will finally start changing the perspective of the future request system being a black hole.
Mike Moniz
·2 years agoMight 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.
LM User
·2 years agoYep, 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).
Stephen Cavernelis
OP2 years agoThanks 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?
LM User
·2 years agoAll 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).
Stephen Cavernelis
OP2 years agoThat 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!
Mike Moniz
·2 years agoQuite 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.
LM User
·2 years agoA ConfigSource is the way to do this.