1

I successfully installed icinga2 and icinga2-web on Debian 8. The problem is that I need to monitor servers with Debian 5, 6 and 7 installed. Is it even possible?

If I understand correctly - I need a icinga2 client installed on host I want to monitor and there is no such thing like specific client in icinga2 - one needs to install whole icinga2 package.

I tried to install this package on squeeze from backports (instruction found here: http://debmon.org/instructions) but without success.

As I start my adventure with monitoring - I would appreciate every help. Thanks in advance.

3 Answers 3

3

While it may be confusing that you'd just install the icinga2 binary package on a node you're calling a "client", it is reasonable to do so.

That way you'll benefit from the following things:

  • Same setup for all nodes in your (cluster) distributed setup, be it master, satellite, client, agent, or any other role you'll assign to them.
  • Same configuration dsl for all involved nodes
  • Clients use the same benefits as cluster nodes do: SSL x509, IPv4 & IPv6 support, replay log on connection loss, etc.

Setting up clients is helped with cli wizards and CSR-auto-signing mechanisms. Though if you are already familiar with the Zone and Endpoint concept in Icinga 2, you may also use your own tools to configure the clients as well as deploy the SSL certificates (e.g. by re-using the Puppet CA).

Though over time, there were three different methods used by the community which are now that popular requiring them being explained in detail in the docs (which is confusing to read and still on the todo list to rewrite).

1) Clients with local configuration. Icinga 2 comes with some basic example checks monitoring the local node. By adding new checks locally and restarting Icinga 2, the core on the client will start to execute the checks and report them to the connecter master node. On the master, you're capable of listing the nodes from the collected repository, black/whitelist them and then generate configuration using 'node update-config'.

In case you're finding it cumbersome to manage configuration on each client yourself - that's true, but in terms of automation and local configuration it is still a valid point.

2) Central configuration master with (satellites and) clients. This method re-uses the Zone and Endpoint mechanism from the Icinga 2 cluster, and allows you to distributed the configuration from the master to the clients. That way you'll just manage the host/service objects on the master, and let Icinga 2 handle the rest. There's even space for a global zone including templates, check commands, etc.

In that scenario you'll just setup the client once, and let the master handle the rest. You'll also gain the benefit of a local scheduler on the client, which continues to check and replays the check history on connection re-establishment (which is certainly helpful for SLA reporting).

3) If you're looking for an NRPE like check execution without a local scheduler, but a quick command plugin executor, you might use the clients as "command execution bridge". In that scenario, you'll initially setup the client once, and add its Endpoint/Zone config to the master. The checkable host/service objects are also configured on the master, but reference a so-called "command_endpoint". This makes Icinga 2 send the check execution to the Icinga 2 client, which asynchronously executes the check and sends the result back to the master.

You'll still need the local CheckCommand definitions on the client. The Icinga Template Library (ITL) already provides plenty of them, but in case you're looking into adding your own, you should consider taking 2) with only a global zone syncing the command configuration.

That way you can also ensure that certain command parameters passed on the master can be disabled on specific clients (the infamous "-a" parameter of nrpe, but in a more controlled way).

More can be found in the documentation: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/icinga2-client#icinga2-client-scenarios

When it comes to Debian 5 Lenny - that's end-of-life, and therefore not supported by Icinga 2. Go for check_by_ssh then. http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-by-ssh

2

Icinga is a fork of nagios and it uses the same plugins/clients for monitoring. What you need is the nrpe daemon and nagios-plugins.

The nrpe daemon is running on the servers you want to monitor and is listening for requests from remote nagios/icinga. When such request comes it can execute a particular plugin and return the result to your icinga server.

The nagios plugins are collection of small programs that check for the status of particular service/resource and report back with OK, WARNING, CRITICAL depending on the conditions.

The packages you need are:

  • nagios-plugins
  • nagios-nrpe-server

You have to have them installed on each server you want to monitor.

2
  • note that if you write a lot of plugins yourself or install manually you might not need nagios-plugins depending on what you want to monitor. Dec 9, 2015 at 15:10
  • nrpe is considered insecure (check the CVE lists) & buggy. the icinga2 client attempts to solve these problems and shortcomings.
    – dnsmichi
    Dec 9, 2015 at 20:10
0

If you only need to check the availability of externally available services (Like HTTP), you don't need to install software on the client.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .