Nagios installieren und konfigurieren

Vorwort

Alles im Griff

Vertrauen ist gut, Kontrolle ist besser ... ein Spruch, der sich gerade was Server betrifft sich immer wieder bewahrheitet. Deswegen ist ein ordentliches Servermonitoring das A und O wenn es darum geht, die darauf laufenden Dienste auch immer im Auge zu behalten und schnell einzuschreiten, wenn es einmal wo kracht. Oder noch besser: Wenn es sogar automatisch wieder ans Laufen gebracht wird und unser Eingreifen nur noch dann gefordert ist, wenn es nicht mehr anders geht.

Um Server zu Überwachen gibt es sicherlich teure Lösungen. Aber wir wollen uns einmal daran halten, was uns die Opensource Welt an Softwaregeschenken macht. Das führt mich zu Nagios, eine freie Servermonitoring Software, die weit verbreitet ist und es eine Vielzahl an Erweiterungen mittlerweile gibt, die einem das Leben noch leichter machen.

Mich hat es zudem interessiert, ob wir auf unserer NSLU2 auch die Chance haben, derartige Software zum Laufen zu bringen.

Nagios auf der NSLU2 in Äktsch'n:

Dazu habe ich erstmal ein aktuelles Debian (Debian 6 Squeeze) für die ARML Plattform installiert (eine Anleitung dazu findet Ihr hier, doch macht hier nur die Basisinstallation und keine weiteren Dienste! http://myslug.de/index.php?title=Debian_6_auf_der_NSLU2

Wenn Ihr ein Basissystem installiert habt, kann es schonmal los gehen. Wir installieren zuerst ein Standard Nagios über den apt:

Nagios installieren

Um das System auf einem Debian Lenny zu installieren kann der Apt Paketmanager relativ einfach verwendet werden. Auf einem einfachen Basissystem setzt hierzu ein

apt-get install nagios3 nagios-plugins

ab. Die folgenden beiden Abfragen beantwortet einfach mit den jeweiligen Standardvorgaben:





Ansonsten dürfte das Standardsystem damit installiert sein. Der vorgegebene User innerhalb der Standardkonfiguration lautet nagiosadmin.

Ihr werdet dann noch nach einem Admin Passwort gefragt, das via htaccess den Zugriff steuert.

Ihr könnt nun Nagios mit einem Browser unter

http://IP_ODER_DEINE_DOMAINE/nagios3

aufrufen.

Solltet Ihr irgendwelche Konfigurationsdateien von Nagios ändern, dann vergesst nicht, nagios mittels

/etc/init.d/nagios3 reload

neu zu starten.

Erste Änderung nach der Installation von Nagios

Ändern des Homeverzeichnis in der /etc/passwd:

nano /etc/passwd

Suchen nach folgender Zeile:

nagios:x:104:106::/var/run/nagios3:/bin/false

Danach diese in

nagios:x:104:106::/home/nagios:/bin/bash

ändern, bzw. besser alte Zeile auskommentieren und diese neu anlegen. Dadurch wird auch für das Erste ein su auf den User nagios ermöglicht, was wir später für die Erzeugung eines privaten und öffentlichen Schlüssels benötigen.

Nun legen wir das neue Homeverzeichnis an:

mkdir /home/nagios

Die korrekten Nutzerrechte:

chown -R nagios:nagios /home/nagios

Erstes Monitoring

Im Netzwerk befindet sich der Server 192.168.0.2 der Server1 heißen soll. Diesen müssen wir erstmal Nagios bekannt machen. Dazu legen wir im /etc/nagios3/conf.d/ eine neue Konfiguration fest:

touch /etc/nagios3/conf.d/server1_nagios2.cfg

Diese editieren wir und füllen die Datei wie folgt:

define host{
        use                     generic-host
        host_name           Server1
        alias                    Server1
        address                 192.168.0.2
        }

Diese Datei wird Dreh- und Angelpunkt für unser Monitoring werden. Aber wir bekommen so erstmal noch nichts zu sehen. Also machen wir einfach mal die Datei /etc/nagios3/conf.d/hostgroups_nagios2.cfg auf. Dort schauen wir uns einmal den folgenden Abschnitt an:

# A list of your web servers
define hostgroup {
        hostgroup_name  http-servers
                alias           HTTP servers
                members         localhost
        }

Hier ist bereits schon der Monitoringdienst für Webserver vordefiniert. Wenn wir immer wieder die gleichen Dienste für verschiedene Server haben, können wir diese Dienst als eine Gruppe auch hier hinterlegen. Das macht Sinn, wenn es besonders viele Server sind. In unserem Fall wollen wir, dass unser Server auch ein Mitglied der http-server wird und damit ein Monitoring auf den http gemacht wird. Ändert dafür den Abschnitt wie folgt ab:

# A list of your web servers
define hostgroup {
        hostgroup_name  http-servers
                alias           HTTP servers
                members         localhost,Server1
        }

Gleiches kann dann auch für die ssh Gruppe usw. gemacht werden. Hierzu müsst Ihr Euch einfach zunächst die fordefinierten Gruppen in dieser Konfigurationsdatei ansehen. Wenn Ihr Eure Änderungen vorgenommen und alles gespeichert habt, müsst Ihr den Nagios wieder neu starten:

/etc/init.d/nagios3 reload

Jetzt sollte Euer Server mit den ersten Diensten im Monitoring sein.

Weitere Dienste einrichten

Im Folgenden werden wir ein paar weitere Dienste einrichten. Diese Dienste werden erstmal recht einfach sein, da sie nicht lokal auf dem Zielrechner ausgeführt werden müssen. Hier bietet sich erstmal der FTP Dienst an.

Jetzt möchten wir erstmal wissen, wie dieser Check genau aussieht und ob dieser bereits definiert ist. Hierzu spitzen wir einfach einmal in das /etc/nagios-plugins/config Verzeichnis. Dort finden wir eine ftp.cfg Datei, die wir zunächst uns einmal näher ansehen:

# 'check_ftp' command definition
define command{
        command_name    check_ftp
        command_line    /usr/lib/nagios/plugins/check_ftp -H '$HOSTADDRESS$'
        }

####
# use these checks, if you want to test IPv4 connectivity on IPv6 enabled syste$
####

# 'check_ftp_4' command definition
define command{
        command_name    check_ftp_4
        command_line    /usr/lib/nagios/plugins/check_ftp -H '$HOSTADDRESS$' -4
        }

Der erstere Aufruf ist für uns interessant. Hier sehen wir, dass das Check Kommando check_ftp heißt.

Jetzt rufen wir wieder unsere /etc/nagios3/conf.d/server1_nagios2.cfg auf. Dort bauen wir folgenden Abschnitt unter unserer Hostdefinition ein:

define service {
        host_name                       Server1
        service_description             FTP
        check_command                   check_ftp
        use                             generic-service
        notification_interval           0 
}

Speichert die Änderung und startet den Nagios neu:

/etc/init.d/nagios3 restart

Schaut Euch im Plugins Verzeichnis ein wenig um, dort findet Ihr sicherlich schnell in den Konfigurationsdateien einen Hinweis darauf, welchen Dienst Ihr bereits einfach einbauen könnt.

Allerdings geht nicht jedes Plugin direkt vom Nagios Server aus, sondern muss auf dem Zielserver teilweise remote ausgeführt werden. Das ist ein wenig tricky, aber das schauen wir uns dennoch gleich einmal an.

Externe Kommandos aktivieren

Um später externe Kommandos abzusetzen muss noch etwas gedreht werden.

Zuerst mittels einem Editor die Zeile check_external_commands=1 in der /etc/nagios3/nagios.cfg setzen.

Folgende Befehle dann an der Konsole absetzen:

/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

Plugin Remote ausführen

Jetzt wird es deutlich kniffeliger, da wir nun einen Check auf den Zielrechner direkt durchführen wollen. Einige Plugins müssen auch entsprechend auf dem Zielrechner gestartet werden, da wir eine Information über den Festplattenstatus, den Serverload etc. nur vom jeweilgen Server direkt geliefert bekommen können.

Dafür müssen wir unseren Zielrechner erstmal einwenig vorbereiten. Die folgenden Schritte werden somit alle erstmal auf dem Zielserver durchgeführt:

a) Nutzer und Gruppe Nagios erzeugen:

groupadd -g 9001 nagios
useradd -u 9001 -g nagios -d /home/nagios -m -c "Nagios Monitoring" nagios

b) Nutzerverzeichnisrechte anpassen:

chown -R nagios:nagios /home/nagios

c) Neues Verzeichnis anlegen:

su nagios
mkdir /home/nagios/.ssh
exit

d) Plugins installieren:

apt-get install nagios-plugins

Das wars dann soweit auf dem Zielrechner. Den Rest machen wir wieder vom Nagios Rechner aus:

Schlüssel erzeugen:

su nagios
cd /home/nagios/.ssh
ssh-keygen -b 1024 -f id_dsa -t dsa -N ''

Das hat zum einen den Schlüssel erzeugt. Damit Nagios auch den Zielrechner als "known-hosts" einträgt, loggt Euch einfach kurz in den Zielrechner ein:

ssh 192.168.0.2

Ihr werdet aufgefordert, den Fingerprint des Zielrechner zu speichern.

Jetzt verlasst wieder den Zielrechner:

exit

Danach den Nutzer nagios:

exit

Wir schieben nun unseren Schlüssel auf den Zielrechner:

scp /home/nagios/.ssh/id_dsa.pub 192.168.0.2:/home/nagios/.ssh/authorized_keys

Jetzt nochmal kurz auf unserem Zielrechner die Rechte angepasst:

chown -R nagios:nagios /home/nagios/.ssh
chmod 700 /home/nagios/.ssh

Das waren soweit erstmal die Vorbereitungen. Wir testen gleich einmal, ob alles klappt. Gebt hierzu auf dem Nagiosrechner folgendes ein:

su nagios
/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_users -w 10 -c 20"

Das sollte Euch nun anzeigen, wieviele User auf dem Zielrechner eingeloggt sind. Ihr dürft an der Stelle nicht mehr nach irgendeinem Passwort gefragt werden. Sollte das dennoch der Fall sein, dann überprüft bitte Eure Installation.

Ihr habt gesehen, dass wir auf dem Nagios Server einen check_by_ssh ausführen und auf dem Zielrechner das entsprechende tatsächliche Plugin. So gestalten wir auch in Zukunft den Aufbau von einem Remote Check. Dies muss aber bevor wir den als normalen Dienst integrieren entsprechend definiert werden. Wir schauen uns dazu wieder das Verzeichnis /etc/nagios-plugins/config an. Dort sehen wir eine load.cfg. Diese Datei öffnen wir einfach mal und sehen uns an, was bereits dort definiert ist:

# 'check_load' command definition
define command{
        command_name    check_load
        command_line    /usr/lib/nagios/plugins/check_load --warning='$ARG1$,$ARG2$,$ARG3$' --critical='$ARG4$,$ARG5$,$ARG6$'
        }

Diese definition ist für einen lokalen Check ausgelegt. Wir fügen nun folgende Zeilen darunter ein:

# 'ssh_check_load' command definition
define command{
        command_name    ssh_check_load
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_load --warning=$ARG1$,$ARG2$,$ARG3$ --critical=$ARG4$,$ARG5$,$ARG6$"
        }

Ihr seht, dass wir ein neues Kommando gebaut haben, das auf den Aufruf ssh_check_load hört. Wir übernemen im Grunde die alte Kommandozeile und erweitern die um den check_by_ssh Aufruf. Diese Erweiterung ist dann auch für alle anderen Plugins gleich. Die alte Zeile wird dann in Hochkommas " " gefasst und bei den Argumenten $ARGS$ die einfachen Hochkommas ' ' weggelassen. Das ist wichtig, da sonst der Auffruf nicht funktioniert! Auch wenn später innerhalb des Remotebefehls das $HOSTADDRESS$ rein muss, müssen wir die einfachen Hochkommas weglassen!

Wir speichern die Änderung und bauen nun den Check in unsere /etc/nagios3/conf.d/server1_nagios2.cfg ein:

define service{
        use                             generic-service 
        host_name                       Server1
        service_description             Current Load
        check_command                   ssh_check_load!5.0!4.0!3.0!10.0!6.0!4.0
}

Hinter unserem ssh_check_load Kommando werden dann die entsprechenden Argumente gesetzt ( $ARGS1$ ... ) und mit Ausrufezeichen getrennt.

Das war's dann auch schon. Startet Nagios neu:

/etc/init.d/nagios3 reload

Templates ändern

Sämtliche Überwachungsoptionen (Checkintervall, wer soll verständigt werden etc.) können natürlich innerhalb der Service eingegeben werden. Das macht allerdings die Konfigurationsdateien auf Dauer ziemlich unübersichtlich. Von daher können auch Templates definiert werden, die dann über das use Kommando eingebunden werden. Hier einmal das Standard Template aus der /etc/nagios3/conf.d/generic-service_nagios2.cfg :

