Grosse Umgebungen sind haeufige Einsatzgebiete von check_multi, um die

• Anzahl der Nagios-Server gering zu halten
• Komplexitaet einer verteilten Nagios-Infrastruktur zu vermeiden

Auf der anderen Seite hat auch check_multi Nachteile (Es kann nur einen geben), wenn

• heterogene Gruppen am Monitoring teilnehmen
• ein Nagios-Objekt fuer jedes ueberwachte Attribut (=check_multi Child-Check) gewuenscht wird.

Dies war der Startpunkt und die Motivation, fuer eine verbesserte Implementierung mit

• dem normalen check_multi-Plugin als einem aktiven Datensammler
• einem erweiterten Report-Modus, der alle Child-Resultate als passive Checks ins Nagios bringt.

• Die Kommunikation zwischen Nagios und dem Client findet nur einmal fuer alle Checks statt, aber nicht einmal pro Check.
• Der Multi-Check ist aktiv und damit unter der Kontrolle des Nagios-Scheduling.
• Alle Einzel-Services sind passive und verursachen damit keine Load in der Nagios-Scheduling-Queue.
• Trotzdem sind alle Services normale Nagios-Services, es gibt daher: Benachrichtigung, Eskalierung, Reporting.
• Der Performance-Vorteil ist enorm: 25000 Services pro Server sind ohne weiteres moeglich (siehe Performance-Teil).

• Die Komplexitatet ist groesser als bei einer rein aktiven Implementierung (aber geringer im Vergleich zum verteilten Setup).
• Die Konfiguration muss zweimal aufgesetzt werden, einmal fuer den aktiven Teil, dann fuer die passiven Checks.

1. check_multi arbeitet als normaler aktiver Nagios check und sammelt auf einem Remote-Host Daten.
2. Jeder Child-Check hat einen entsprechenden passiven Check im Nagios mit genau demselben Namen.
3. check_multi nimmt den Output des Child-Checks und den RC und fuettert damit den gleichnamigen passiven Nagios-Check.

Das ist schon alles.

Es gibt ein Problem, wenn auf der Remote-Seite Checks ausgefuehrt und deren Ergebnisse in die passive Eingangsqueue von Nagios transferiert werden sollen: den Transport.

• Wenn check_multi auf dem Nagios-Server ausgefuehrt wird, muss pro Child-Check eine eigene Remote-Verbindung aufgebaut werden. Sehr teuer.
• Wenn check_multi auf dem Remote-Server ausgefuehrt wird, gibt es ein Problem, die Input-Queue von Nagios auf der passiven Seite zu erreichen.

Die Loesung ist: check_multi wird zweimal aufgerufen in einer Kommando-Kette:

1. check_multi auf dem Remote-Host sammelt die Daten.
2. Ein zweites check_multi auf dem Nagios-Server fuettert die Passiven Services.

Das erste check_multi gibt seine Daten per XML an das zweite check_multi auf dem Nagios-Server zurueck.

Anmerkung: die gesamte Kette wird auf dem Nagios-Server gestartet. Fuer DMZ-Host-Monitoring werden daher keine Inbound Connections verwendet.

1. SSH:

   check_by_ssh -H <hostname> -c '/path/to/check_multi -f multi.cmd -r 256' | check_multi -f - -r 8192

2. NRPE:

   check_nrpe -H <hostname> -c check_multi -a '-f multi.cmd -r 256' | check_multi -f - -r 8192

3. NSCA:

   check_nrpe -H <hostname> -c check_multi -a '-f multi.cmd -r 4096'

   
   Diese Methode benoetigt einen laufenden nsca-Daemon auf dem Nagios-Server. Da die Verbindung auf dem Remote-Server gestartet wird, ist diese Methode nicht fuer DMZ-Setups geeignet.

check_multi laesst sich einfach in Sven Nierleins mod_gearman integrieren.

mod_gearman ist ein Nagios NEB module, das in einem gearman scheduling framework laeuft und die Check-Resultate in Nagios zurueckgibt. Mit dieser Technik koennen viele tausend Checks sehr effizient und flexibel in einer einzelnen Nagios-Instanz ausgefuehrt werden.

Ein spezieller Client 'send_multi' ist Teil des mod_gearman-Pakets und kann dazu verwendet werden, die einzelnen Child-Check-Resultate in die gearman-Queues einzuspeisen.

Dieser Client ist ein kleines C-Binary und bei weitem ressourcensparender, als wenn man check_multi selber dazu verwenden wuerde, die Checks an Nagios zurueckzumelden.

Aufrufbeispiel:

$ check_multi -f multi.cmd -r 256 | \
   send_multi --server=<job server> --encryption=no --host="<hostname>" --service="<service>"

Anmerkungen:

