pulling text from db to add to error message

See also: 

Not wanting to wait, we came up with a less-optimal method where we use a custom integration with every possible token (hard to keep that up to date as things change), which triggers a processor via Template::Toolkit (anything similar like Jinja2, etc. would also work).  The output of this is expected to be MarkDown, and final result is transformed into HTML into our ticket system (RT).   Rickety, but works well enough for now.  Having access to the API, we can pull additional detail into the final result remotely, but it would be far better to have a template tool within LM so all alert targets can benefit, not just one integration.

Another way could be for LogicMonitor to add a simple database of key/value pairs that customers can maintain via the UI and automatically via exernal process using the REST API. The keys in should be usable as tokens for alerts. 

Sure, but without templating that supports conditional output, you cannot have meaningful alerts in many cases.  Being able to analyze the results and provide an alert that applies to the specific problem (and associated client-specific instructions and related information) is valuable.  That said, yes -- adding a key/value DB would be very nice.  I think I asked for something like redis or equivalent awhile back, but I was thinking that would be more for storing non-metric information by logicmodules for extraction in alerts.  I saw a recent FR noting the same could be done with ops notes (if manipulating ops notes was made more accessible), which is intriguing.  How would the proposed K/V database differ from the existing property system?

The properties UI doesn't lend itself well to editing and maintaining multi-line text.  Yes, the ability to control when a token interpolated would be good too; even if it was a simple regex based method to start with.

Agreed on the properties editor.  We tried to use that to hold a very long value related to Windows file permissions monitoring and it was extremely awkward.  And there is an undocumented maximum value length (not sure, I just recall being told there was a limit).  There are various ways to skin this cat, but the truth is a templating system for alerts within LM, including a way to manage the library of template components, would solve many problems.  As I noted, we pushed that into an integration and only use properties to reference template components (e.g., support/att_avpn, contact/clientteam1, etc.).  Because the integration feeds into a ticket system, we sometimes end up with stranded tickets because LM does not always send recovery alerts -- working on that one with our CSM separately.

Another point about the properties editor -- I filed a different FR requesting a more expansive UI element mechanism that could be specified for datasources that could dovetail with this.  The problem I often run into is that special properties are undocumented -- you literally have to open the datasource and sometimes browse code to figure out what is allowed.  If the UI element thing happens, I would hope one of the options would include a multiline text entry box...

I have the same need as the original request by KSTEVENS.   However, our OS is Centos/Linux and our DB is PostgreSQL.  Has anyone found a solution?   So far we are able to use a custom datasource that performs an ErrorCount via DB query, and then the logic is configured to alert(Warning Level) on any delta greater or equal to 1 from the last poll. It is set to poll every minute which is the most frequent we can poll.

What I would love to be able to do is run a Groovy script on alerts between the Alert Rules and Escalation stages of alert processing so that the alert message can be enriched or additional custom logic can be used to determine if the alert should proceed to Escalation stage (the script could return a true or false to control whether the alert processing continues normally or is aborted). 

Example use case, alert is triggered > alert rule is matched > script checks CMDB and change management calendar, returns false if CI is in change or true to continue to Escalation.

5 hours ago, Mosh said:

What I would love to be able to do is run a Groovy script on alerts between the Alert Rules and Escalation stages of alert processing so that the alert message can be enriched or additional custom logic can be used to determine if the alert should proceed to Escalation stage (the script could return a true or false to control whether the alert processing continues normally or is aborted). 

Example use case, alert is triggered > alert rule is matched > script checks CMDB and change management calendar, returns false if CI is in change or true to continue to Escalation.

In the previous monitoring tool we deployed for our clients (Nagios primarily), we developed a notification script that used a Perl Template::Toolkit handler to generate the output (this could be any of a number of template systems like jinja2, etc., we are just old-school Perl geeks).  One of the features in our system is a callback function that allows running a limited set of scripts to gather more information, just like an admin would if they were involved at the time the alert triggered.  Since the output from the callback was available to the template code, we could also create conditional output based on the callback output.  For example, if a callback produced a list of the top 5 processes from a Windows box, we would generally tack that onto the notification as additional information.  But the template could also check if the output contained a particular process, at which point it could add "Also, since XXX is high, please refer to YYY for more information on how to troubleshoot".  We have had that in place for like 10 years and it has been extremely frustrating to be restricted to unconditional token substitution.

On 8/16/2018 at 9:14 AM, mnagel said:

In the previous monitoring tool we deployed for our clients (Nagios primarily), we developed a notification script that used a Perl Template::Toolkit handler to generate the output (this could be any of a number of template systems like jinja2, etc., we are just old-school Perl geeks).  One of the features in our system is a callback function that allows running a limited set of scripts to gather more information, just like an admin would if they were involved at the time the alert triggered.  Since the output from the callback was available to the template code, we could also create conditional output based on the callback output.  For example, if a callback produced a list of the top 5 processes from a Windows box, we would generally tack that onto the notification as additional information.  But the template could also check if the output contained a particular process, at which point it could add "Also, since XXX is high, please refer to YYY for more information on how to troubleshoot".  We have had that in place for like 10 years and it has been extremely frustrating to be restricted to unconditional token substitution.

So I found out today that you can't even generally insert properties into the existing alerts.  If you want an email alert that you can reply to ACK or SDT, you cannot use a custom integration.  If you do not use a custom integration and want to append something to alerts, you would have to edit EVERY datapoint template.  I was actually advised to use the API to append my custom token expansion into every datapoint template, which is not going to happen, for many many reasons.  This is a huge issue that needs immediate attention -- we have to be able to customize what appears in alerts per client.  The closest I have is custom integration since MESSAGE is the result of whatever template is filled out.  If the custom email integration could act the same as regular email, then that would be a feasible solution.