define service{
        name                            generic-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                notification_interval           0               ; Only send notifications on status change by default.
                is_volatile                     0
                check_period                    24x7 ;täglich rund um die Uhr wird geprüft
                normal_check_interval           5 ; alle 5 Minuten wird geprüft
                retry_check_interval            1 ; Bei Fehler wird in einer Minute nochmals geprüft
                max_check_attempts              4 ; 4 Fehlschläge bis Statusmeldung
                notification_period             24x7 ; täglich rund um die Uhr wird gemeldet
                notification_options            w,u,c,r ; Status Warning, Undefiniert, Critical, Recovered wird gemeldet
                contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

Ich habe mal fehlende Erklärungen ergänzt. Wenn Ihr ein neues Template anlegen wollt, dann kopiert diesen Abschnitt und ändert den Templatenamen. Dann könnt Ihr entsprechend weitere Änderungen vornehmen:

define service{
        name                            mein-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                notification_interval           0               ; Only send notifications on status change by default.
                is_volatile                     0
                check_period                    24x7
                normal_check_interval           5
                retry_check_interval            1
                max_check_attempts              3
                notification_period             24x7
                notification_options            w,u,c,r
                contact_groups                  admins,techniker
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

Jetzt könnt Ihr bei den Services entsprechend die Änderungen dort vornehmen, wo es auch geändert werden soll:

define service {
        host_name                       Server1
        service_description             SSH
        check_command                   check_ssh
        use                             mein-service
}

Nach Änderung müsst Ihr Nagios neu laden:

/etc/init.d/nagios3 reload

Diese Templateänderung gilt nur für die Services! Wenn Ihr das Template (generic-host) innerhalb Eurer host - Definition ändern wollt, dann geht analog in der Datei /etc/nagios3/conf.d/generic-host_nagios2.cfg . Kommt nur nicht auf die Idee, ein Service Template innerhalb des host-Abschnitts zu verwenden! Da sollen sich schon Leute fummelig nach den Fehlern gesucht haben

Benachrichtigungen versenden

Das beste Monitoring nützt natürlich nichts, wenn wir nicht über einen Ausfall verständigt werden. Nagios kann das sowohl per Mail als auch per SMS. Der SMS Weg setzt natürlich noch zusätzliche Hardware (ISDN etc.) voraus, weshalb wir uns in unserem Tutorial nur auf die klassische E-Mail beschränken.

Damit aber überhaupt eine Mail von unserer Slug versendet werden kann müssen wir ersteinmal einen Mail Transporter definieren. Aufmerksame Leser meiner Seite kennen eventuell die Vorgehensweise, aber ich liste die notwendigen Schritte dazu gerne nochmal auf.

Die heutigen Debianserver haben als Standard MTA den exim4 hinterlegt. Solltet Ihr eigentlich keinen Mailserver aktiviert haben, könnt Ihr aber dennoch den exim4 dazu verwenden, via eines sogenannten Smarthosts (= externer Mailserver) Eure Nagios Mails verschicken zu lassen.

Um einen Smarthost einzurichten startet die Konfiguration mit einem

dpkg-reconfigure exim4-config

Folgende Konfigurationsschritte:

1.) Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail

2.) Email Name des Systems: Lasst einfach den voreingestellten Domänen Name stehen

3.) IP-Adressen, auf denen eingehende SMTP-Verbindungen erwartet werden: 127.0.0.1

4.) Weitere Ziele, für die die E-Mails angenommen werden sollen: Auch hier den default Domän Namen stehen lassen

5.) Rechner für die die E-Mails weitergeleitet werden sollen (Relay): Leer lassen, wenn nicht ein weiterer Rechner DIESEN Rechner als Smarthost verwendet. Also normal leer lassen.

6.) IP Adresse oder Rechnername der Sendezentrale für ausgehende E-Mails: Hier und genau hier kommt die IP Adresse oder der Rechnername (mail/smtp.xyz) Eures ISP rein!

7.) Lokalen E-Mail Namen in ausgehende Mails verbergen: Ja

8.) Sichtbarer Domänennamen für lokalen Benutzer: Hier gebt eine Adresse ein, die Ihr besitzt (in der Form meinepage.de)

9.) DNS Anfrage minimieren: Ja

10.) Versandart bei lokaler Mailzustellung: Mbox Format in /var/mail/

11.) Einstellungen auf kleine Dateien aufteilen: Nein

Danach startet der MTA neu. Jetzt kann es auch sein, dass Euer Smarthost eine Authentifizierung abverlangt. Diese hinterlegt in der folgenden Datei: /etc/exim4/passwd.client

Hier das Passwort wie folgt hinterlegen:

IP_des_Mailserver_oder_Name:LOGIN:PASSWORT

Die Datei sollte nur lesbar für root sein.

Startet danach den MTA neu:

/etc/init.d/exim4 restart

