Token to include DataSource raw output in email and alert body
We have script DataSources that output useful diagnostics information that help Operations to understand the number valuewhen an alert is generated. We want to include the raw output from a DataSource in the alert and email body. What we need is a##DSRAWOUTPUT## token which contains the complete raw output sent to standard out from a DataSource script. For example, we monitor for processes running under credentials they are no supposed to be running under, and we want to include that info as textual information in the alert/email body.21Views3likes2Comments
value lookups
One of the biggest challenges with LM is the reliance on numbers only in datasources-- the reason is understood, but the result is often messy and many backflips must be done to get a usable result in many cases. I recommend that there be a "lookup" function for numbers that can be associated with datapoints so numeric values can be replaced with text when that is appropriate. An example I just ran into today was after I added the OpenWeatherMap datasource from LM Exchange. It did not include the weather condition, so I added that to the datasource. The values for these range from 200's to 800's indicating "clouds", "rain", etc. You could in theory create a legend for this as is done typically, but the list is too long in practice for 60-odd values (https://openweathermap.org/weather-conditions). If those code-to-string lookups could be defined and referenced, then the value displayed in graphs,in alerts and anywhere else applicable could be displayed as the mapped values, not the original codes. This obviously applies much more widely than this example, but this example shows more clearly how the current method breaks down.2Views3likes0Comments
StatusPage.IO Monitoring
I have built a generic StatusPage.IO datasource to allow for monitoring the status of various services we use. Since so many companies are using StatusPage.io, I figured it's a good idea to have a heads up in the event there is an outage with one of our many service providers. This has worked well as an early warning system for our service desk guys to know about issues before they start getting calls from end users. LogicMonitor actually uses StatusPage, but of course there are many, many others. Attached is a screenshot of the Box.com StatusPage data that we've collected from https://status.box.com. This datasource should be universal to any statuspage.io site. So far it has worked against every site I have tested it against. NYJG6J19Views2likes0Comments
Datasource Display Name token
The datasource tokens##DataSource## and ##INSTANCE## do not allow for enough granularity. For example, if I want to the an alert to state that it is a "Citrix Services"alert, I cannot just use the ##DataSource## token as thiswill also include the Instance name, which may be long and confusing such as "WinCitrixServices-Citrix Independent Management Architecture". A ##DataSourceDisplayName## or similar token would resolve this, the name is stored by LM as dataSourceDisplayName. This token is what I am requesting. With the current setup,##DataSource##equals Datasource.dataSourceName + instance.DisplayName And ##INSTANCE## equals instance.Name Thank You, John9Views2likes2Commentsneed method to always update instance description even if filtered
I am not sure exactly how to describe this other than by example. Wecreated an API-based method a while back to control alerting on interfaces based on the interface description. This arose because LM discovered interfaces that would come and go (e.g., laptop ports), and then would alarm about the port being down. With our change, those ports are labeled with a string that we examine to enable or disable alerting. The fly in the ointment is that if an up and monitored port went down due to some change, our clients think they should be able to change the description to influence behavior. Whichtheyshould. Unfortunately, because LM will not update the instance description due to the AD filter, the down conditionis stuck until either the description is manually changed in LM or until the instance is manually removed in LM. Manual either way, very annoying. My proposal is that there should be a way to update the instance description even if the AD filter triggers. Or a second AD filter for updates to existing instances. I am sure there are gotchas here and perhaps a better way exists. I considered using a propertysource, but I don't think that applies here. The only other option is a fake DS using the API to refresh the descriptions, but then you have to replicate the behavior of many different datasources for interfaces.6Views1like1Comment
Alert Message Token - Tokens for the individual warning, error, and critical thresholds
As I am sitting here, trying to explain to one of our internal partners, for what seems like the umpteenth time,on how to read an alert threshold expression from a ##THRESHOLD## token--it would be great if there were individual message tokens for each of the thresholds. Something like ##WARNINGTHRESHOLD##, ##ERRORTHRESHOLD##, and ##CRITICALTHRESHOLD## that should render the comparison operator and that respective threshold value, example--- Quote >=20971520 This way, I can be more clear as to what this string of numbers actually mean in this type of fashion Quote Warning Threshold: ##DATAPOINT## ##WARNINGTHRESHOLD## Error Threshold: ##DATAPOINT####ERRORTHRESHOLD## Critical Threshold: ##DATAPOINT####CRITICALTHRESHOLD##3Views1like1CommentComplex Datapoints between Datasources
It would be great to create alerts from multiple data-points from multiple data-sources. For example if CPU is above 30% and SQL database lock timeouts is above 1000. I can see many uses cases to be able to alert on different datapoints that relate to other datapoints in other data-sources.8Views1like1Comment
Ad-hoc script running
Often when an alert pops up, I find myself running some very common troubleshooting/helpful tools to quickly gather more info. It would be nice to get that info quickly and easily without having to go to other tools when an alert occurs. For example - right now, when we get a high cpu alert the first thing I do is run pslist -s \\computername (PSTools are so awesome) and psloggedon \\computername to see who's logged in at themoment. I know it's possible to create a datasource to discover all active processes, and retrieve CPU/memory/disk metrics specific to a given process, but processes on a given server might change pretty frequently so you'd have to run active discovery frequently. It just doesn't seem like the best way and most of the time I don't care what's running on the server and only need to know "in the moment." A way to run a script via a button for a given datasource would be a really cool feature. Maybe on the datasource you could add a feature to hold a "gather additional data" or meta-datascript, the script could then be invoked manually onan alert or datasource instance. IE when an alert occurs, you can click on a button in the alert called "gather additional data" or something which would run the script and produce a small box or window with the output. The ability to run periodically (every 15 seconds or 5 minutes, etc) would also be useful. This would also give a NOC the ability to troubleshoot a bit more or provide some additional context around an alert without everyone having to know a bunch of tools or have administrative access to a server.16Views1like7CommentsNative, non-REST API, Groovy helper class to add OpsNotes in a Datasource Definition.
The concept of OpsNotes is growing on me. What would really make it shine would be a Groovy helper class/client that can insert an OpsNote from within a Datasource definition for the device context without resorting to using the REST API. Use Case-- we have a datasource for SQL Servers to count the number of blocking sessions on a per database basis. The DBAs want a way to capture some of the session metadata with this metric. OpsNotes seem like a potentialway of capturing this.2Views1like1CommentWindows Network Adapters DataSource
Code isTXL3W9 This DataSource provides instances for each of the Network adapters, including the following Instance Level Properties: auto.TcpWindowSize auto.MTU auto.MACAddress auto.IPSubnet auto.IPAddress auto.DNSHostName auto.DNSDomain auto.DefaultIPGateway auto.SettingID auto.Description10Views1like0Comments
