event handlers

2 hours ago, NBM said:

I'm cross-posting this as I saw the link to this thread in the other post I made, so apologies for the duplicate:

Hello,

We're currently looking to evaluate LogicMonitor as a potential replacement for Microsoft System Center Operations Manager (SCOM) and prior to SCOM being our enterprise monitoring tool we had IBM Tivoli Monitoring (ITM) in place within our organization.

So we come from well over 10+ years of being able to take corrective actions without the tools themselves in response to various alerts that are raised and based on our initial demo with the LogicMonitor team, we understand that's not a feature of the product as they don't want to be in config management business which I understand.

However, we can't be the only organization that has this issue so I'm curious how others have worked around this that would be willing to share their solutions. 

Here are some simple things we do today:

1. 1. Windows Service Restarts (we only alert in most cases if the corrective restart action fails)
2. 2. Linux Process Counts (we'll attempt to restart the process or execute some type of other scripted action)
3. 3. IIS Application Pool failures (we'll attempt using builtin Windows functionality to recycle and AppPool)

Appreciate the responses, thanks!

Alert processing happens outside the detection point (in "the cloud") -- there need to be triggers to an event handler that operate in the collector context.  One possibility would be to create datasources that don't actually collect data, but do the check and repair operation, with a datapoint as a side effect.  It would be easier if datasource code could cross-reference other datasource/instance datapoints without having to replicate the same API code into each (e.g., code library support), but it is feasible.  Triggers would be much cleaner.