In Sensu Classic it was typical best practice to include specialized plugin configuration in the default Sensu configuration as json files under
/etc/sensu/conf.d/ and have all the configuration for all plugins loaded as part of normal operation.
But in Sensu Go I find now that I prefer to segregate my plugin configuration into distinct plugin specific configuration paths to isolate configuration between plugins and teams. This helps isolate human errors in configuration syntax and provides a mechanism by which I can let different teams manage their own configuration…by giving them separate configuration directories in which to hold needed plugin configuration.
Let’s take the existing opsgenie sensu plugin as an example.
It provides a handler that expect to find specalized opsgenie json configuration that includes information like the api access key. By default this handler, like all handlers based on the sensu-plugin gem, will look in /etc/sensu/conf.d/ for configuration. But I don’t want the default behavior. I want to explicitly use:
teamA corresponds to the specific Sensu Go namespace i want to run the handler under.
What I can do in the Sensu Go handler is set the environment variable:
Now my opsgenie handler is reading ONLY the configuration from that single file. A file only members of teamA uses for their workflow. For teamB, I’d have a similar subdirectory where teamB can have its opsgenie configuration defined.
The SENSU_CONFIG_FILES envvar has always been available to support alternative locations for configuration as part of Sensu Classic server and client operation. It supports a list of files using the ‘:’ path separator. With Sensu Go, its even more powerful because individual checks, handlers, and mutators can set that envvar explicitly for much more granular control over what configuration is uploaded as part of plugin operation. It’s very flexible and great for workflows that give teams end-to-end control over their monitoring configuration.