Beacons at VMware Aria Automation Config (AKA vRealize Automation Saltstack Config) is a key enabler to creating a self-healing, healthy and stable environment. It allows you to continually monitor events on the minions, like logins, disks and processes usage, services, and much more, once a defined activity occurs the beacon will notify the system, and then you can trigger a Reactor, which is the piece that does the remediation/configuration, but Reactor is a topic for another post, today let's focus on the beacon itself.
There are a few methods to enable beacons, through the use of config files, Pillars, or with the use of state modules.
Here's come the first challenge, if you look at tutorials and blogs out there, you will only find examples of config file manipulation, local to the minions or through the use of the file state module.
Second challenge; complexity and scalability:
IMHO, using the file state module is a little complex and requires some extra attention as the solution scales;
Let's take an example of 3 behaviors you wanna monitor; A, B, and C (for this example it does not matter what those beacons are).
To get it to work on every possible combination you will need to create 7 different config files to distribute for your minions depending on the combination of activities you want them to monitor.
file 1: only a
file 2: only b
file 3: only c
file 4: a+b
file 5: a+c
file 6: b+c
file 7: a+b+c
To summarize, to monitor only 3 behaviors you will need 7 config files, you can imagine how complex it would be if you have dozens of individual behaviors to monitor. Plus, when you are manipulating the config file you need to restart the salt-minion service for the new beacon to take effect (would that be another challenge?).
Now comes my preferred method; the use of state modules;
You can write individual beacons for the behaviors you want to monitor and apply them whenever you want without having to worry about previous beacons or a combination of the desired config file, It will just add up to the beacons that are already applied, and because it's applied through the states it's automatically enabled, no need to restart the service.
Taking the A, B, and C example, you will end up with only 3 state files.
But now here's come another challenge, there are not many beacon examples of state files out there;
even though they look pretty much the same for other states, I usually have a hard time getting them right, so I decided to share its syntax.
1 - It's the ID, can be anything you want, or the name of the module;
2 - this one is self-explained, right ?! it's a beacon;
3 - the name of the module you want t monitor;
4 - it saves the beacon to the local minion's config file, it will persists upon reboots, otherwise it will just monitor available during the actual session;
5 - enable, means enable, right...why create something if you will keep it disabled;
6 - extra parameters the module might require;
if you are looking for some other examples, check my GitHub repository.
Now, it's your turn, tell me how you manage beacons in your environment.
