[Check_mk (english)] R: RE: R: Re: R: Re: Distributed monitoring question.

mlist at libero.it mlist at libero.it
Thu Feb 2 13:21:32 CET 2017


Would there be someone available to create a short step by step guide (with screenshots) related to distributed setup?
I would like to add it to my "beginner guide" and obviously the author would be mentioned





----Messaggio originale----

Da: "Greg Bessette" <greg.bessette at gmail.com>

Data: 02/02/2017 12.33

A: "Arno Wijnhoven"<arnow at vsnsystemen.nl>, <mlist at libero.it>, "Jam Mulch"<spammagnet10 at gmail.com>, <checkmk-en at lists.mathias-kettner.de>

Ogg: RE: [Check_mk (english)] R: Re: R: Re: Distributed monitoring question.








-->I am going to spin up a test and see if it can be done in the reverse.   Thanks everyone for the suggestions. From: Arno Wijnhoven [mailto:arnow at vsnsystemen.nl] 
Sent: Thursday, February 02, 2017 2:46 AM
To: 'mlist at libero.it' <mlist at libero.it>; Jam Mulch <spammagnet10 at gmail.com>; Greg Bessette <greg.bessette at gmail.com>; checkmk-en at lists.mathias-kettner.de
Subject: RE: [Check_mk (english)] R: Re: R: Re: Distributed monitoring question. Actually, there could be a way but this only works if you have an external DB with all devices.I never implemented this, but theoretically this could work. I use a tool that syncs WATO-config with our existing DB with devices (made this myself - tailored to our own database so I can’t share it… sorry).It uses the API to add/remove/update devices in WATO once each 5 minutes (existing DB is always ‘master’).When a monitoring site goes down, the tool can automatically assign the devices to another monitoring site which is still up.The selection of the ‘new’ host will be based on IP-ranges as not all of my monitoring hosts can reach all devices due to network restrictions. I never tried this as Check_MK is an additional monitoring tool for me (not main monitoring). I also have daily backups, so there’s no need for me to do this.Still, I’m pretty sure this will work, I can’t see why it won’t. Arno Wijnhoven From: checkmk-en-bounces at lists.mathias-kettner.de [mailto:checkmk-en-bounces at lists.mathias-kettner.de] On Behalf Of mlist at libero.it
Sent: woensdag 1 februari 2017 21:06
To: Jam Mulch <spammagnet10 at gmail.com>; Greg Bessette <greg.bessette at gmail.com>; checkmk-en at lists.mathias-kettner.de
Subject: [Check_mk (english)] R: Re: R: Re: Distributed monitoring question. Jam

I really thank you for this OUTSTANDING explanation. Very very clear!

Best
Marco ----Messaggio originale----
Da: "Jam Mulch" <spammagnet10 at gmail.com>
Data: 01/02/2017 16.46
A: "mlist at libero.it"<mlist at libero.it>, "Greg Bessette"<greg.bessette at gmail.com>, <checkmk-en at lists.mathias-kettner.de>
Ogg: Re: [Check_mk (english)] R: Re: Distributed monitoring question.

I meant that B has A entered as a host...I could have A monitor itself...but then if it crashed,
I wouldn't be able to look at it's services prior to the crash...until it was back up and running.

With some planning, you can move hosts from one site to another...if you are talking about
HA, there was some discussions on that but I haven't implemented anything.
Try a Google search on 'check_mk HA'

If you create folders on the main site with one folder having properties set to monitor using site X,
then all subfolders will inherit that setting....if X dies, you could change that folder setting to Y,
then commit the changes....all the hosts would get picked up by Y.

AFAIK there is no automated mechanism to do that in CMK CRE...maybein EE.


I have my folders set up in a hierarchy first by organization, then responsible group/service...like network, storage,  backups, wireless, etc...mainly for ease of notification configuration. (RBN based on folder)
and below that I have subfolders for which site they are monitored from.
I *can* migrate all hosts from one site to another, but I'd have to change a bunch of folder properties
near the bottom of the hierarchy, or use a script and the API to do so, but it wouldn't take me
more than an hour to do it manually.

A side-effect would be all the migrated hosts would lose their data history...and if switched back, there
would be a history gap on the original host...

I suppose you could setup backup sites configured with the same hosts, or periodically backup
your existing sites and put the backups somewhere so you could easily restore to another
server if your primary site server went down...mine are on VMs that are backed up daily so
I haven't had to do that.On 02/01/2017 09:53 AM, mlist at libero.it wrote:Hi jam

really interesting your explanation. Just a clarification please:

You wrote:

B has A as a host so if A has problems I can see it and if A dies, I can log into B's GUI and look at A's data)

Question:

Supposing that B fails, can I easy assign its hosts to A or C so that devices remain monitored? ----Messaggio originale----
Da: "Jam Mulch" <spammagnet10 at gmail.com>
Data: 31/01/2017 21.19
A: "Greg Bessette"<greg.bessette at gmail.com>, <checkmk-en at lists.mathias-kettner.de>
Ogg: Re: [Check_mk (english)] Distributed monitoring question.

I don't understand that setup. What I have is:

                                  A
                              /    \   \
                             B    C   D

Where A is the master and it pulls data from B,C,D and displays it on it's GUI.
B and C are configured on A as slaves with replication so I can do all the config
management on A. D is configured as a slave with no replication (Nagios XI) so
I can see it's problems on A's GUI.

All hosts are polled from either B, C, or D. The only things monitored directly on A
are B,C,D themselves. (B has A as a host so if A has problems I can
see it and if A dies, I can log into B's GUI and look at A's data.)On 01/31/2017 01:36 PM, Greg Bessette wrote:Hello, Currently within our environment, we have 3 separate instances that can see each other over port 6557.   Is it possible to add a master server to cover these 3 instances?  We want to leverage building unified dashboards and perform updates on one system versus three.   The future slave instances are older and targeted to be upgraded as they are on 1.2.6p5 Raw Edition. Thanks Greg Current A <--->  B <----> C    Proposed               D      /        |        \   A <-->  B <---> C   

_______________________________________________checkmk-en mailing listcheckmk-en at lists.mathias-kettner.dehttp://lists.mathias-kettner.de/mailman/listinfo/checkmk-en    



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mathias-kettner.de/pipermail/checkmk-en/attachments/20170202/21ccea2d/attachment-0001.html>


More information about the checkmk-en mailing list