OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf

Monitoring at large
Die Welt ist nicht genug
OSMC 2011
Referent: Thomas Gelf
Nürnberg, 29.11.2011

Ich und mein Job
 Was Handfestes, Sicheres
 An der frischen Luft

Thema: Skalierbarkeit und Hochverfügbarkeit
 Schwerpunkt: Nagios/Icinga
 Probleme und Grenzen derselben
 Vergleich mit dem Mitbewerb
 Ziel dieser Präsentation:
– Anregungen liefern

Kampf zwischen zwei Fronten
 Beim Kunden
vertrete ich eine
OSS-Lösung
 In den OSS-
Projekten vertrete
ich den Kunden

Tuning
 Tipps
 Mythen und Halbwahrheiten
 Technische Grenzen

Der Blick...
 Über den Zaun
 Auf die Nachbarweide
 In die Ferne

Neue alte Ansätze
 Verworfene oder
vergessene Ideen, Ansätze
und Methoden müssen
nicht immer schlecht sein
 Dumm darf man sein, man
muss sich nur zu helfen
wissen...
 ...besonders wenns mal
irgendwo klemmt und
kratzt

Komponenten einer Monitoring-Umgebung
 Scheduler
 Agents, Plugins, Protokolle, Busse...
 Benachrichtigungen, Alarming, Eskalations
 Historische Daten, Events, Trends, SLAs...
 Frontends

Wer benutzt als Scheduler...
 Nagios
 Icinga
 Shinken
 OpenNMS
 Zabbix
 Ein Closed-Source-Produkt
 Andere?

Wer benutzt als Protokoll...
 NRPE
 NSCA
 SSH
 check_mk
 SNMP
 ICMP
 …

Wer benutzt als Backend...
 Relationale Datenbanken
 Textdateien
 RAM
 RRDs

Wer benutzt als Frontend...
 Nagios/Icinga Classic
 Icinga-Web
 Thruk
 Multisite
 Centreon
 Ninja
 Closed-Source
 Andere?

Und was für...
 Plugins?
 Addons?
 Konfigurationsbackends?
...soll ich aufhören?

Und trotz allem...
 ...es läuft und läuft und läuft

Naja. Jedenfalls...
 ...solange nichts Unvorhergesehenes eintritt.

Erster Schritt: Systemtuning
 Man sollte seine Hardware kennen
 Wichtig für Nagios und Icinga:
– Disk I/O
– Fork Performance
– Und natürlich: RAM. Vor allem wenn IDO/NDO zum
Einsatz kommt

Disk I/O
 Es geht nichts über viele Spindeln, die an einem
schnellen batteriegepufferten Controller in einem RAID
10 am lokalen Bus hängen
 Controller-BIOS
 Passender I/O-Scheduler im Kernel
– Per Kernel-Parameter (elevator)
– Pro device im SYS Filesystem

Schneller Überblick: Durchsatz und Latenzen
 Kein Benchmark, aber erste Werte mit Aussagekraft:
~ # hdparm t /dev/sda
Timing buffered disk reads: 1134 MB in 3.00 seconds = 377.48
MB/sec
~ # dd if=/dev/zero of=/root/tomtest bs=512 count=1000
oflag=direct
1000+0 Datensätze ein
1000+0 Datensätze aus
512000 Bytes (512 kB) kopiert, 0,0786434 s, 6,5 MB/s

Fork performance
 Sollte man messen, um Vergleichswerte zu haben
 Kann die Ursache von Performance-Problemen in Vms
sein
 Quick & Dirty Beispiele:
while true ; do date ; done | uniq c
for i in 1 2 3 4 5; do taskset c 0 spawn 5; done
 Immer nur im Vergleich interessant!

Problem: Shell Skripts
 "Ich benutze doch nicht Perl, wenn ich es mit einem
Shellskript..."
for i in `seq 1 24`; do
XY=`snmpget ... | grep ... | wc l`
OUT="$OUT, $XY"
 Verschärft das Problem
 Aber: es gibt auch Perl-Checks, die `snmpwalk ...`
nutzen

Regelmäßige Benchmarks ein- und durchführen
 Benchmarking neuer Hardware-Plattformen
 Benchmarking in unterschiedlichen Konfigurationen
 Ergebnisse zum Vergleichen aufbewahren
 Mein Favorit: Phoronix Test Suite

Tuning für Nagios/Icinga
 http://docs.icinga.org/latest/de/tuning.html
 use_large_installation_tweaks?
 check_result_reaper_frequency?
 RAM Disk?
 ...und weiter?

Der Reaper ist ein Problem...
 ...das andere nicht haben
 Shinken macht es vor!
 Es gibt mittlerweile auch einen Lösungsansatz dafür im
Icinga-GIT
 Dazu später mehr

Wieviel kann ich eigentlich rausholen?
 Faire Benchmarks sind schwierig
 Glaube keinem, den du nicht selbst...
 cached_*_check_horizon
 Man kann's auch übertreiben:

Hilft eine Ramdisk wirklich?
 Checkresults Ordner
 Status.dat, object.cache, retention.dat?