• Moechte man lediglich check_multi und keine weiteren Worker verwenden, so kann man das mit der folgenden NEB-Modul-Konfiguration in der nagios.cfg erreichen:
  

  broker_module=/usr/local/share/nagios/mod_gearman.o \
     server=localhost \
     encryption=no \
     eventhandler=no \
     hosts=no \
     services=no \
     hostgroups=does_not_exist

• Encryption ist nicht notwendig, wenn sowohl check_multi als auch die Nagios check_results-Queue auf demselben Server laufen.

Diese Beispiel-Installation ist Teil des sample-config-Verzeichnisses im check_multi-Paket.
Achtung: das Setup laeuft nur auf einer Maschine, es ist kein Remote-Zugang eingeschlossen. Fuer das grundsaetzliche Verstaendnis des Prinzips spielt das aber keine Rolle

Kochrezept:

1. check_multi, aktuelle SVN downloaden.

2. ./configure; make all

3. cd sample-config/feed_passive

4. Installieren Sie das feed_passive-Beispiel mit

   make install-config

   , dies wird ein Verzeichnis /path/to/nagios/etc/check_multi/feed_passive erzeugen und fuellen.

5. Fuegen Sie dieses Verzeichnis als cfg_dir zur nagios.cfg hinzu:

   cfg_dir=/usr/local/nagios/etc/check_multi/feed_passive

6. reloaden / restarten Sie Nagios: das war schon alles
   
   

• In der Standard-Auslegung gibt es 10 Hosts mit 10 aktiven Services and 100 passiven Services.
• Wenn's etwas mehr sein soll, wechseln Sie bitte in das <nagiosdir>/etc/check_multi/feed_passive und fuehren

  perl gencfg nhosts

  aus, danach wieder einen Nagios-Reload.

1. mandatory - perl module XML::Simple
   Installieren Sie XML::Simple auf dem Nagios-Server, entweder aus Ihrer Linux-Distribution oder direkt von CPAN. Das Modul wird nur auf der Empfangsseite, also dem Nagios-Server benoetigt. Die Sender (Remote-Clients) brauchen kein XML::Simple.
2. Optional - nagios.cfg Einstellungen
   Ich empfehle noch, einige Einstellungen in der nagios.cfg aus Performance-Gruenden anzupassen, ausserdem wird unnoetiges Logging vermieden.
   

Keines dieser Attribute ist zwingend erforderlich, aber die Performance in grossen Setups wird erheblich verbessert.

Nur als Beispiel ;)

#--- multi.cmd
command [ system_disk  ] = check_disk -w 5% -c 2% -p /
command [ system_load  ] = check_load -w 10,8,6 -c 20,18,16
command [ system_swap  ] = check_swap -w 90 -c 80
command [ system_users ] = check_users -w 5 -c 10
command [ procs_num    ] = check_procs
command [ procs_cpu    ] = check_procs -w 10 -c 20 --metric=CPU -v
command [ procs_mem    ] = check_procs -w 100000 -c 2000000 --metric=RSS -v
command [ procs_zombie ] = check_procs -w 1 -c 2 -s Z
command [ proc_cron    ] = check_procs -c 1: -C cron
command [ proc_syslogd ] = check_procs -c 1: -C syslogd

#--- avoid redundant states
state   [ WARNING      ] = IGNORE
state   [ CRITICAL     ] = IGNORE
state   [ UNKNOWN      ] = IGNORE

Dieser Service laeuft auf dem Remote-Host und sammelt Daten:

• check_multi report option -r 256+4+1:
  1. erforderlich: -r 256 as XML output option
  2. Empfohlen: -r 4 for ERROR output
  3. Last not least: -r 1 for detailed results in the status line
• Beispiel:
  

  define service {
          service_description     multi_feed
          host_name               host1
          check_command           check_multi!-f multi_small.cmd -r 256+4+1 -v
          event_handler           multi_feed_passive
          check_interval          5
          use                     local-service
  }

• Notwendig: passive_checks_enabled 1
• Notwendig: active_checks_enabled 0
• und der Rest nach Belieben
• Beispiel:

  define service {
          service_description     $THIS_NAME$
          host_name               $HOSTNAME$
          passive_checks_enabled  1
          active_checks_enabled   0
          check_command           check_dummy!0 "passive check"
          use                     local-service
  }

Mit dem Report-Mode 2048 koennen Sie sich diese Service-Definitionen einfach erzeugen:

check_multi -f multi.cmd -r 2048 -s service_definition_template=/path/to/service_definition.tpl > services_passive.cfg

Hinweis: schreiben Sie sich einen Einzeiler, der ueber die Nagios-Hosts laeuft und den Stapel der Service-Check-Definitionen erzeugt. Wann immer ein Host hinzugefuegt oder entfernt wird, lassen Sie diesen Einzeiler laufen und reloaden danach Nagios.

• Die Fehlermeldung Passive check result was received for service '%s' on host '%s', but the service could not be found! bedeutet, dass fuer einen check_multi-Childcheck keine entsprechende passive Service-Definition gefunden wurde. Kontrollieren Sie bitte die passiven Service-Definitionen.
• Wenn Sie mit einer XML-Datei testen wollen, verwenden Sie z.B. eine Pipe, z.B.

  cat test.xml | check_multi -f - -r 8192

  .

