Eine performante Überwachungsumgebung ist die Voraussetzung für den erfolgreichen Einsatz von Monitoring im Unternehmen. Christoph Siess diskutiert Parameter anhand derer die Leistungsfähigkeit auf Nagios basierender Monitoring-Systeme gemessen werden kann. Interessant ist die Erkenntnis, dass Nagios-Systeme ohne den Einsatz von 3rd Party Komponenten sehr suboptimal performen. Durch Komponenten wie mod_gearman oder merlin sind erhebliche Performance Verbesserungen messbar. Der Vortag stellt diese Komponenten vor, und gibt Administratoren Anhaltspunkte zur besseren Nutzung ihrer vorhandenen Rechner-Ressourcen. Grundlage dieses Vortrages ist eine Master Thesis die von Christoph Siess in Zusammenarbeit mit Bacher Systems an der FH Technikum Wien im Jahr 2011 erstellt wurde.

2. Performancevergleich Nagios-Systeme
OSMC 2011, Nürnberg
Christoph Siess, MSc xs@bacher.at

3. Agenda

4. • Christoph Siess, MSc
• Consultant bei Bacher Systems
• Themen: Monitoring, ITSM
• 10 Jahre OpenSource
• 5 Jahre Nagios
• 2 Jahre op5 (Professional Partner)
• Diplomarbeit: „Vergleich von
Nagios und Shinken im Kontext
von Cloud Computing“
Kurzportrait

5. Zentrale Bedeutung von Monitoring
Information- &
Access Security
Application
Delivery
Unified
Storage
Virtualization
&
Computing

6. Anforderungen unsere Kunden
Applikationen Server DatenbankenNetzwerk Cloud Virtualisierung
Daten sammeln
Verfügbarkeit und Performance
IT Services
Business Prozesse – „Operational Control“

7. Performancevergleich Nagios-Systeme
OSMC 2011, Nürnberg
Christoph Siess, MSc xs@bacher.at

8. Kernfrage:
Der Nagios Scheduler – die große Unbekannte?
Vorgehensweise:
Lasttests am Nagios Core
Vergleich mit neuen Technologien
Einleitung

9. • Wie kann eine Nagios-Umgebung simuliert werden?
• Welche Einflussfaktoren auf den Nagios Core gibt es?
• Wie werden diese gemessen?
• Welche alternative Ansätze könnten interessant sein?
Welche Fragen gilt es im Vorhinein zu klären?

10. Einleitung - Betrachtung als vereinfachtes System
Nagios
Input Output

11. • Betrachtung als Greybox
– Wir wissen zwar über die Nagios Internals bescheid, darauf gehen
wir aber nicht näher ein.
– Wir ändern Parameter „von außen“ und betrachten „von außen“
wie sich das System verhält.
– Ziel ist es nicht den Nagios Kern auf Code Level zu analysieren.
Einleitung - Vorgangsweise

12. • CPU bzw. Load
– Können alle Prozesse in der Run Queue bedient werden?
• Nagios Latency
– Dauer zwischen geplantem und tatsächlich durchgeführtem
Zeitpunkt der Ausführung eines Checks.
• Memory
– Reicht der Hauptspeicher aus?
Einleitung – Gemessene Parameter

13. • Latency
– nagiostats (status.log)
– Cronjob (minütlich)
• CPU | Memory
– sar (Intervall 5 Sekunden)
– sadf zur Auswertung
• Grafiken
– Perl zur Datenaufbereitung
– Gnuplot zum Zeichnen
Einleitung – Wie wird gemessen?

14. Einleitung - Betrachtung als System
Nagios
• CPU/Load
•Memory
• Latency
Input Output

15. • Faktoren die sich im System ändern
– Anzahl der Nagios Checks
– Durchlaufzeit der Nagios Checks
– Rückgabewerte der Nagios Checks
• Anforderungen an die Simulation
– Die genannten Faktoren müssen veränderbar sein
– Wenig CPU Load durch die Simulation
Einleitung – Wie das System simulieren?

16. – ./sampler_get_warning_critical.pl
• Wechselt im definierten Intervall zwischen OK/Warning/Critical
• Initialisiert sich mit einem Offset für diesen Wechsel
• Schläft rand(10) Sekunden bei jedem Aufruf
• Ist billig in der CPU Nutzung:
– real 0m3.011s
– user 0m0.003s
– sys 0m0.006s
• Keine Performancedaten
Einleitung – Simulations Check

17. Einleitung - Betrachtung als System
Nagios
• Anzahl Checks
• Return Codes
• Laufzeit
• CPU/Load
•Memory
• Latency
Input Output

18. • Icinga
– Nagios Fork mit neuen Features
• mod_gearman
– Eventbroker Modul zur Verteilung von Checks
• Merlin
– Ähnlicher Ansatz wie mod_gearman
• Shinken
– Rewrite in Python
Einleitung – neue Technologien zur Performanceoptimierung

