Warum Monitoren?
- Wissen, dass etwas kaputt ist, bevor Kunden sich beschweren
- Was passierte, dass die Performance in den Keller geht
Was monitoren?
Netzwerk-Monitoring
typischerweise SNMP
Router, Switche, etc.
Service-Monitoring
Läuft mein Webserver?
Genug Platz auf den Festplatten frei?
Welche Intention?
Langfristige Statistiken/Grafiken ("RRDTool") — Analyse
oder
Up/Down mit Nachrichten —
Alerting
Welche Lösung?
Funktionalitäten überschneiden sich
…eine kleine Auswahl
-
Zabbix
Komplett über Webfrontend konfigurierbar
-
OpenNMS
Auto-Discovery von SNMP-Nodes
-
Cacti
Analysetool
-
Munin
Analysetool, oft in Verbindung mit Nagios
Platzhirsch Nagios
Vermutlich meist genutzte Monitoring-Lösung (für Alerting)
Viele Abkömmlinge
- Shinken
- Naemon
- Opsview
- Icinga
Architektur Nagios
(einfaches Szenario)
- Zentraler Daemon
- führt periodisch Plugins aus
- Je nach Status Aktion (Alert)
- Agenten auf Hosts für nicht-öffentliche Daten (z.B. Festplattenspeicher)
- Webinterface
Plugins
einfache Scripte/Programme
Rückgabewert entscheiden (Unix-typisch) über Zustand
- 0 — OK
- 1 — WARNING
- 2 — CRITICAL
- 3 — UNKOWN
Fazit: sehr einfach erweiterbar!
Bonus-Slides
Bei zuviel Zeit
Alerting vollständig konfigurierbar
Abhängig von
- Zustand
- Tageszeit/Wochentag
- Eskalationsstufe
Nachricht…
- an welche Personengruppe?
- per Mail, SMS, Jabber (eigentlich auch nur wieder ein Plugin)
- auch z.B. automatischer Service-Restart möglich
Warum Icinga?
Nagios Enterprise versucht "zwanghaft" zu kommerzialsieren
Marenrechtsdurchsetzungen gegen die Community
Langsame Entwicklung
Akzeptiert wenig/spät Patches
Icinga hat schickeres Web-Interface