I have a good concept of how satellites and agents work manually, but I’m having some trouble figuring this out with Director. I’m trying to keep the configuration mainly confined to Director as I’m using Kubernetes and the container images, and it’s not quite as easy to do a bunch of custom manual configuration with this setup. The documentation seems more or less silent on this.
To start, I got a host added with agent installed and can easily get service checks running on that host as the check source. What I want to do is configure this host now as a satellite where I can configure other hosts and have the service checks run on the agent/satellite. There is no inward communication from my master instance to the network where the agent/satellite is installed.
I’ve tried adding a zone manually, but that seems to break the checks and configuration when I assign the host to that new zone. I haven’t updated or added the endpoint configuration. I can see that Director added both a zone and endpoint for the agent in the deployed configuration, they just aren’t visible in Director directly.
Ultimately, what are the steps to get this working? Is it possible to do all or most of this in Director?
Stellites can’t be setup in the director ATM but after it’s done manually the config import gets them into the director and from then on they can be used in the director.
I strongly advise against using the Director to configure satellite endpoints and zones.
I our setup (admittedly with many zones) it came apart after some time and we moved all satellite zones to the masters zones.conf file.
For the agents, doing this via a Template with the provided dropdown fields, is fine and works well.
You can control the direction for the communication via the host attribute in the endpoint object.
Setting the attribute in the satellites endpoint object on the master will mean that the master will try to connect to the satellite.
Setting the attribute on the satellite in the masters endpoint object will let the satellite connect to the master (preferred, as it takes a bit of load and log clutter from the master).
The satellite then has to be configured to accept_config and accept_commands in the api feature.
After a lot of experimentation, I’ve found a way to set up satellites that works. Most of the work can be done in director, which is great as my master is running as a container image and direct editing of configuration files is tricky.
These steps have been used successfully for multiple satellites and I haven’t yet found issues with them or the setup. Additionally, while I’m using a container image for the master, the satellites are set up as individually managed VMs.
Also note that when you’re working in Director, don’t deploy every change you make immediately. It should be okay, but I’ve only confirmed this works when deploying at the steps where I specifically indicate. These steps specifically configure a satellite that connects to the master, which works for the internal network where I developed these. Additionally, I have not tested with Windows Satellites. In theory, these steps will work as long as you convert them to the conventions on that OS.
Install Icinga on your intended satellite. If you’re following the official documentation, only do the steps in “Install Icinga 2” and “Set up Check Plugins”. Do not go past those steps.
In Director, create a new zone for your satellite. You can try using an existing defined zone, but I haven’t tested this scenario. The place for adding a zone can be found in the “Icinga Infrastructure” section. To match conventions for naming, use all lowercase letters and hyphens only in the name. Set the parent zone to “master”. Hold onto the zone name you are using, you will need it later.
Add a host entry for the new satellite. Do the steps just as if you are adding a normal host you would monitor. Do NOT set the agent configuration section yet. Keep note of the “hostname” you put in for the host, you will need it later. ADD/STORE the host.
In the newly created host, navigate to the “Agent” tab. Grab the agent script provided either by the download links or just copying the script text. Run this script on the intended satellite.
On the host, edit the file /etc/icinga2/zones.conf. In this file, you’ll see several objects defined. Find the Zone object with the same name as the host. Edit the name to be the name of the zone you created earlier. Save your changes and restart the Icinga2 service.
In Director, create a new Endpoint. This will also be found in the “Icinga Infrastructure” section. Set the name of the endpoint to the hostname of the host you created. Set the Cluster Zone to the name of the zone you created. You do not need to fill in any other fields. Once done, deploy the configuration.
Edit the host in Director. In the “Icinga Agent and zone settings” section, set “Cluster Zone” to the name of the zone you created. Set “Icinga2 Agent” to Yes. In the two new settings that appear, set “Establish connection” to No and “Accepts config” to Yes. Store the changes and then deploy the configuration.
That’s it! The satellite is now configured, and the majority of the configuration is stored/managed via Director. You can now add any hosts you need to the Cluster Zone and the satellite will be the check and scheduling source for it and any services attached.
The keys I found to getting it working are:
Setting up the zone and endpoint before turning on the agent setting on the host. This prevents Director from creating the host-only zone that it otherwise does.
Editing the zone.conf file on the satellite to have the created zone name. This puts it in the proper zone on start and allows the Icinga2 process on the satellite to get further configuration from the API once it connects to the master.
