Nagios installieren und konfigurieren: Unterschied zwischen den Versionen
Admin (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Admin (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 344: | Zeile 344: | ||
<code><pre> | <code><pre> | ||
dpkg-reconfigure exim4-config</pre></code> | dpkg-reconfigure exim4-config</pre></code> | ||
Folgende Konfigurationsschritte: | '''Folgende Konfigurationsschritte:''' | ||
<br /><br /> | <br /><br /> | ||
1.) '''Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail''' | 1.) '''Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail''' | ||
Zeile 427: | Zeile 427: | ||
Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)</pre></code> | Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)</pre></code> | ||
<br /><br /> | |||
==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: | |||
<code><pre> | |||
mysql -u root -p</pre></code> | |||
Nun erzeugen wir eine Datenbank und einen Nutzer | |||
<code><pre> | |||
CREATE DATABASE nagiosdb; | |||
GRANT select ON nagiosdb.* TO nagios@localhost; | |||
exit</pre></code> | |||
Nun wenden wir uns dem Nagios Server zu. Dort öffnet die Datei '''/etc/nagios-plugins/config/mysql.cfg''' und fügt folgende Zeilen ein: | |||
<code><pre> | |||
# '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" | |||
}</pre></code> | |||
Die '''/etc/nagios3/conf.d/server1_nagios2.cfg''' wird wie folgt ergänzt: | |||
<code><pre> | |||
define service { | |||
host_name Server1 | |||
service_description MYSQL | |||
check_command ssh_check_mysql | |||
use generic-service | |||
}</pre></code> | |||
Danach nagios neu laden: | |||
<code><pre> | |||
/etc/init.d/nagios3 reload</pre></code> | |||
<br /><br /> | <br /><br /> |
Version vom 24. Oktober 2012, 18:02 Uhr
Vorwort
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.
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