Soweit so gut. Legt nun einen neuen Kontakt in der Datei /etc/nagios3/conf.d/contacts_nagios2.cfg an. Kopiert einfach dazu den root User Abschnitt und ändert diesen entsprechend Eurer Daten ab:

define contact{
        contact_name                    mein_name
        alias                           Mein_name
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           meine@adresse.mail
        }

Wenn der neue Kontakt definiert ist, fügt diesen dann in den Abschnitt Contact Groups der gleichen Datei mit ein:

define contactgroup{
        contactgroup_name       admins
        alias                   Nagios Administrators
        members                 root,mein_name        
        }

Da der Kontakt root ein "Dummy" ist, könnt Ihr den auch gleich aus der Zeile members löschen.

Wie immer dann den Nagios neu laden:

/etc/init.d/nagios3 reload

Um jetzt zu testen, dass alles klappt, schießt einfach einen Dienst auf Euren Zielserver ab und wartet, bis Ihr eine Mail bekommt. Das dürfte nicht lange dauern

Toter Mysql:

***** Nagios *****

Notification Type: PROBLEM

Service: MYSQL
Host: Server1
Address: 192.168.0.2
State: CRITICAL

Date/Time: Fri Aug 28 20:09:54 CEST 2009

Additional Info:

Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)

MYSQL testen

Eine Spezialität ist das Checken des MYSQL Servers. Das wollen wir auch über einen Remote Zugriff erledigen. Dazu müssen wir aber auf dem Zielrechner eine Datenbank für Nagios und den User Nagios anlegen, der aber nur lesend auf seine Datenbank zugreifen kann. Uns genügt es zu wissen, ob die DB läuft. Also meldet Euch bitte auf Eurem Zielrechner an der mysql Datenbank an:

mysql -u root -p

Nun erzeugen wir eine Datenbank und einen Nutzer

CREATE DATABASE nagiosdb;
GRANT select ON nagiosdb.* TO nagios@localhost;
exit

Nun wenden wir uns dem Nagios Server zu. Dort öffnet die Datei /etc/nagios-plugins/config/mysql.cfg und fügt folgende Zeilen ein:

# 'ssh_check_mysql' command definition
define command{
        command_name    ssh_check_mysql
        command_line      /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_mysql -H localhost -u nagios"
}

Die /etc/nagios3/conf.d/server1_nagios2.cfg wird wie folgt ergänzt:

define service {
        host_name                       Server1
        service_description             MYSQL
        check_command                   ssh_check_mysql
        use                             generic-service
}

Danach nagios neu laden:

/etc/init.d/nagios3 reload

Spezialfall Mail Queues

Um die Mailqueues zu prüfen benötigt man normalerweise Rootrechte. Wie wir wissen werden aber alle Checks nur als User nagios durchgeführt. Um nun remote einen Test durchzuführen, der beispielsweise den Mail Queues eines Exim4 prüft, müssen wir einen neuen Dienst definieren, der folgendes Kommando absetzt:

/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_mailq -w 40 -c 70 -M exim"

Rootrechte hätte man, wenn der Befehl wie folgt aussieht:

/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "sudo /usr/lib/nagios/plugins/check_mailq -w 40 -c 70 -M exim"

Nur nützt uns das wiederum nichts, weil wir hier ein Passwort für Root eingeben müssten.

Um das zu umgehen legen wir auf dem Zielrechner nun fest, dass genau dieser Befehl /usr/lib/nagios/plugins/check_mailq vom User nagios mit Rootrechte ausgeführt werden darf. Das setzt auf dem Zielrechner als root folgenden Befehl ab:

visudo

Sollte dieser nicht funktionieren muss noch sudo installiert werden:

apt-get install sudo
Dort fügt nun eine Zeile ein:

<code><pre>
nagios ALL=(root) NOPASSWD: /usr/lib/nagios/plugins/check_mailq

Speichert die Änderung. Jetzt definiert unter /etc/nagios-plugins/config/mail.cfg ein neues Kommando:

# 'ssh_check-mailq' for exim
define command {
        command_name    ssh_check_mailq_exim
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa -C "sudo /usr/lib/nagios/plugins/check_mailq -w $ARG1$ -c $ARG2$ -M exim"
}

Danach wie gehabt den Service für Euren Host anlegen:

define service {
        host_name                       Server1
        service_description             Mail-Queues
        check_command                   ssh_check_mailq_exim!25!50
        use                             generic-service
}

Die Argumente ( 25 = Warning , 50 = Critical ) können natürlich entsprechend angepasst werden.

Und nun wie gewohnt:

/etc/init.d/nagios3 reload