19. • Greyboxtest zu Bestimmung von:
– CPU, Memory, Latenz
• Parameter:
– Durchlaufzeit der Checks
– Anzahl der Checks
– Status der Checks
• Vergleich Nagios, mod_gearman, Icinga, Merlin, Shinken
Einleitung - Zusammenfassung

20. Tests: zwei Kategorien
• Kurzzeittests
– Geben Aufschluss über das Verhalten des Nagios Schedulers bei
Änderungen der Parameter
• Vergleichstests
– Dienen dazu, verschiedene Technologien miteinander zu
Vergleichen.

21. • Test 1: Auswirkung der CPU Performance
• Test 2: Durchlaufzeit der Checks
• Test 3: Rückgabewerte der Checks
• Hardware: VMs auf ESX Basis, 1.5 GHz, 512 MB Ram
Tests – Kurzzeittests

22. • Fragestellung 1:
– Wie wirken sich die CPU Performance auf die Systemumgebung
aus?
• Vorgangsweise:
– Erhöhen der Anzahl der Checks schrittweise
– Checks werden jeweils 1x pro Minuten ausgeführt
– Checks geben zu 100% OK zurück
– Return des Checks sobald wie möglich
– Keine Sleeps
Kurzzeittest Test 1: Vanilla Nagios (3.2.1)

23. Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU
2200 Checks
1000 1400
Lastgrenze

24. Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU
2200 Checks
1000 1400 1800
Lastgrenze
1000
1400
2200 Checks

25. Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU
2200 Checks
1000 1400 1800
Lastgrenze
1000
1400
2200 Checks
1000 1400
2200 Checks

26. • Erkenntnisse:
– Je mehr Checks ausgeführt werden, desto höher ist die CPU Last
– Sobald die CPU am Limit ist steigt die Latency sprunghaft
– Ergo – mit zwei CPUs sollte die Performance wieder OK sein ->
Anzahl der Checks bleibt bei 2200 pro Minute
Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU

27. Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 2 CPUs
Doppelte CPU Latenz wieder OKVergleich  Eine CPU

28. Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 2 CPUs
Doppelte CPU  Latenz wieder OKVergleich  eine CPU

29. • Fragestellung 2:
– Wie wirkt sich die Ausführungsdauer der Checks auf die
Systemleistung aus?
• Hintergrund:
– Viele Remote Checks belasten das System nicht direkt,
verlangsamen aber die Ausführung der Checks
• Vorgangsweise:
– Checks werden durch sleep(rand(10)) verlangsamt
Kurzzeittest 2: Vanilla Nagios (3.2.1), Ausführdauer der Checks

30. Kurzzeittest 2: Vanilla Nagios (3.2.1), 2 CPUs, 2200 Checks, Delay bei Checks
Latency nach dem Delay: ~ 5 SekundenLatency vor dem Delay: ~ 1 Sekunden

31. Kurzzeittest 2: Vanilla Nagios (3.2.1), 2 CPUs, 2200 Checks, Delay bei Checks
CPU seitig keine Auswirkung

32. • Erkenntnisse:
– Die Zeit die ein Plugin in der Ausführung braucht beeinflusst direkt
die Latency des Systems
– Aus Sicht der CPU ergibt sich keine Änderung
Kurzzeittest 2: Vanilla Nagios (3.2.1), 2 CPUs, 2200 Checks, Delay bei Checks

33. • Fragestellung 3:
– Wie wirkt sich der Rückgabewert der Checks auf das System aus?
• Hintergrund:
– Wenn ein Check immer „OK“ ist muss der Nagios-Core weniger
Arbeit leisten, als wenn der Check „WARNING“ oder „CRITICAL“
zurück gibt.
• Vorgangsweise:
– 10% der Checks wechseln zwischen OK, WARNING, CRITICAL
Kurzzeittest 3: Vanilla Nagios (3.2.1), Statuscodes der Checks

34. Kurzzeittest 3: Nagios (3.2.1), 2 CPUs, 2200 Checks, verschiedene Status
90% liefern OK, 10% schwanken
zw. OK/WARNING/CRITCIAL100% liefern OK

35. • Erkenntnisse:
– Das Ausführen der Checks ist die eine Sache
– Ob und wie auf den Status reagiert werden muss beeinflusst das
System sehr stark.
Kurzzeittest 3: Nagios (3.2.1), 2 CPUs, 2200 Checks, verschiedene Status

36. • Erkenntnisse:
– Sobald die CPU 100% ausgelastet ist steigt die Latency sprunghaft
– Je länger Checks in der Ausführung brauchen, desto schlechter ist
das für die Latency, nicht jedoch für die CPU
– Je mehr Checks einen Returncode ungleich OK zurück liefern,
desto mehr Last ergibt das für den Nagios Core
Kurzzeittests - Zusammenfassung

37. • Vergleich verschiedener Technologien über einen
längeren Zeitraum:
• Test1: Plain Nagios vs. Nagios/mod_gearman vs. Shinken
• Test2: Langzeittest Icinga, Merlin, Plain Nagios
• Test3:Langzeittest Merlin 1 vs. 2 Nodes
• Hardware: P4 3.0 GHz 2Core, 1.5 GB Ram
Vergleichstests unterschiedliche Technologien