Hochverfügbarkeit
 Im Grunde simpel. Eine Variante:
– Zwei System überwachen sich gegenseitig
– Beide nutzen dieselbe Konfiguration
• Eines pollt aktiv, ein Eventhandler aktiviert/deaktiviert
die eigenen Checks
• Oder auch: beide immer aktiv, nur die Notifications
werden ein- und ausgeschaltet
 Elegantere Lösungen in Merlin, Shinken...

HA-Cluster
 Vereinfacht den Failover, der Cluster macht alles
 Verkompliziert alles, man muss den Cluster verstehen
 Pacemaker / Corosync, andere
 Shared Storage nötig, DRBD oder ClusterFS
 So viel wie möglich immer auf allen Knoten aktiv!
 So wenig I/O als möglich auf dem Shared Storage
– RRDs
– retention.dat, object.cache

Datenbank hat eigene Replikationsmechanismen
 Es macht Sinn, diese zu benutzen
 Für jeden Master kann ein ido2db Daemon ständig
laufen
 idomod findet bei einem Clusterschwenk schon einen
laufenden Daemon vor

Aktive Checks skalieren nicht...
 …aber auch Umgebungen mit rein passiven Checks
stoßen an Grenzen
 Mit NDO/IDO noch früher

Mehrere Instanzen pro Server
 Mehrere kleine Icingas arbeiten besser als ein großer
 Passive Check-Ergebnisse werden in einen „zentralen“
gekippt
 Lässt sich mit LConf schön steuern

Der Scheduler
 In der Nagios/Icinga-Welt zentral
 Wird von Shinken besser gelöst

Neue Ansätze: icingamq
 Verteilt Checks über X Check-Daemons
 Hierarchien sind möglich
 Entlastet den Core
 Noch pre-beta Status

Was man mit icingamq noch so anstellen könnte
 Man erhält alle Events aus dem Core
 Eine Graphing-Lösung könnte sich an den Bus hängen
 Damit entfällt der Umweg über die Perfdata-Dateien
 SLA-Reporting auslagern

Web-Frontends
 Unterscheiden sich anhand der Arbeitsweise
– status.dat
– IDO/NDO - Datenbank
– Merlin DB
– MK Livestatus

Die status.dat
 Für kleinere Umgebungen wunderbar
 Ist da auch performant sein
 Skaliert aber leider per Design nicht

MK Livestatus
 Guter Ansatz
 Beeindruckende Zahlen
 Aufgaben wie z.B. die Sortierung sind komplex
 Oder: „Zeige mir abhängig von meinen Berechtigungen
jene Services, welche in den letzten X Stunden am
meisten Probleme verursacht haben – sortiert nach
Anzahl der Probleme“

Relationale Datenbanken
 Können skalieren, müssen aber nicht
 Schema von NDO/IDO ist ein Problem
– NDO wurde wohl erdacht, um bequem Objekte
abzulegen...
– ...und nicht um dem Query-Designer das Leben leicht zu
machen
 Merlin ist ein Beispiel dafür, dass es eleganter geht
 Man könnte viel, viel mehr Informationen rausholen
 Es gibt nicht nur relationale Datenbanken

Plugins tunen!
 Die Hauptarbeit wird immer noch von den Plugins
erledigt
 Hier hat man die Möglichkeit, vieles zu drehen

Dependencies nutzen
 Sind umständlich zu konfigurieren
 In LConf aber nett gelöst

Host-Erreichbarkeit
 check_host_alive.
 Wer nutzt check_ping?
 check_icmp?
 check_fping?
 Andere?

Wie häufig wird der Host geprüft?
 Standard-Template: 5 min, 1 min, 10 attempts
 Es dauert 10 Minuten bis ich weiß, dass der Host down
ist
 In der Zeit hat bereits 20x mein Telefon geklingelt
 In anspruchsvolleren Umgebungen prüfen wir 1x pro
Minute...
 ...und auch das ist eigentlich recht wenig

ICMP type 8: Echo request
 12.000 Hosts aktiv im Minutentakt zu pingen...
– Bedeutet für den Nagios/Icinga-Core sehr viele Forks pro
Sekunde
– Mein Laptop kann in der Sekunde 500x date aufrufen
– Mein Laptop kann aber auch 17.000x in der Sekunde in
einem banalen Skript mein Loopback pingen, auf die
Antwort warten, die Dauer berechnen und das Datum
ausgeben
– Mein Laptop kann noch sehr viel mehr in der Sekunde,
wenn er Pings parallel und asynchron ausführt

Warum schreiben wir nicht einen Daemon...
 ...der unsere Hosts per ICMP überwacht...
 ...und stellen all unsere Host-Checks auf PASSIV um?
 Lassen JEDEN Host im 5-Sekunden-Takt pingen
 Beschleunigen den Rhythmus auf eine Sekunde wenn
eine Antwort nicht innerhalb von einer Sekunde
ankommt
 Liefern im 5-Minuten-Rhythums Performance-Daten an
Nagios

