Terminology

Firstly, take the necessary time to understand the terminology (that’s the correct word, right?). It took me a long time to wrap my head around this, so I will try and explain them first.

Service/Host

These two are very much the same.They are, basically anything you want to check.

Endpoint

This is a device (server/pc) that the (remote) Icinga 2 (henceforth Icinga) instance runs on. I struggle to understand this, as it does not seem to be a standard networking name.

Master

This is your Icinga server. The master. The main one. It might also help if you think of this as the server.

Satellite

This is a remote machine to monitor (remote) services and/or hosts with. It might also help you to think of this as a client/slave of the master.

Zone

I am still not 100% sure, but the way I have it set up now, is that every separate network is a zone. A collection of Endpoints.

These are the extra terms that I learnt and had to understand first.

Understanding these terms made it much easier for me to wrap my head around the system, and to configure it for my use. More information about each, and much, much more can be found in the Icinga 2 documentation.

The Setup

So, kind off obviously, you will have one (1) master node and multiple satellite nodes. From what I could see, during the installation, you can have more than one master, but I have not done it yet, so therefore cannot say anything about it.

I doubt I have done it correctly, but this was how I did it.

Ports

By default, Icinga uses port 5665. Nagios was port 5666, so I suspect that is why Icinga 2 uses 5665. Don’t fret, if you wish, this can be changed (relatively easily).

Have the port (5665 in this case) open for connections to and from both you master and satellite setups.

Master Setup

Start by installing Icinga. Icinga comes with an AWESOME set of Command Line tools, which is used extensively.

Run icinga2 node wizard and press ‘n’ (to answer ‘no’) to the first question to in the wizard. As the wizard will mention, ‘n’ (‘no’) installs a master setup and choosing yes will install a satellite (remote) setup.

Go through the setup, answering all questions. I don’t know why this is, but for me it was best not to use capitals. I suspect Icinga converts them to lowercase and then they do not match with what you do, so I think it is best not to use capitals, to minimize any possible confusion.

Only run this the first time, after that it’s not necessary to run for every satellite.

Satellite Setup

Satellite setup follows the same procedure, except that at the first question you must answer ‘y’ (‘yes’) to start the satellite setup wizard. Once again you need to answer the questions. Once again try not to use capital letters.

When asked if the satellite should accept configuration from the master, answer ‘y’ a(‘yes’).

When asked if the satellite should accept commands from the master, answer ‘y’ a(‘yes’).

When it prompts you for the key, generate it on the master and provide the generated key on the satellite setup. The command to generate it will be something like this: Icinga2 pki ticket --cn '<endpointname>'

Your satellite will then communicate with the master, get the necessary certificate and ask you to confirm it. Once you have confirmed it, you are done with the satellite setup.

The next thing I do, and this is not the correct way of doing it, that much I now, is to add a Zone and the necessary Endpoint(s) for the network in the master’s repository.d directory. The files in the repository.d directory should, in theory, not be necessary to edit, but (unfortunately, it is for me, this way.

After I have done that, successfully restarted Icinga and everything is working, I move on to adding the host and the services for the endpoint.

The next step is to create CheckCommands to check everything that the satellite system is to check. For some obscure reason this also took me quite some time to figure out how to do, but now that it is done, it works like a charm.

The CheckCommand definitions need to be on the master as well as the satellite. The master builds the command locally and then send it to the satellite for processing, and, I guess, the satellite then checks, somehow, if the command is a valid command and only execute it if it is. If set up correctly, the entire communication is very secure.

After this is done and there is no more problems with the CheckCommand definitions, on either the satellite or the master, we can then move on.

Next comes host/service definitions. The host definitions are the as previously discussed, so I will not go through it now. You can view the previous post here.

The services are mostly the same as previously discussed, but there is a small difference, there is an extra line to it: command_endpoint = "<endpointname>" where <endpointname> is the name of the endpoint specified previously. This line basically instructs Icinga 2 to run the command on the remote Icinga endpoint and get the status/result from there.

I used to use NRPE for everything, but am busy going over to Icinga and must say it seems to be much better. One network in particular, gave a lot of timmeout errors with NRPE. Since going over to Icinga, I have not had even 1. On it’s own this is mazing and makes it worthwhile, at least for me, to do the switch. It also seems to be much faster than NRPE and it has many bugfixes and security improvements over NRPE.

Conclusion:

Icinga 2’s remote agent is very nice. It’s not difficult to set up, but it does require an understanding of some things, especially terminology. I have explained how to do a setup for remote monitoring. If there is anything missing, or you think there is a better way (or even a different way) to do something, please do not hesitate to contact me.