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