38. Test1: Nagios (3.2.1), vs. Nagios mit mod_gearman
• Fragestellung:
– Gibt es Performanceunterschiede zwischen Nagios, mod_gearman
und Shinken
• Vorgangsweise:
– 2200 Checks pro Minute
– Checks geben zu 90% OK zurück
– Vergleich Nagios vs Nagios mit mod_gearman
– Vergleich Nagios mit mod_gearman vs. Shinken

39. Test1: Nagios (3.2.1), vs. Nagios mit mod_gearman
Aus dem Kurzzeittest:
2200 Checks pro Minute, 10% wechseln den
Returncode ohne mod_gearman
Gleiche Ausgangslage, ganz andere Kurve
mit mod_gearman

40. Test1: Nagios (3.2.1), vs. Nagios mit mod_gearman
Zoom zeigt: Latency Sinkt von ~ 7 Sekunden auf 0.5 Sekunden

41. Test1: Nagios (3.2.1), vs. Nagios mit mod_gearman
Aus dem Kurzzeittest:
2200 Checks pro Minute, 10% wechseln den
Returncode ohne mod_gearman
Wesentlich geringere CPU Auslastung
(gleiches Setup mit mod_gearman)

42. Test1: Nagios (3.2.1) mit mod_gearman vs. Shinken
Rechts: ShinkenLinks: mod_gearman

43. Test1: Nagios (3.2.1) mit mod_gearman vs. Shinken
Rechts: ShinkenLinks: mod_gearman

44. Test1: Nagios (3.2.1) mit mod_gearman vs. Shinken
• Erkenntnisse durch den Einsatz von mod_gearman:
– Wesentlich geringere Latenz (7 Sekunden vs. 0.5 Sekunden)
– Geringere CPU Auslastung:
• Nagios: 80% System
• mod_gearman: 20% System, 5% User
• Erkenntnisse durch den Einsatz von Shinken:
– Ähnliche Verbesserungen zu mod_gearman
– Etwas mehr CPU Last

45. Test2: Icinga vs. Nagios vs. Merlin
• Fragestellung:
– Wie unterscheiden sich die „Big Player“
• Vorgangsweise:
– Sehr hohe Checkanzahl: 60 000 Checks pro Minute
– Checks wechseln zw. OK/Warning/Critical
– Delay von sleep(rand(10))
– Vergleich Icinga vs. Nagios
– Vergleich Merlin vs. Nagios

46. Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Icinga

47. Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Icinga

48. Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Merlin

49. Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Merlin

50. Test2: Icinga vs. Nagios vs. Merlin
• Erkenntnisse
– Alle drei Systemen verhalten sich sehr ähnlich

51. Test3: Merlin Single vs. 2 Nodes
• Fragestellung:
– Wie wirkt sich ein zweites System auf die Last aus?
• Vorgangsweise:
– 2200 Checks pro Minute
– Checks geben zu 90% OK zurück
– Vergleich Merlin Single Node vs. 2 Nodes

52. Test3: Merlin Single vs. 2 Nodes
Rechts: Merlin zwei NodesLinks: Merlin Single Node

53. Test3: Merlin Single vs. 2 Nodes
Rechts: Merlin zwei NodesLinks: Merlin Single Node

54. Test3: Merlin Single vs. 2 Nodes
• Erkenntnisse Loadbalancing
– Zwei Nodes bedeuten doppelt so viel Performance
– Die Load ändert sich durch das Verteilen wenig

55. Vergleich Technologien - Zusammenfassung
• Nagios / Icinga / Merlin performen in der
Standardkonfiguration fast gleich
• Durch den Einsatz von mod_gearman ist ein
Performancesprung erreichbar

56. • Anderes Design:
– Kleine Workerthreads vs. (double) Fork des Nagios Cores
– Entkoppelt Checkausführung vom Core
– Checks werden direkt dem Core rückgemeldet
• Aber:
– Single Point of Failure
Warum performt mod_gearman/Shinken so viel besser?

57. • Single Point of Failure bei mod_gearman
– Ein zentraler gearmand notwendig
• Merlin
– Autarke Master Systeme, durch Peering Redundant
• Das beste aus beiden Welten
– Performance Vorteil durch mod_gearman
– Redundanz durch Merlin
Ein Ansatz – Merlin mit mod_gearman

58. • Komplexität in O-Notation
– O(c + 3n) Nagios vs. O(c + n) mod_gearman
• Die gute Nachricht (Timeline Q1/2012):
Reaktionen / Ausblick in die Zukunft
The primary thing to be aware of is that we're very well aware of where
the bottlenecks in Nagios reside, and the reason mod_gearman and shinken
both currently outperform vanilla.
Fixing them is not hard, so that that vanilla Nagios will undoubtedly
outperform both shinken and mod_gearman in future versions.
(Andreas Ericsson)

59. Eins noch:
– Nagvis Backend für Business Process AddOns sponsored by
Bacher Systems: http://goo.gl/sftJO
– Ab Version 1.6rc2 in Nagvis