Aggregating multiple Icinga2 clusters into one central IcingaWeb2 (no Thruk / Livestatus)

Hi everyone,

We’re running Icinga2 across multiple clusters and trying to figure out a good way to get a central view of everything without relying on Thruk or Livestatus (since that’s not supported in Icinga2 anyway).

Current setup

Right now, we have a central setup, but as we add more clusters, it’s becoming harder to manage. A bad config in one cluster can cause issues for others, and we’re also seeing increased load on the central API.

We’d like to split things up so each cluster is self-contained, but we still want one place to view everything.

What we want

The goal is to have:

  • One Icinga2 master per cluster
  • One satellite and a couple of IcingaWeb2 pods per cluster
  • One central IcingaWeb2 instance that can show data from all clusters

Each cluster should keep running on its own (for isolation and availability), but we’d like to avoid having to check N different IcingaWeb2 UIs every time something happens.

Problem

Thruk seemed like a good idea, but it only works with Livestatus, which Icinga2 doesn’t support. The HTTP backend in Thruk also doesn’t help here, since it’s just for talking to other Thruk instances.

So I’m wondering if anyone has solved this in a clean way.

Looking for advice

  • Is there any officially supported way to aggregate Icinga2 data across multiple clusters?
  • Has anyone tried pulling data via the API into a central frontend?
  • Are there ways to do this with DB replication, Grafana, or something similar?

Ideally, we’d like to keep each cluster independent, but still have a single view (even if it’s just read-only). Open to ideas or hearing how others are approaching this.

Thanks!

Actually, it does. Features - Icinga 2
However, its deprecated. As i know a few large setups which are using livestatus i dont think it will be actually removed in the next few major releases - but who knows?

IcingaDB supports different environments, as theres a environment id in the database which could be used to differentiate between setups. Anyways, at the moment nothing like that is supported in the IcingaDB Web counterpart.