Server monitoring with Icinga 2 ? Part 2: the node (Ubuntu host)
Posted on 03-09-2015 07:15
It's been a long, long wait! But it's finally here, the second part of the Icinga 2 tutorial that I've promised a while ago.
Last time, we set up an Icinga 2 server to which we are now going to add a host. Unlike with Nagios, you can add hosts 'automatically' in Icinga 2 out of the box. That is, you have to do some things, but configuration is quite easy compared to getting started with NRPE. On top of that, it's a lot more secure: all communication is secured by TLS with certificates, which Icinga 2 can set up for you automatically.
So, we're going to add a host to our server. I'm assuming the host is running Ubuntu as well; any recent version will work.
Let's get started!
The server node
In order to be able to add hosts securely, we have to go to the server and run the following command:
This will start a wizard which will first ask you whether this is a satellite setup or not. Since this is the server or master you have to say 'No' here, to input an 'n':
It then starts generating keys are certificates required for secured TLS communication. In addition to that, it adds these to the configuration, plus it ensures this server is listed as the master:
It then asks you for the host and port for the API. We have no reason to change these, so leave these empty:
It then finalizes setting up this server as a master my editing some more configuration files:
With that done, restart Icinga 2 in order to use the new settings:
And the master is good for now. Let's move on to the host node!
The host node
On the host node, we're first going to have to ensure the Icinga 2 repository is present:
Press ENTER when it asks you to.
Note: If this command gives you an error, run 'sudo apt-get install software-properties-common' to get the 'add-apt-repository' command!
Once the repository has been added, update apt:
And install Icinga 2:
With that out of the way, we can initiate the same wizard as we did on the master:
This time we answer 'Yes' when it asks us if this is a satellite setup by just hitting ENTER:
After which is starts a different wizard:
It asks you for the common name and the local zone name for this server. These default to the system's hostname in fully qualified domain name format. These master uses the common name to connect to the server and the local zone name to identify it in configuration files. I just let these be.
It then goes on to ask you about your master node:
Please enter the Common Name of your master node (in my case 'icinga-server'). This is usually the hostname unless you've changed it. Then press ENTER when asked if you want to establish a connection to the master from this node. This triggers the next question:
Enter the master's IP address or Fully Qualified Domain Name (FQDN) here and accept the default port. Also press ENTER in order to not add more endpoints: we're just working with one master right now.
Then it's on to the connection for CSR auto-signing, the bit of magic that makes setting up a secure connection a bit easier for you:
Accept the defaults here as well, because the master we have entered before is also our server for CSR auto-signing.
After this, Icinga 2 is going to save some configuration on the host node and start the setup of a secure connection. As part of this process the master is contacted:
The certificate that has been set up needs to be signed in order to prove that you're actually in command of both servers and approve of this secure communication:
This means you need to run the following command on the master:
And copy the output from that command, which looks like 'ff84267fca3b0b29c4c88d94706c76f4247cac34r42; to the host node.
With all certificates signed and in place, we're asked about the API again:
Just like at the master, we're not going to touch these here.
The wizard now asks you whether to accept the configuration and commands from the master:
Select 'Yes' for both. Unfortunately, the Icinga 2 documentation is a bit fuzzy on this part. There are several ways to setup up a client, for example with a local configuration or as an execution bridge. I'm aiming for the latter of the two here: the master is in control and sends commands, the host node just executes them and returns the results. This is closest to what NRPE does and should keep all the data on the master.
With this done, everything is being put in place to make this work:
After which you need to restart Icinga 2 on the host node:
And it's back to the master.
Back to the server node (the master)
With the host node set up properly, only a few things remain on the master to be set up. First of all, we want to list the nodes on the master to see if our new host node is in there:
The output should include the node you've just added.
Then, we update the configuration on the master so the host node is being included in checks, or in other words is being added to the master:
The only thing that remains right now is to reload Icinga 2:
And we're done! After a few minutes results should start popping up in the web interface!
Warning about ParkingCrew.com! Case: ParkingCrew.com acquires NameDrive.com but earnings are not transferred despite assurances and promises. Inquiries about this are ignored! It's just a con compagny. Don't do business with them!
|Jump to Forum
|Subject||Discussion Forum||Last Post|
|Finding your way on your first ever VPS ? Part III||Linux tutorials, Tips & Tricks||: 1||17-10-2016|
|Server monitoring with Icinga 2 ? Part 1: the server (Ubuntu host)||Linux tutorials, Tips & Tricks||: 1||17-10-2016|
|Tutorial ? The LowEndCluster ? Part 4||Linux tutorials, Tips & Tricks||: 1||26-05-2015|
|Tutorial ? The LowEndCluster ? Part 3||Linux tutorials, Tips & Tricks||: 1||24-05-2015|
|Tutorial ? The LowEndCluster ? Part 2||Linux tutorials, Tips & Tricks||: 1||24-05-2015|