Überblick zu Monitoring-Möglichkeiten

Monitoring mit Icinga

Elmar Athmer elmar@athmer.org

@oxyfodu

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
Icinga Tactical Overview

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

ENDE