And I want to use it for Icinga2 self-monitoring, but after the official doc, I’m confused about steps for configuring this staff. And I can’t find more information about this method, but it looks like my solution to this question. Could somebody help me with this?
Hello Feu, Denys and me working on pretty big setup of Icinga2, in this setup we have several different teams(Operations/Devs/etc.), each team have their own Icinga2 cluster, we need to monitor clusters of Icinga2 that we provide to the teams + our own infra.
Icinga2 doesn’t have client/server application package structure, and the same demon stands as a server and client at the same time. Currently we are trying to start additional demon as a client for Team Icinga2 clusters.
In this schema we don’t have an interest to monitor Team N agents (see picture attached), but we need to ensure that Icinga2 servers we provide to the teams are healthy, also we need some kind of auto-remediation(Event commands) on clusters we provide to provide better high-availability if any services will go down, so passive checks in this case will be not an option for us and we need agent to monitor services and restart them automatically if required.
Regarding multiple-environments we expect that it will allow us to start multiple icinga2 demons on same system or demon will start with 2 different ports:
First for Icinga2 cluster to process payload from team agents
Second for our own monitoring needs
Icinga2 objects: ApiListener and IcingaApplication both have an option environment but it completely unclear for us on how to set it correctly, we’ve tried different configurations for it but didn’t succeeded in that and looking for some assistance.
Hope it will provide you more insights of what we are trying to implement.
Any config examples or recommended steps are highly appreciated.
Hello Dmitriy,
I am not sure, if I understand your setup correctly.
Why do you want multiple Icinga2 instances on the same machine? It would be useless for monitoring
each other, since a problem would often affect both instances.
As for the client functionality, a Icinga2 can do both jobs (server and client) at the same time, so it may well execute and delegate checks while itself receives commands or configuration.
Hello @lorenz, yes, cluster could monitor it self, the reason we implemented this schema - currently we(my team) provide different clusters to the Dev / SRE teams and we need to have a control that their clusters are healthy, that’s why we configured additional “Self-monitoring” cluster.
We already were able to solve this problem by compiling icinga2 from sources with different root prefix path(installed in /usr/local/), that way we are able to start 2 independent daemons on a single system
Hm, if you want to check, if Icinga is still running, I would suggest to use Icinga from another machine and execute the check via ssh. This would prevent the second Icinga (the one to monitor the first one) from suffering from most problems which would occur.
Well, if this solves your problem, it is good I guess.
I still would like to add, that IMHO monitoring from the same system is inherently problematic.
In any case, I wish you good luck