Users who are baking sensu-agent into their EC2 images for auto-scaling situations or similar, you might find this gist useful.
Real quick summary, you can extend the system service unit provided in the Sensu packages to run an ExecStartPre script that grabs EC2 metadata and will use it to populate sensu-agent configuration environment variables.
In the gist I provide an example of a script that will grab the EC2 instance-id and encode it as part of the sensu-agent entity name.
There are 3 files in play to make this magic happen.
-
the system service config extension file. Instead of editting the vendor provide systemd service unit (which is a very bad practice don’t do it…as it complicates package updating) instead you can extend service configuration by placing files in .d directories in /etc/systemd/system/
For sensu-agent service that directory is /etc/systemd/system/sensu-agent.service.d/ -
The file /etc/default/sensu-agent which the sensu-agent.service will attempt to load envvars from using an optional systemd EnvironmentFile directive. For the magic in the gist to work this file needs to exist and be writable by the sensu user.
-
The update_name.sh script, provided in the gist pulls information from the ec3 metadata api endpoint accessible from inside the instance and then outputs the SENSU_NAME envvar into the /etc/default/sensu-agent file.
Now with all of this in place, when the sensu-agent service starts up, the update_name.sh script will be called first and re-populate the EnvironmentFile systemd tries to read from before start the sensu-agent executable.
You can follow this sort of pattern to do other things as well, like configure the agent namespace to use based on an ec2 tag…for example. But I didn’t want to go too far down the rabbithole with specific business logic.