Another crazy idea: Add ability to pass alert message from custom script

Just the ability to pass the alert message through a scripted function that returns a string back the alert handling process would meet many people's requirements in this space.  The alert message script could be part of the data source same as discovery and collection scripts. At datapoint level would be nice, but even at module level, it would be fine as we could if()...else or switch() case for data points.

You can reference properties (including automatic properties) as tokens, but there is no facility to send arbitrary text (e.g., enum to text lookup).  Unfortunately, since the alert system is simple token substitution and has no programmatic capability, you cannot do any sort of conditional display or substitution.  I have railed on this one virtually since we started with the product, but no joy, not even a hint of a plan to fix alerting.  Our only option has been to use custom integrations with actual templating (like ERB, Template::Toolkit, etc.), but we have found various bugs (like custom email integrations do not pass ACK or SDT notices), which make it more annoying than it needs to be.

4 hours ago, mnagel said:

You can reference properties (including automatic properties) as tokens, but there is no facility to send arbitrary text (e.g., enum to text lookup).  Unfortunately, since the alert system is simple token substitution and has no programmatic capability, you cannot do any sort of conditional display or substitution.  I have railed on this one virtually since we started with the product, but no joy, not even a hint of a plan to fix alerting.  Our only option has been to use custom integrations with actual templating (like ERB, Template::Toolkit, etc.), but we have found various bugs (like custom email integrations do not pass ACK or SDT notices), which make it more annoying than it needs to be.

I just thought of a hack that might work.  In the AD section, generate a bunch of auto properties that look like auto.enum.DSName.DPName.enumValue = enumName (substituting your DS name, DP name and enum value/name pairs, of course).  Then in your alert message you may be able to reference ##AUTO.ENUM.DSNAME.DPNAME.##VALUE####.  I have not tested whether nested token references work, but if they do, this could take away some of the pain.  It might work as well with or without AD to put the definitions into a propertysource.  Complete conjecture at this point, but I will probably whip something up to test as soon as I have some time....

On a test run with some enum properties defined, no joy.  Maybe it can be done via an undocumented method, like braces or something, or more likely there is just no support for constructing tokens this way.

Help, I see a value of ##AUTO.ENUM.FAKEDS.FAKEDP.##VALUE####!  Waaaah!

I did create the enum mappings as a property source (could also just be manually defined at the root, but using a PS is a lot faster for many items).  This will pollute the property list pretty badly when used extensively unless there is an option to keep them hidden in the UI.  Enum support really needs to be added to LogicModules directly.

I haven't thought of a way to do this either. Best I've come up with is for script-based DataSources is to output any text info in script output that DataPoints will ignore but will show up if you use Raw Data > Poll Now and scroll down to scriptOutput section. No where as as good as having the details in the alert message/ticket itself, but better than having to log into the problem system and work it out.

P.S. Calling LM"Lomo", ha! :)

In addition to enum management within modules, the right fix is to replace the simple token single-pass token substitution functionality with an actual templating engine.  See https://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html for a list -- LM needs to pick one and provide some sort of library function to enable management of template fragments.

Another reason why I'd like to pass the alert message through a script first would be for SSL cert alerts. Rather than "SSL cert will expire in n days" I would prefer to have it say "SSL cert will expire on <date>".  With a alert message script we could perform that calculation.

There are gobs of reasons to be able to transform the raw tokens into meaningful rather than vanilla output.  Most times, the output is just shy of "Something is wrong, good luck."  We created a real template system for Nagios that provided very rich conditional information with callbacks to be able to collect additional data from impacted systems and this is one thing I really miss.  LM has no apparent interest in doing anything like that, or at least has been silent in every F/R thread it has been mentioned within.  My best option so far has been to send all tokens to our ticket system (which is a maintenance headache as the integration must list every token explicitly), but then I hit a wall with email integration bugs.  Need to figure out how to put up a middle web API instead...

We still use Nagios also. This one feature is the only reason we do though. If LM every fixes this then we will be 100% LM. 

LM Employee here, from the Sales Engineering team. Hello!

What if, for scripted datasources, we had a token that contained the stdout and another token that contained the stderr of the most recent poll?

You could add to the groovy telling it to call the LM API and put that kind of data as a property on the device/instance. You'd be able to get the entire raw output into a token, and then into an alarm notification.

Agreed that real templating is needed. Personally I'd love to see Jinja2.