How to organize your customers

Hi,
I’m new to Icinga. First of all thanks to all the developers for their valuable work.
I started reading the documentation, but I need some advice. How should I best organize the monitoring of some clients?
I mean, for example, three clients with these resources to monitor.

Customer 1:

  • host1 Linux
  • host2 Linux (which hosts “website 1” and “website 2”)
  • host3 Windows

Customer 2:

  • Linux host1 (which hosts “website 1”, “website 2” and “website 3”)
  • host2 Windows

Customer 3

  • host1 Linux (which hosts “website 1” and “website 2”)

In the future more customers will be added, but what interests me now is to understand how to start correctly with the structure.

Thank you in advance for your help!

Personally I would (and do) do this with a single Master which you manage,
communicating to one Satellite per customer, which then communicates to each
host for that customer (but, obviously, not any other customer).

This has the advantages that the configuration for each customer is only passed
to that customer’s Satellite (because your zone setup), and also that each
Satellite will continue to manage service checks running on that customer’s
host machines, even in the event of a communications failure between your
Master and that Satellite (which I assume is over the Internet, whereas
Satellite to host is more likely to be LAN). Once the communications comes
back, the service check history / backlog is uploaded from the Satellite to
the Master, so you get continuity of monitoring history even for the time when
you couldn’t actually connect to the customer’s network for whatever reason.

The bit which I do, and I believe is either not standard or not recommended,
practise (I’m not sure which), is to run Icingaweb2 on each of the Satellites,
so that each customer has their own view of their own network, and you can see
everything on the Master which knows about everything.

Hope that helps,

Antony.

3 Likes

This is what we’re doing too, with the exception of IcingaWeb being hosted externally - clients are provided with a read-only view of their ‘zone’.

Would do it as @Pooh described, as well!

@Pooh Out of interest, as I have never set up a Satellite with its own Icinga Web 2 interface:
Do you connect the Interface to the masters DB instance or do you install a separate DB on the satellite?

1 Like

Local DB on the Satellite - it’s “that customer’s Icinga machine”, they don’t
need to know about the Master.

If I wanted a Satellite pointing at the Master DB (don’t know how to do that),
I’d do the same as Liam Best, and give each customer a restricted view of the
Master DB.

Antony.

4 Likes

Thanks for the explanation!
Also agree with you and Liam on the restricted view by zone/variable/whatever :slight_smile:

1 Like

thank you all for your precious advice :slightly_smiling_face: