18 – 22 June looked at the cloud and development models, offered a guide to NSCA and counted down to the OSMC.
In charge of our cloud and a OpenNebula fan, Sebastian was proud to see Netways featured on OpenNebula’s list of users.
On the same theme, Bernd considered SLA in the cloud, upon learning of Amazon Web Services’ availability woes.
Following on, Alexander clarified the software development concepts within and around Model Driven Architecture, while Philip continued his NSClient++ series with part 7 on NSCA.
As usual Eva counted down to the OSMC (121 days) with a video of Oliver Jan’s presentation on “Monitoring Solutions for the Next Decade.”

Serie NSClient++ – Teil 7: NSCA

In den vorherigen Teilen der NSClient++ Serie wurden die Möglichkeiten der aktiven Überwachung eines Windows Servers mit NSClient++ aufgezeigt.
NSClient++ verfügt, neben den Modulen für aktive Abfragen (NSClientListener, NRPEListener), auch über ein Module für passive Abfragen, NSCAAgent.
NSCA (Nagios Service Check Acceptor) ist ein Nagios/Icinga Add-On bestehend aus zwei Komponenten:
* NSCA Server: Der NSCA Daemon auf dem Monitoringsystem welcher passive Checkergebnisse an nimmt und diese in die Nagios- bzw. Icinga-Commandpipe schreibt.
* NSCA Agent: Der NSCA Agent auf dem Clientsystem welcher die Checkergebnisse an den NSCA Server weiterleitet.
Eine gute Anleitung für die Installation des NSCA Servers findet man in der Icinga Dokumentation: http://docs.icinga.com/latest/de/nsca.html#id3878652
NSClient++ verlangt einige Einstellungen in der NSC.ini um NSCA zur Aktivierung und Konfiguration.
Zuallererst muss das NSCAAgent Modul geladen werden:

; NSCA Agent if you enable this NSClient++ will talk to NSCA hosts repeatedly (so dont enable unless you want to use NSCA)
NSCAAgent.dll

Anschließend muss NSCA konfiguriert werden. Wichtig ist hierbei zu wissen welche encryption_method und ggf. welches password auf der Seite des NSCA Servers (nsca.cfg) definiert wurde. Beide Optionen, Verschlüsselung und Passwort, müssen mit der NSCA Agent Konfiguration übereinstimmen.

[NSCA Agent]
;# CHECK INTERVALL (in seconds)
;   How often we should run the checks and submit the results.
interval=120
;# ENCRYPTION METHOD
encryption_method=1
;# ENCRYPTION PASSWORD
;  This is the password/passphrase that should be used to encrypt the sent packets.
password=icinga
;# LOCAL HOST NAME
;  The name of this host (if empty "computername" will be used.
hostname=windows-server
;# NAGIOS SERVER ADDRESS
;  The address to the nagios server to submit results to.
nsca_host=icinga.training.netways.de
;# NAGIOS SERVER PORT
;  The port to the nagios server to submit results to.
nsca_port=5667

Der hostname muss mit dem in Nagios/Icinga definierten Hostobjekt übereinstimmen.
Nach der Konfiguration des NSCA müssen die NSCA Commands definiert werden, jene Checks die NSClient++ ausführen soll und an den Monitoringserver senden soll. Hierbei muss jeweils das Checkcommand mit den dazugehörigen Argumenten angegeben werden:

[NSCA Commands]
CPU=CheckCPU warn=80 crit=90 time=15m time=10m time=5m ShowAll=long
Memory=checkMem MaxWarn=80% MaxCrit=90% ShowAll=long type=physical
Disk-C=CheckDriveSize MaxWarn=80% MaxCrit=90% ShowAll=long Drive=c:

Die Namen der Commands müssen mit den in Nagios/Icinga definierten Serviceobjekte übereinstimmen.
Damit der NSCA Server die empfangenen Checks auch richtig an Nagios/Icinga weiterleiten kann muss dort der jeweilige Service, als passiver Service, definiert werden.
Beispiel:

define service{
        use                     generic-service
        host_name               windows-server
        service_description     CPU
        check_command           check_dummy!3 "No results received, check NSCA"
        active_checks_enabled   0
        check_freshness         1
        freshness_threshold     600
        }