Icinga agent versus by_ssh monitoring

Service Monitoring
1

What are the pros and cons when it comes to Linux hosts.

SSH is already installed on all hosts, thus i just have to add an SSH “monitoring” user and add the Icinga satelite SSH keys to the authorized_keys file to get the host into the monitoring.
If icinga no longer supports the OS I have to switch to by_ssh anyway. So why i should use the agent?

2

I see advantages for by_ssh:

  • no agent installation incl. certificates and zones etc required
  • is not limited to just one parent (which is very helpful for my test environment)

Advantages for icinga agent:

  • top down config sync provide checks being executed even if the parent is not reachable and resend check result once it is reachable again
3

Advantages for icinga agent:

  • top down config sync provide checks being executed even if the parent is not reachable and resend check result once it is reachable again

But with multiple satellites in one zone this also loses its importance in my opinion.

4

Configuration with by_ssh is not 1:1 transparent as with the Icinga agent. You’ll need to wrap commands and arguments in a way which works, but is barely readable - compared to what you get with native custom variables and command_endpoint.

Also, SSH connections are not permanently opened, which slows down the execution (and is known to be expensive).

The docs for 2.11 provide some benefits for each agent.

If you prefer SSH, go for it. You won’t get much help from my side though, I really dislike debugging the SSH layer when it comes to monitoring checks. That’s far more easy with the agent.

Cheers,
Michael