Master <-> satellite <-> agent, assign service to agent with command_endpoint == master

I have this scenario: master ↔ satellite ↔ agent I have firewall which prevent satellite and agent from executing a service. I need the command_endpoint of the service to be the master. By doing so, I get this error:

critical/config: Error: Validation failed for object 'agent!service' of type 'Service'; Attribute 'command_endpoint': Command endpoint must be in zone 'satellite' or in a direct child zone thereof.

Is it possible to perform what I am trying to do? Or should I modify my fw to move agent as a child of master ?

I have this scenario: master ↔ satellite ↔ agent I have firewall which
prevent satellite and agent from executing a service. I need the
command_endpoint of the service to be the master.

Is it possible to perform what I am trying to do?

No.

Or should I modify my fw to move agent as a child of master ?

Yes.

“Command endpoint must be in zone ‘satellite’ or in a direct child zone
thereof.” Note the word direct

Antony.

1 Like

Okay, thanks @Pooh !

Sure you can define services that are situated on a host with an Icinga2 agent but let the check command be executed on the master.

I use this mostly for HTTP checks.

EDIT: maybe I can because I don’t have a satellite in between?

That would be correct - Icinga really doesn’t have a definition of “Master”,
“Satellite” or “Agent” - they’re just convenient terms for humans to use in
understanding the hierarchy.

In fact, it’s not especially mentioned in the documentation, but you can have
as many levels of satellites as you want - anything from zero upwards.

I for example monitor both physical and virtual servers hosted in more than
one location (and belonging to more than one customer), and my hierarchy is:

Master = Internet-based system which can be seen from anywhere, and where I
manage the entire top-down configuration

Satellites, level 1 = Icinga running on a firewall / router at a hosting centre
(receives configuration details only for its “local” machines, not ones on
someone else’s network. Note also that a “hosting centre” might well be a
customer’s office with a server room, and personnel with browsers on the same
network, not necessarily a data centre which nobody normally has access to.)

Agents, level 1 = Standalone (physical) servers at a hosting centre

Satellites, level 2 = Physical server on the customer’s network, running a
virtualisation environment

Agents, level 2 = Virtual servers inside a virtualisation server

So, for the VMs, the hierarchy is:

Master → Satellite 1 → Satellite 2 → Agent

I do it this way for several reasons:

  1. it makes sense for the machines I’m managing, the way they’re both
    physically and logically grouped, and the fact that different hosting centres
    generally belong to different customers

  2. in case of a connectivity failure between the Master and a hosting centre,
    the service checks still run on the machines at that location and report to
    the local Satellite

  3. personnel at a hosting centre can access the local icingaweb interface
    (which shows only their machines and hides any other customers’ systems)

  4. Agents running on virtual machines inside one of the level 2 Satellites can
    be auto-configured to talk to “the local machine”, reducing network traffic and
    making the configuration simpler.

As a proof-of-concept I’ve even set up a 5-layer system with a Master, an
Agent, and three sets of Satellites in between, just to check that it works
(it does). I haven’t (yet?) come up with a real-world reason for using such
an arrangement, though.

Personally I think it’s a pity that this multi-level system isn’t more clearly
documented as a possibility, because I think it’s a useful arrangement in
certain situations, and it’s good for people to be aware that it works.

Antony.

2 Likes

This would make sense in the distibuted monitoring chapter, right?
We are always open to PRs, if you feel like creating one!

It might also make sense to just include it in the graphics, which would then be out of scope for a simple PR - but it might also confuse new users…