[SENSU/Server] : Alter event data before writing to Redis.

[chiriaev]

Gents, Hi. As far as I understand, it is not possible to alter or mutate client event data, the “[:check][:output]” key for example, before writing it to Redis. All the additional “handling”, handlers, mutators and extensions happen right after.

If confirmed, I would like to suggest an enhancement based on the following use-case:

…
Roughly:

To implement a centrally managed alert dictionary, monitoring clients will send a unique ID as part of the “:output” key and a name space ID in another, “:alert_id”, key for example.

The server will be configured to execute a handler or extension to re-write the output text. (i.e.: querying a DB, etc…) This will happen before the event data is written to Redis and inherited by all subsequent processors. (i.e.: handlers, etc…) Ideally, a filter can be defined to discard all events that don’t have certain fields in the event core data.
…

Thanks in advance, Regards, Andrei

[chiriaev]

Guys, Hi. I know you are busy. First thoughts, to start with. Regards, Andrei

[portertech]

@ems-dev I am having a hard time understanding the use-case. I do not see what is gained by mutating event data prior to storing it in Redis. Everything that queries Redis expects a certain structure, data types, and assumes correctness (what the producer published). Sensu's main concern is current state, anything historical is passed off to a service well suited for the task.

[nstielau]

@ems-dev say your message STDOUT is a JSON blob with all the rich data you
need. What's wrong with that? (I am assuming that non-human-readable
ugliness in the dashboard and other alerts is the only issue there).

On Thu, Nov 21, 2013 at 2:13 PM, Sean Porter notifications@github.comwrote:

@ems-dev https://github.com/ems-dev I am having a hard time
understanding the use-case. I do not see what is gained by mutating event
data prior to storing it in Redis. Everything that queries Redis expects a
certain structure, data types, and assumes correctness (what the producer
published). Sensu's main concern is current state, anything historical is
passed off to a service well suited for the task.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/665#issuecomment-29029927
.

☮
Nick Stielau
206-245-7991

[chiriaev]

Guys, thanks. Let me turn it differently. I have several standalone checks that define “[:check][:alert_id => “andrei”] “ in their JSON. Now, the check returns a “critical”. The event is forwarded to the server. The server can see the custom field, named “alert_id”.

What I want is to pre-process the value of the “[:check][:output]” before it gets written to Redis. I want, for example, to pre-pend the “alert_id” value to the “[:check][:output]”.

Can expand on the use-case, of course.

Regards, Andrei

[nstielau]

The 'alert_id' should be accessible in the event data. A filter can be
defined to filter out events that do not have an alert id.

It does mean that you'd have to update the any UIs, and handlers to manage
the structure data according to your desired 'ops logic'.

We do something similar with a 'playbook' (see attached).

I see the use-case, I think, which is to provide a single location to make
a human-readable string representation of the event, rather than in each
UI/handler.

Makes sense, but I think rewriting the data before redis could be dangerous.

On Thu, Nov 21, 2013 at 3:00 PM, ems-dev notifications@github.com wrote:

Guys, thanks. Let me turn it differently. I have several standalone checks
that define “[:check][:alert_id => “andrei”] “ in their JSON. Now, the
check returns a “critical”. The event is forwarded to the server. The
server can see the custom field, named “alert_id”.

What I want is to pre-process the value of the “[:check][:output]” before
it gets written to Redis. I want, for example, to pre-pend the “alert_id”
value to the “[:check][:output]”.

Can expand on the use-case, of course.

Regards, Andrei

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/665#issuecomment-29033411
.

☮
Nick Stielau
206-245-7991

[chiriaev]

Thanks for that. Good to be on the same page. Is that something that can still be considered? (i.e.: when you saying that it would have to be taken up very carefully)

Regards, Andrei

[portertech]

Lets make the Sensu Dashboard more intelligent, we should maintain event data integrity, and the Dashboard should be able to detect JSON strings and links, and markup accordingly.

@ems-dev I'm going to close this issues, considering it a won't fix, but I would love to see a Sensu Dashboard issue to make this happen!