Wieviel Traffic bedeutet...
 ...ein Rhythmus von 5 sec, 1 sec, 5 attempts...
 ...für 12.000 Hosts?
???
 Ungefähr 2,5 Mbit/s Nutzdaten bei 64 Byte Payload
 Etwa 5 Mbit/s samt IPv6-Header und Ethernetframe

Und könnte man...
 ...diesen Ansatz nicht auch für check_tcp und
check_udp nutzen?
 Für HTTP-Checks?
 Oder für „teure“ Plugins wie die vmWare Checks?

Kleinvieh macht auch Mist
 Ein gutes Beispiel für teure Checks sind sämtliche
Interface-Table Check-Varianten
 Snmpwalk, jedesmal
 Ein Walk besorgt sich immer einen Wert nach dem
anderen
 Einige Switches antworten sehr langsam

Wie läuft das ab?
 OID: ifTable / ifXTable
– ifIndex, ifInOctets, ifInUcastPkts, ifInNUcastPkts,
ifInDiscards, ifDescr, ifOutErrors, ifOutQLen, ifSpecific,
ifType, ifMtu, ifSpeed, ifPhysAddress, ifAdminStatus,
ifOperStatus, ifLastChange
 Jedesmal wird die vollständige Tabelle abgeholt
 Schnell mal 1000+ sequentielle SNMP-Requests pro
Switch und Check
 Aber brauchen wir das wirklich?

Switch-Überwachung – ein anderer Ansatz
 Ein SNMP-Paket pro Switch im 10 Sekunden-Takt
 Portstatus-Änderungen können so bei 48 Ports in
weniger als einer Minute erkannt werden...
 ...und das ohne nennenswerte Last

Vorschlag, das eleganter zu lösen
 IfIndexes ändern sich nie oder nur bei Reboot
– Merken, sysUptime überwachen!
 Descriptions und Aliases kann ich ab und an mal
abfragen
 ifStatus will ich mit höherer Frequenz:
– snmpbulkget, nicht walk
 Octets, Errors: längere Intervalle

Embedded Perl nutzen
 Zahlt sich aus
 Macht aber erst mal Arbeit
 Es ist nicht schwer, Plugins entsprechend anzupassen
 Man muss es aber machen
 Speicher im Auge behalten!

Mir gefällt check_mk...
 Bedeutet aber im Grunde, dass ich MK konfiguriere,
nicht mehr Nagios oder Icinga
 Der Core wird sukzessive reduziert
 Was vielleicht gar nicht so schlecht ist
 Grundsatzentscheidung

Agenten nehmen Last weg
 check_by_ssh & check_cache
 check_mk
 …
 Bedeuten aber grundsätzlich erst mal
Konfigurationsoverhead

Bottleneck xDO
 Muss jedes Check-Result in die DB?
 Eigentlich reichen ja die Status-Änderungen
 Wie weiß ich dann aber, ob alles noch läuft?

Vertrauen ist gut...
 Status ist rot oder grün
 Seit Zeitpunkt X
 Und das bleibt so, bis es sich ändert

...Kontrolle ist besser
 Die lässt sich aber auch anders lösen
 Prüfen, ob externe Komponenten sauber arbeiten

Und meine Trendgrafiken?
 Müssen die wirklich durch den Core?
 Wunschliste: Subscriptions für Events
 Thema für icingamq, mod_gearman, Shinken...

Benachrichtigungen
 Könnte man doch auch modularisieren
 Ist im Core recht starr
 Es gibt Addons...
 ...die aber gezwungen sind, suboptimal zu arbeiten

WENN wir dann so was haben...
 ...könnten wir die aktuellen Stati ja in einen Key/Value
Store blasen
 Stichwort NoSQL
 Dort würde ich mir auch on-the-fly Aggregationen /
Summaries wünschen

Wichtig: gefühlte Performance im Frontend
 Beispiel Icinga-Web 1.5
– Eigentlich schneller als der Vorgänger, ABER...
– Parallele Requests
– Teure Abfragen

Problem: keine parallelen Requests in 1.5

Mit Fix: parallelen Requests in 1.5

Icinga-Web skalieren
 Klassische LAMP-Anwendung
 APC-Cache
 In 1.6: Sessions in Memcached/Membase
 Dedizierte Datenbank-Slaves

ABER:
 SELECTs können grundsätzlich parallel laufen, aber:
– Sobald eine Schreibquery auf eine langsame Abfrage
wartet, müssen alle darauffolgende SELECTs warten
– Transaction Isolation Level
– Readonly-Slaves helfen nur bedingt
– Jeder Slave muss ALLE Schreib-Transaktionen in einem
einzigen Thread ausführen

Meine persönliche Meinung:
 Wir brauchen unbedingt ein neues Schema
 Vielleicht wäre das ein Thema für die Roadmap von
Icinga 2.0?
 Aus dem Icinga-Projekt sollten die Impulse und
Vorgaben kommen
 Ein modularer Aufbau ermöglicht Drittanwendungen,
dem Core Arbeit abzunehmen

Danke für Ihre Aufmerksamkeit!

OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf

Ähnlich wie OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf (20)

OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf