Gateway event triggered by specific log outputs?

Ignition
1

Twice now in 5+ years I've bumped into circumstances where something is failing in some Java code that I have no visibility into, for some event that I have minimal controls over, but I want to be able to have a script run in response to.

In both cases, I can see the event in the Ignition logs, but have no control of the event that triggered it. What I think I need is a gateway event that can be triggered by a log event. The gateway event should be setup to look for messages from a specific logger name and optionally match the log message against a regex or search string. When the event triggers, a script should be run with the log event as a parameter.

I opened a suggestion on the feedback board. If you think this might be useful to you as well, please give it a vote. :+1:

If it matters, the two cases I bumped into were:

  • Twilio failures when a recipient's phone number is no longer valid or they have replied "STOP" to Twilio and we need to know that they are no longer receiving alarms
  • Sparkplug/MQTT Engine failures when someone out in the field has adjusted their tags on the edge to have the same name except for a case-only name change, at which point MQTT Engine just chokes on that tag and it stops working altogether
2

You'll probably have to use the SDK to implement a log consumer that generate events. Probably very difficult until v8.3 lets you make a custom event stream.

1 Like
3

I was kinda hoping there would be enough other people who could use something similar to convince IA to do it. :slight_smile:

4

Kinda tricky to avoid errors in your event script feeding back into your log event generator. Kaboom!

5

Yeah, I totally get that. Very easy to accidentally make infinite recursion with this feature. But that doesn't mean it shouldn't exist.

It should probably have some sort of cool-down or lockout if over-triggered, though.

6

Hmm. I see the utility, but this does seem like the wrong solution to the problem...

But, to Phil's point, I could definitely see us adding an opt-in event stream log capture facility. I wouldn't expect any higher level abstraction like a new gateway event script type, though - event streams are the new standard throughout the platform for this pattern.

7

Too bad we pulled the implementation out of platform and turned it into an add-on module :cry: :cry: :cry:

8

Oh, right :upside_down_face: