Sensu-Go integration mechanisms?

Sensu Go
1

I’d like to clarify the integration mechanisms available for sensu-go.

From reading documentation and Googling around I’ve found the following.

The pipe handler sends data to a handler process via stdin. The documentation doesn’t make this clear, but I think it’s one-shot: that is, it spawns a new process and hands it one event. Is that correct?

There is a socket handler, and again it’s not clear, but I think it opens a separate TCP connection for every event.

You can run external mutator commands, which also accept (JSON) input on stdin. Again it’s unclear whether these are one-shot or persistent subprocesses.

I found a blog post suggesting that you could extend sensu with external filter programs using gRPC (on dzone.com, at /articles/migrating-to-sensu-20-the-good-the-bad-and-the-ugly) … but I can’t find anything in the official documentation about this. Is the blog post wrong?

I also found mention of an extension package called “WizardVan” which opens a persistent socket to graphite or opentsdb. I’m guessing that’s sensu core only, and is replaced by the socket handler in sensu-go.

I note that you can write filter expressions in Javascript which use external libraries, and that potentially might be an extension point.

Now, I have a couple of use cases in mind, and I’m trying to work out the best way to integrate.

  1. Collecting bulk metrics via sensu, and writing them to a time-series database like influxdb.

  2. Collecting bulk metrics and events via sensu, and writing them out to kafka, from where they’d go to other backends. This potentially supercedes (1) as I could do the metric-to-database flow from a kafka reader.

If I want to avoid forking a process for every event, what’s the best way to handle these scenarios today? Would it be to use the socket handler, and write a process which accepts events and then writes them out?

Thanks!

2

Hi @candlerb,

Pipe handlers and mutators all create a new child process every time they are invoked. Same goes for socket handlers; a new connection is created for each invocation.

gRPC extensions are currently not supported in Sensu Go. We found multiple problems with our initial implementation so we decided to remove it from the 2.0 release and go back to the drawing board.

To answer your last question, the socket handler would definitely be the most performant solution compared to a pipe handler since only a TCP connection is required.

Let us know if you still have any question!

3

@candlerb I’m looking to do the same - what did you end up doing?

@palourde is there a timeline on re-enabling the gRPC extensions? This is required for shipping metric data over sensu. A fork for every handler or a tcp connection for every payload will hit limits pretty quickly. Extension also allows adding buffering and connection pooling capabilities, which was possible in sensu classic.