Sobald man eine Anzahl Server und andere Netzwerkgeräte zu administrieren hat, kommt man beim Thema monitoring nicht vorbei. Damit lässt sich beispielsweise überwachen ob ein Webserver noch läuft, ob der Toner im Drucker schon verbraucht ist und vieles mehr. Wir werden hier einen Nagios monitoring Host aufsetzen und schritt-für-schritt dessen Funktionalität erklären.
Einführung
todo
Die Standard-Konfiguration in Nagios ist jedoch etwas suboptimal aufgebaut und sieht vor, dass man für jeden Host eine Konfigurationsdatei hat in der die Services gleich definiert sind. Dies hat dann jedoch den Nachteil, dass man häufig verwendete Servicechecks bei jedem Host wieder neu definieren muss, was mit der Zeit sehr unübersichtlich und mühsam wird.
Wir werden deshalb ein besonderes Augenmerk auf eine professionelle Konfiguration richten, die auch in grossen, professionellen Umgebungen hält.
Nagios und die Objekte…
In Nagios ist alles als ein sogenanntes „Objekt“ definiert; diese kann man sich wie die Objekte bei der Programmierung vorstellen.
Man definiert zuerst ein sog. „Objekt-Template“; dieses hat dann schon mal die Grundlegenden Eigenschaften, wie Benachrichtigungs-Intervall, Kontaktgruppen an den die Benachrichtigung gesendet wird, usw.
Dann erstellt man für die verschiedenen Subtypen weitere Objekte, die dann die Eigenschaften des vorherigen Objektes „erben“. Diese Eigenschaften kann man dann überschreiben und/oder noch zusätzliche Eigenschaften hinzufügen.
Die Standard-Definitionen befinden sich in der Datei „templates.cfg“.
Hier findet man Objekt-Vorlagen (templates) zu den typen: contacts, contactgroups, hosts, hostgroups und services.
Schauen wir uns mal ein Beispiel für einen Host an:
define host{
name generic-host ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host 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_period 24x7 ; Send host notifications at any time
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
}
Wir möchten nun einen Host für die Linux-Server machen, der genau so eingestellt ist wie „generic-host“, mit zwei Ausnahmen:
- Die Benachrichtigungen sollen nur während den Arbeitszeiten verschickt werden (workhours)
- Die Benachrichtigungen sollen nur an Leute in der Kontakgruppe „linux-admins“ verschickt werden
Dies würde dann so aussehen:
define host{
name linux-server
use generic-host
notification_period workhours
contact_groups linux-admins
register 0
}
Mit dem Keyword „use“ sagt man hier, dass man alles von „generic-host“ übernehmen will, danach definiert man „notification_period“ neu und fügt „contact_groups“ hinzu.
Und bei der Definition eines Hosts verwendet man dann dieses template, wieder mit „use“ (aber ohne „register“ am Schluss!) wie folgt:
define host{
use linux-server
host_name host1
alias host1
address XX.XX.XX.XX
}
Nun noch eine kurze Beschreibung der verschiedenen Objekttypen:
Objekttypen
contacts / contactgroups
Jede Person, die nagios benutzt muss als ein Kontakt-Objekt definiert sein; die grunsätzlichen Parameter sind: name, email und evtl. pager (handy/sms) Nummer.
Mehrere Kontakte können in einer Kontakgruppe zusammen gefasst werden, z.B. „linux-admins“.
Nagios benutzt diese Informationen hauptsächlich um Benachrichtigungen zu versenden; als Benachrichtigungsempfänger kann man entweder nur einen einzelnen Kontakt oder eine ganze Kontaktgruppe angeben.
[stextbox id=“note“ caption=“Hinweis“]Jede Person, die auch das Nagios-Frontend verwenden möchte, muss zusätzlich in der Datei: /etc/nagios/htpasswd.users stehen.
Um nun einen Benutzeraccount fürs Frontend zu erstellen benutzt man am besten das Programm htpasswd:
htpasswd /etc/nagios/htpasswd.users USERNAME |
htpasswd /etc/nagios/htpasswd.users USERNAME
[/stextbox]
hosts / hostgroups
Wie die Kontakte muss jeder Host, den man überwachen möchte als Host-Objekt definiert sein. – Man kann hier auch wieder mehrere Hosts in einer Hostgruppe zusammenfassen; dies macht vor allem da Sinn wo man gewisse checks für mehrere Hosts gleichzeitig machen mcöhte.
[stextbox id=“note“ caption=“Hinweis“]Eine gute Idee ist es deshalb für alle Hosts die ähnlich konfiguriert sind eine Gruppe zu machen, beispielsweise „centos“ oder „ubuntu“.[/stextbox]
services [[service groups]
Für jeden „Service“ (z.B. http, ssh oder backup) den man überwachen möchte, muss man nun noch ein Service-Objekt definieren.
In diesem Objekt kann man auch wieder definieren an wen die Benachrichtigungen gehen sollen (contact,contactgroup) und auf welchen Host der Service überwacht werden soll.
Man kann hier auch wieder „Service-Gruppen“ machen, doch das wird in der Regel sehr selten verwendet.
Installation
Die Installation wurde auf einem CentOS-System gemacht, kann aber natürlich für alle weiteren Systeme 1:1 umgsetzt werden; lediglich Paketmanager und Paketnamen unterscheiden sich jeweils geringfügig.
Zuerst installieren wir nagios, nagios-plugins und nrpe:
yum install icinga icinga-gui icinga-idoutils nagios-plugins nagios-plugins-setuid nagios-plugins-nrpe
Konfiguration
Überlegungen
Da die Konfiguration eines Nagios-Systems bereits nach kurzer Zeit sehr komplex werden kann, macht es Sinn eine gescheite Struktur aufzubauen.
Grundsätzlich werden wir alle Konfigurations-Dateien in Verzeichnis /etc/conf.d/ haben; möchte man nun aber noch externe Netzwerke (z.B. die von Kunden) überwachen sollte man diese nicht mit den „eigenen“ mischen; stattdessen würde man ein Verzeichnis /etc/conf.d.KUNDE anlegen und diese in der Datei /etc/nagios/nagios.cfg als cfg_dir eintragen.
Danach gibt es zwei sinnvolle Konfigurationen, welche man nimmt hängt von den individuellen Vorlieben ab; diese werde ich hier kurz erklären:
Wenige, grosse Konfigurationsdateien
Bei dieser Konfiguration würde man eine Datei für alle Kontakte-, eine für alle Hosts-, eine für alle Hostgruppen-, eine für alle Services- und eine Datei erstellen die dann die Checks den Hosts zuweist.
Diese Struktur würde so aussehen:
/etc/nagios/
|-- cgi.cfg
|-- conf.d
| |-- checks.cfg
| |-- commands.cfg
| |-- contacts.cfg
| |-- hostgroups.cfg
| |-- hosts.cfg
| |-- services.cfg
| |-- templates.cfg
| `-- timeperiods.cfg
|-- htpasswd.users
|-- nagios.cfg
|-- nrpe.cfg
`-- resource.cfg
Viele kleine Konfigurationsdateien
Bei der zweiten Konfiguration würde man für Kontakte-, Hosts-, Hostgruppe- und Services je ein Verzeichnis erstellen und darin für jeden Service eine Datei. Dies sähe dann so aus:
/etc/nagios/
|-- cgi.cfg
|-- conf.d
| |-- contactgroups
| | |-- admins.cfg
| | `-- linux-admins.cfg
| |-- contacts
| | |-- Hans_Muster.cfg
| | |-- John_Doe.cfg
| | `-- nagiosadmin.cfg
| |-- hostgroups
| | `-- linux.cfg
| |-- hosts
| | |-- host1.cfg
| | |-- host2.cfg
| | `-- host3.cfg
| |-- misc
| | |-- commands.cfg
| | |-- templates.cfg
| | `-- timeperiods.cfg
| `-- services
| |-- backup.cfg
| |-- http.cfg
| |-- load.cfg
| |-- ping.cfg
| |-- ssh.cfg
| `-- yum.cfg
|-- htpasswd.users
|-- nagios.cfg
|-- nrpe.cfg
`-- resource.cfg
Für welche der beiden Varianten man sich entscheidet ist egal, beide sind sehr flexibel und auch in grossen Umgebungen noch übersichtlich. Ich werde später die Konfiguration beider Varianten erklären, machen muss/kann man natürlich nur eine. 😉
Zuerst jedoch erstellen wir mal die Basisstruktur.
Basisstruktur
Da wir die Konfiguration von vorne beginnen, ist es ratsam, sich das Originalverzeichnis erst mal zu kopieren; dies kann später wieder gelöscht werden, wenn die neue Konfiguration läuft:
cp -pvR /etc/nagios /etc/nagios.orig
Nun erstellen wir die neue Struktur:
mkdir -pv /etc/nagios/conf.d/
cd /etc/nagios/objects/
mv -v commands.cfg templates.cfg timeperiods.cfg /etc/nagios/conf.d/
cd ~
rm -rfv /etc/nagios/objects
rm -fv /etc/nagios/command-plugins.cfg
Nun öffnen wir die Datei: /etc/nagios/nagios.cfg
Darin wird erstmal alles was „cfg_dir“ und „cfg_file“ ist gelöscht, oder auskommentiert; dann fügen wir die Zeile:
cfg_dir=/etc/nagios/conf.d
hinzu.
Nun muss man sich für eine der beiden Varianten entscheiden:
Variante 1: Wenige grosse Dateien
Variante 2: Viele kleine Dateien
Erstellen wir zuerst die Verzeichnisstruktur:
mkdir -pv /etc/nagios/conf.d/{contactgroups,contacts,hostgroups,hosts,misc,services}
cd /etc/nagios/conf.d/
mv -v commands.cfg templates.cfg timeperiods.cfg /etc/nagios/conf.d/misc/
Für jeden Benutzer, der nagios benutzen soll, erstellen wir nun eine contacts-Datei (der „Standardkontakt“ nagiosadmin sollte auch erstellt werden):
/etc/nagios/contatcs/nagiosadmin.cfg
define contact{
contact_name nagiosadmin ; Short name of user
use generic-contact ; Inherit default values from generic-contact template (defined above)
alias Nagios Admin ; Full name of user
email admin@localhost ; <<__* CHANGE THIS TO YOUR EMAIL ADDRESS ____
}
Nun erstellen wir eine Kontaktgruppe:
/etc/nagios/contactgroups/admins.cfg
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members nagiosadmin
}
Für jeden Host, den wir Monitoren wollen, erstellen wir eine Hosts-Datei:
/etc/nagios/conf.d/hosts/host1.cfg
define host{
use linux-server
host_name host1
alias FileServer
address XX.XX.XX.XX ; << IP-Adresse des Servers
}
Nun erstellen wir noch eine Hostgruppe für alle Linux-Server:
/etc/nagios/hostgroups/linux.cfg
define hostgroup{
hostgroup_name linux ; The name of the hostgroup
alias Linux Servers ; Long name of the group
members host1, host2, host3 ; Comma separated list of hosts that belong to this group
}
Und zu guter Letzt erstellen wir noch für jeden Service, den wir überwachen wollen eine Datei in: /etc/nagios/services/
Hier ein Beispiel für check_http, der überprüft ob ein Server per HTTP erreichbar ist:
/etc/nagios/conf.d/services/http.cfg
define command{
command_name check_http
command_line $USER1$/check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$
}
define service{
use generic-service
host_name server1
service_description HTTP
check_command check_http
}
[stextbox id=“note“ caption=“Hinweis“]Anstatt host_name könnten wir den Check mit hostgroup_name auch auf der ganzen Gruppe-, oder mit „host_name *“ auf sämtlichen Hosts ausführen.[/stextbox]
Benutzung
Neuer Host hinzufügen:
Um dieser Konfiguration einen neuen Host hinzu zu fügen müssen wir:
- Eine Datei für diesen Host in /etc/nagios/conf.d/hosts/ anlegen
- Diesen Host zu den passenden Hostgruppen in /etc/nagios/conf.d/hostgroups/ hinzufügen
- Den Host in all den entsprechenden Dateien in /etc/nagios/conf.d/services/ hinzufügen, oder, sollte noch kein entsprechender Service vorhanden sein, diesen anlegen
[stextbox id=“note“ caption=“Hinweis“]Falls der neue Host bereits in einer Hostgruppe ist, die mit einem Service verbunden ist, muss dieser nicht noch einzeln für den Host definiert werden.[/stextbox]
Erweiterungen
pnp4nagios
Mit pnp4nagios lassen sich die performancedaten der plugins in schöne Graphen darstellen.
Zuerst bereiten wir als root die Umgebung vor:
yum install rrdtool rrdtool-perl
mkdir -v /usr/local/src/icinga && chown -v icinga:icinga /usr/local/src/icinga
Nun wechseln wir zum icinga user:
cd /usr/local/src/icinga/
wget http://sourceforge.net/projects/pnp4nagios/files/PNP-0.6/pnp4nagios-0.6.21.tar.gz/download
tar -xvzf pnp4nagios-0.6.21.tar.gz && rm -v pnp4nagios-0.6.21.tar.gz
cd pnp4nagios-0.6.21/
./configure --with-nagios-user=icinga --with-nagios-group=icinga --bindir=/usr/local/bin --libexecdir=/usr/local/libexec/pnp4nagios --sysconfdir=/etc/icinga/pnp4nagios --localstatedir=/var/local/pnp4nagios --libdir=/usr/local/lib/pnp4nagios --datarootdir=/usr/local/share/pnp4nagios
make all
Nach dem configure script sollte man die Ausgabe kontrollieren, insbeosndere ob die Pfade stimmen.
Danach noch (als root) installieren:
sudo make fullinstall
Nun sollte man die Datei: /etc/httpd/conf.d/pnp4nagios.conf kontrollieren, ggf. anpassen und apache neu starten:
/etc/init.d/httpd restart
Nun muss man die zwei (schon vorhandenen) commands in: icinga/commands.cfg kontrollieren (Pfade!):
define command {
command_name process-service-perfdata
command_line /usr/bin/perl /usr/local/libexec/pnp4nagios/process_perfdata.pl
}
define command {
command_name process-host-perfdata
command_line /usr/bin/perl /usr/local/libexec/pnp4nagios/process_perfdata.pl -d HOSTPERFDATA
}
Nun kann man mittels Aufruf von: http://example.net/pnp4nagios die Ausgabe kontrollieren.
Ist alles ok, können wir noch das install.php file disablen:
mv -v /usr/local/share/pnp4nagios/install.php /usr/local/share/pnp4nagios/install.php.ignore
Um bereits im GUI eine vorschau zu erhalten, muss noch ein SSI-File kopiert werden:
cp -v /usr/local/src/icinga/pnp4nagios-0.6.21/contrib/ssi/status-header.ssi /usr/share/icinga/ssi/
Nun erstellen wir ein template um die Graphen einzufügen in icinga/templates.cfg:
define service {
name pnp-link-popup
icon_image ../invisible.png' border="0"</a> <A target="_blank" href="/pnp4nagios/graph?host=$HOSTNAME
amp;srv=$SERVICEDESC
quot; class="tips" rel="/pnp4nagios/popup?host=$HOSTNAME
amp;srv=$SERVICEDESC
amp;view=0"><img src="../images/trends.gif" register 0 }
Um nun einen Service für die Performance-Auswertung zu aktivieren, reicht es das template „pnp-link-popup“ hinzuzufügen:
use OTHER_TEMPLATES, pnp-link-popup
Quellen
