My current “issue”:
I got a couple cases in different spots or our infrastructure where i want to monitor the “same” service more than once on the same host.
The most common example would be more than one http(s) service running on the same host, and i want to check all of them. Especially if they use different ssl-certificates i need to have a couple copies of that service. Another case would be having an ingress (as in kubernetes) that provides access to mupltiple services, usually all http(s).
No i can add 5 https(s) checks to the same host but that has issues:
service names need to be unique, so i get a lot of different names for services doing the same thing, which clutters the webGUI, also if i write the monitoring data to influxDB or the like i can’t just say “give me all https data” since there is like http-1 to http-12 in there
My current solution is add a host entry for every service, adding a custom value that tells me that’s an “alias host” where i add the service again. That naturally leaves the issue which of those dummy hosts are connected. Afaik there is no simple way to link hosts so someone using icingaweb2 can figure out that those 5 hosts are all the same “physical” box, just a webserver and 4 additional vHosts on there getting checked.
I’m not sure if I got your goal correctly. To me it sounds like you want to have just one service per type e.g. http that covers many instances on the same host. The common way to realize this is to use apply for which generates one service per instances. But this is something you don’t want especially in case of using infuxdb.
What you could do instead is to write a wrapper that collects the results of plenty check plugins and return just one summary. This would work well for plugin output, common check result and performance data. But this would not work well for alerting since icinga issues alerting for state change only. For example, if you have one failing http check this wrapper return overall check result critical. but if then the next http fails as well, icinga does not recognize a state change, hence, no notification would be triggered.
I think you have to live with the “clutter” in icingaweb2 but I would let the service be generated maybe via x509 for SSL certificate checks and k8s and other highly dynamic stuff I would try to remote control icinga via API for host, services and results. How you partition the hosts and services depends on your favorite view 1 service n hosts or 1 host n services but you can use groups and or the business process module to bundle dummy hosts together.