• Ein beliebter Fehler ist, die Command-Datei auf der Empfaenger-Seite anzusiedeln, z.B. check_multi … | check_multi -f - -f xyz.cmd.
  Damit monitoren Sie Ihren Nagios-Server, nicht aber den Remote-Host. Machen Sie sich nochmal deutlich: Die Pipe hat zwei Teile:
  - einen Sender-Teil fuer Remote, wo die Informationen gesammelt werden (→ Input)
  - einen lokalen Empfaenger-Teil auf dem Nagios-Server, wo die Informationen ausgegeben werden (→ Output).

Hardware

• Dual core Athlon X2/64 3600 with 1 GB RAM

Nagios configuration

• 1000 hosts
• 1000 active services
• 25000 feeded passive services

# sar -u
06:00:00 PM       CPU     %user     %nice   %system   %iowait     %idle
06:00:01 PM       all     32.28      0.00     28.37      0.71     38.63
06:10:01 PM       all     31.66      0.00     27.86      1.05     39.43
06:20:31 PM       all     31.60      0.00     28.06      1.25     39.09
06:30:01 PM       all     31.61      0.00     28.40      1.19     38.79
06:40:01 PM       all     31.55      0.00     28.39      1.16     38.90
06:50:01 PM       all     33.68      0.00     28.54      0.92     36.86

# sar -q
06:00:00 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
06:00:01 PM         3       166      1.99      2.52      3.75
06:10:01 PM         3       158      1.91      2.19      2.95
06:20:31 PM         2       155      1.53      1.93      2.44
06:30:01 PM         2       159      2.22      2.11      2.28
06:40:01 PM         2       155      1.76      1.96      2.10
06:50:01 PM         2       165      1.90      2.14      2.14

Nagios Stats 3.1.2
Copyright (c) 2003-2008 Ethan Galstad (www.nagios.org)
Last Modified: 06-23-2009
License: GPL

CURRENT STATUS DATA
------------------------------------------------------
Status File:                            /usr/local/nagios/var/status.dat
Status File Age:                        0d 0h 0m 5s
Status File Version:                    3.1.2

Program Running Time:                   0d 1h 40m 5s
Nagios PID:                             4112
Used/High/Total Command Buffers:        0 / 0 / 4096

Total Services:                         26001
Services Checked:                       26001
Services Scheduled:                     1001
Services Actively Checked:              1001
Services Passively Checked:             25000
Total Service State Change:             0.000 / 7.760 / 0.327 %
Active Service Latency:                 0.000 / 1.054 / 0.160 sec
Active Service Execution Time:          0.300 / 3.266 / 0.917 sec
Active Service State Change:            3.750 / 7.760 / 4.246 %
Active Services Last 1/5/15/60 min:     187 / 988 / 1001 / 1001
Passive Service Latency:                0.000 / 0.000 / 0.000 sec
Passive Service State Change:           0.000 / 7.760 / 0.170 %
Passive Services Last 1/5/15/60 min:    4694 / 24676 / 25000 / 25000
Services Ok/Warn/Unk/Crit:              26001 / 0 / 0 / 0
Services Flapping:                      186
Services In Downtime:                   0

Total Hosts:                            1002
Hosts Checked:                          1002
Hosts Scheduled:                        1002
Hosts Actively Checked:                 1002
Host Passively Checked:                 0
Total Host State Change:                0.000 / 0.000 / 0.000 %
Active Host Latency:                    0.971 / 2.042 / 1.366 sec
Active Host Execution Time:             0.024 / 1.150 / 0.065 sec
Active Host State Change:               0.000 / 0.000 / 0.000 %
Active Hosts Last 1/5/15/60 min:        185 / 935 / 1002 / 1002
Passive Host Latency:                   0.000 / 0.000 / 0.000 sec
Passive Host State Change:              0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min:       0 / 0 / 0 / 0
Hosts Up/Down/Unreach:                  1002 / 0 / 0
Hosts Flapping:                         0
Hosts In Downtime:                      0

Active Host Checks Last 1/5/15 min:     220 / 968 / 2906
   Scheduled:                           220 / 968 / 2906
   On-demand:                           0 / 0 / 0
   Parallel:                            220 / 968 / 2906
   Serial:                              0 / 0 / 0
   Cached:                              0 / 0 / 0
Passive Host Checks Last 1/5/15 min:    0 / 0 / 0
Active Service Checks Last 1/5/15 min:  200 / 1001 / 3003
   Scheduled:                           200 / 1001 / 3003
   On-demand:                           0 / 0 / 0
   Cached:                              0 / 0 / 0
Passive Service Checks Last 1/5/15 min: 4975 / 25000 / 75000

External Commands Last 1/5/15 min:      0 / 0 / 0