Create abstraction for Sensu Checks

[fguimond]

The first version of this repository contains an abstraction for the common Sensu handler logic. The abstraction is responsible to

• Read and validate the Sensu event from stdin
• Read the arguments from the command line, environment variable or Sensu event
• Execute the user provided validation logic
• Execute the user provided handler logic

We want to implement a similar pattern for Sensu checks. While handlers and checks are similar there are some differences (please correct me if I'm wrong).

• Handlers read a Sensu Event from stdin while Checks don't
• Handlers always read a Sensu Event from stdiin while checks optionally read one
• Handlers can read input values from the event, while checks can't since they don't read an event
• Checks write the return the result data to stdout or stderr, handlers don't
• Checks exit status code indicates the state... 0=OK, 1=WARNING, 2=CRITICAL, other=UNKNOWN

You can look at the gohandler.go file, as some code can probably be reused. What I had in mind is to invoke the checks the same way the handlers are with some subtle differences.

1. See the way options are defined at https://github.com/sensu-skunkworks/sensu-aws-ec2-deregistration-handler/blob/sensu-auth/main.go#L31. Very similar approach but no need to have the Path property since it defines where to look in the Sensu Event.
2. Create a new sensu.NewGoCheck function instead of sensu.NewGoHandler https://github.com/sensu-skunkworks/sensu-aws-ec2-deregistration-handler/blob/sensu-auth/main.go#L31
3. The sensu.NewGoCheck function should have an extra readSensuEvent argument which would tell whether or not the Sensu Check expects an event to be sent through stdin
4. The execution method needs to have a way to return the exit status code, result and error. The result and error should automatically be written to stdout and stderr respectively. The exit status code should be used automatically when the check process exits. Signature might be something like this: func(event *types.Event) (int, string, error) - (exit status code, result, error) where event will be nil if the check doesn't read from stdin

Unit tests are required.

Once this is done the EC2 plugin can be converted to use the abstraction.

[sreejita-biswas]

@fguimond @calebhailey I don't have access to this repository https://github.com/sensu-skunkworks/sensu-aws-ec2-deregistration-handler. Please provide me the access.

[fguimond]

@sreejita-biswas - You can use this gist. Should be the same line numbers. https://gist.github.com/fguimond/c4bfad1b6b6fe7165cdb4c028f4ecb73

[calebhailey]

@sreejita-biswas invite sent; see: https://github.com/sensu-skunkworks/sensu-aws-ec2-deregistration-handler/invitations

[calebhailey]

@fguimond please note the following comments/responses to your issue description:

1. "Handlers read a Sensu Event from stdin while Checks don't"

   Checks do not read stdin by default, but this is supported via the stdin check definition attribute; see https://docs.sensu.io/sensu-go/5.5/reference/checks/#spec-attributes (under "stdin"). Please note the following comments from the documentation:

   If the Sensu agent writes JSON serialized Sensu entity and check data to the command process’ STDIN. The command must expect the JSON data via STDIN, read it, and close STDIN. This attribute cannot be used with existing Sensu check plugins, nor Nagios plugins etc, as Sensu agent will wait indefinitely for the check process to read and close STDIN.

2. "Handlers can read input values from the event, while checks can't since they don't read an event"

   I'm not sure if I understand this assertion. Checks can read input values from the request payload if stdin is enabled, however, only the check configuration is available at this time (e.g. the configured check definition attributes).

3. "Checks write the return the result data to stdout or stderr, handlers don't"

   Handlers can and do generate standard output (stdout), and Sensu does consume this output, but handler stdout is currently only visible in the sensu-backend logs, and only when --log-level is set to debug (we don't currently display this anywhere in the web ui, however this will change soon).

4. "Checks exit status code indicates the state... 0=OK, 1=WARNING, 2=CRITICAL, other=UNKNOWN"

   Sensu also validates handler exit status codes to determine handler success; if a handler exits with a "non-zero" exit status code, Sensu logs an error. As above, this is currently only observable in the sensu-backend logs and only when --log-level is set to debug.

I hope this helps! Let me know if you have any questions.

[fguimond]

Thank you for the clarifications @calebhailey this is very helpful.

1. "If the Sensu agent writes JSON serialized Sensu entity and check data to the command process’ STDIN"

Would you happen to have a sample of such a structure? The Event consumed by the handler does contain a Check and an Entity but it also has Timestamp and Metrics. Is there a different data structure used for checks?

Thank you!

[fguimond]

Sensu Go Plugin Library