Populate Sensu Agent Name from EC2 metadata

exec_start_pre.conf

# Extend the sensu-agent service init to call the update_name.sh  script
# place this file in: /etc/systemd/system/sensu-agent.service.d


# With systemd you don't have to edit the vendor provided service init script.
# local admins can extend/override vendor settings by using correctly named extension directory structures
# Ex: /etc/systemd/system/sensu-agent.service.d/
# This .d directory will be parsed for systemd directives to extend/override the vendor supplied sensu-agent.service

# For now all we want to do is add an ExecStartPre directive, 
# to populate the sensu-agent EnvironmentFile the vendor provided service unit knows how to read in.
# Note: the /etc/default/sensu-agent file must be writable by the sensu user.

[Service]
ExecStartPre=/etc/sensu/scripts/update_name.sh

update_name.sh

#!/bin/bash
#
#  Simple example of how to use the EC2 metadata to populate sensu-agent environment variables
#  Consider placing this in /etc/sensu/scripts/

# Let's make sure the Sensu Agent name encodes the ec2 instance-id
SENSU_NAME=ec2_$(curl -sS http://169.254.169.254/latest/meta-data/instance-id)

# Lets output the envvars we want sensu-agent to use into one of the supported file locations
# NOTE: Must make sure /etc/default/sensu-agent is writable by the sensu user
cat << EOF > /etc/default/sensu-agent
SENSU_NAME=${SENSU_NAME}
EOF

I use a similar approach, however it only requires 1 file:

[Service]
PermissionsStartOnly=true
ExecStartPre=/usr/bin/bash -c "/usr/bin/systemctl set-environment SENSU_NAME=$(curl -sS http://169.254.169.254/latest/meta-data/instance-id)"

yeah... i left it more abstracted as you can do more configs than just the name... like set the subscriptions and namespace from ec2 tags..

Makes total sense! More ways of accomplishing what we need to do!

Yep... sort of thinking about.. what are the required things we need to configure as part of an agent and can we get that all from the ec2 metadata via ec2 tag? If you can do that, then you can bake in agent into your custom AMIs for your org and rely on metadata to ensure agents are configured correctly.

So name, namespace, subscriptions at a minimum... then potentially labels and annotations.

Those are the ones we care about, possibly backend based on your environment and then deregistration: and the handler for it.

I should definitely look into the set-environment verb as an alternative to using the /etc/default-sensu-agent to hold envvar state.
That is probably a cleaner solution for sure. But trying to do everythng inline instead of a script on disk feels a little...dirty...once it gets to the point where i'm setting 6 or 7 things.

Leaving behind a breadcrumb for the next time I don't read the instructions carefully enough:

"Note: the /etc/default/sensu-agent file must be writable by the sensu user."

To future me: don't forget to create the /etc/default/sensu-agent file, and ensure it is owned by the sensu user! 🤦‍♂️

$ sudo touch /etc/default/sensu-agent && sudo chown sensu:sensu /etc/default/sensu-agent

Derpity derpity derp...