On Monday 19 December 2016 at 23:38:57, Volker Janzen wrote:
> > then use the master -
> > client setup described in section 6 of the documentaton:
> >
> > https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distrib
> > uted- monitoring
>
> I read this document, but I was a bit confused which way to follow. There
> are too many possibilities. ;-)
See if this description helps:
Master = a machine running Icinga2 (and probably Icingaweb2 as well) which can
show the results of monitoring both itself and many other machines
Client = a machine running Icinga2 (but probably not Icingaweb2) which
monitors only itself, and reports the results back to a master or satellite
Satellite = a machine running Icinga2 (and maybe Icingaweb2 as well) which
monitors itself and clients which are connected to it, and reports the results
to a parent master
Example scenario:
I offer monitoring services to my customers; I run a Master, and I can see all
the checks on all th emachines on its Icingaweb2 interface.
Each customer has a Satellite and several Clients. The Satellite runs
Icigaweb2, so they can see the monitoring of their own machines (but have no
knowledge or visibility of any of my other customers). If network connetivity
breaks between the customer and my Master, their Satellite continues managing
the monitoring of the local Clients.
The Clients just do as they're told by the local Satellite; each Satellite
does what it's told by my Master; I use top-down command-endpoint mode.
> > Yes, except there is no Icinga "agent" - it's just Icinga.
>
> I think I read the term agent in the German Icinga book.
Yes, I've seen the term used, I just wanted to stop you trying to find the
Icinga2 Agent to be able to install it - there isn't one - it's the standard
Icinga2 binary.
> >> I want the agents to be configured locally.
> >
> > Why?
>
> It's the way I currently manage the configuration with NRPE. I add all
> local expections to the nrpe_local config. When I work on the VM I can
> adjust the nrpe config and (if it's not a new command) I do not need to
> login to nagios.
Okay, well that would be bottom-up configuration in Icinga2's terminology, and
it certainly does support it - in the above Master - Satellite - Client
description, the configuration would all be on the individual Client endpoints,
and the Satellite and Master Icingaweb2 interfaces would still show the same
sets of results as described above.
Bottom-up is certainly an option; it makes sense in some scenarios, but I've
never used it.
> With icinga2 it seems that I could work this way too and even install new
> command locally and they are pushed to the master then.
Yes, the Master learns about the commands from the Clients rather than the
other way round - in both case the Clients send the results to the Master.
> I'll read the top-down part again and reconsider it. I'm currently still
> figuring out how I can do my setup. I can still change everything.
My approach to deciding this is based on the question "who configures the
monitoring?"
If it's one person or team, I prefer to have that configuration in one place
(on the Master), so that it's all managed in a single set of configuration
files
on a single machine.
If the monitoring configuration is done by lots of different people, because
they each manage their own servers, then bottom-up would be the better
approach, because each server admin is then responsible for configuring the
monitoring on that server, and can't interfere with the configuration of any
other.
> > How are these files being auto-generated? What tool are you using for
> > the auto-generation?
>
> Same answer: icinga2 node wizard. The address/address6 is not included
> automatic.
Ah, okay - I've only used the node wizard to create the bare definitions of the
Endpoints and the Zones - I've never used it to create the Hosts as well.
Um... you *are* creating a Host definition for the thing you want to monitor,
aren't you? You're not trying to put the Service checks into an Endpoint
definition, by any chance?
> > That should be: vars.os = "Linux"
>
> Even with this syntax I still get an error. I'm just not sure which one,
> systemd/journald hide the error message from me. They just say icinga2
> reload failed, but do not show a reason. Need to check how to see the
> error.
icinga2 daemon -C
Antony.
--
This email was created using 100% recycled electrons.
Please reply to the list;
please *don't* CC me.
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
