SlideShare ist ein Scribd-Unternehmen logo
1 von 59
Downloaden Sie, um offline zu lesen
Performancevergleich Nagios-Systeme
OSMC 2011, Nürnberg
Christoph Siess, MSc xs@bacher.at
Agenda
• 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
Zentrale Bedeutung von Monitoring
Information- &
Access Security
Application
Delivery
Unified
Storage
Virtualization
&
Computing
Anforderungen unsere Kunden
Applikationen Server DatenbankenNetzwerk Cloud Virtualisierung
Daten sammeln
Verfügbarkeit und Performance
IT Services
Business Prozesse – „Operational Control“
Performancevergleich Nagios-Systeme
OSMC 2011, Nürnberg
Christoph Siess, MSc xs@bacher.at
Kernfrage:
Der Nagios Scheduler – die große Unbekannte?
Vorgehensweise:
Lasttests am Nagios Core
Vergleich mit neuen Technologien
Einleitung
• 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?
Einleitung - Betrachtung als vereinfachtes System
Nagios
Input Output
• 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
• 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
• 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?
Einleitung - Betrachtung als System
Nagios
• CPU/Load
•Memory
• Latency
Input Output
• 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?
– ./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
Einleitung - Betrachtung als System
Nagios
• Anzahl Checks
• Return Codes
• Laufzeit
• CPU/Load
•Memory
• Latency
Input Output
• 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
• 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
Tests: zwei Kategorien
• Kurzzeittests
– Geben Aufschluss über das Verhalten des Nagios Schedulers bei
Änderungen der Parameter
• Vergleichstests
– Dienen dazu, verschiedene Technologien miteinander zu
Vergleichen.
• 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
• 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)
Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU
2200 Checks
1000 1400
Lastgrenze
Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 1 CPU
2200 Checks
1000 1400 1800
Lastgrenze
1000
1400
2200 Checks
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
• 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
Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 2 CPUs
Doppelte CPU Latenz wieder OKVergleich  Eine CPU
Kurzzeittest Test 1: Vanilla Nagios (3.2.1), Anzahl Checks variabel, 2 CPUs
Doppelte CPU  Latenz wieder OKVergleich  eine CPU
• 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
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
Kurzzeittest 2: Vanilla Nagios (3.2.1), 2 CPUs, 2200 Checks, Delay bei Checks
CPU seitig keine Auswirkung
• 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
• 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
Kurzzeittest 3: Nagios (3.2.1), 2 CPUs, 2200 Checks, verschiedene Status
90% liefern OK, 10% schwanken
zw. OK/WARNING/CRITCIAL100% liefern OK
• 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
• 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
• 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
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
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
Test1: Nagios (3.2.1), vs. Nagios mit mod_gearman
Zoom zeigt: Latency Sinkt von ~ 7 Sekunden auf 0.5 Sekunden
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)
Test1: Nagios (3.2.1) mit mod_gearman vs. Shinken
Rechts: ShinkenLinks: mod_gearman
Test1: Nagios (3.2.1) mit mod_gearman vs. Shinken
Rechts: ShinkenLinks: mod_gearman
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
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
Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Icinga
Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Icinga
Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Merlin
Test2: Icinga vs. Nagios vs. Merlin
Rechts: NagiosLinks: Merlin
Test2: Icinga vs. Nagios vs. Merlin
• Erkenntnisse
– Alle drei Systemen verhalten sich sehr ähnlich
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
Test3: Merlin Single vs. 2 Nodes
Rechts: Merlin zwei NodesLinks: Merlin Single Node
Test3: Merlin Single vs. 2 Nodes
Rechts: Merlin zwei NodesLinks: Merlin Single Node
Test3: Merlin Single vs. 2 Nodes
• Erkenntnisse Loadbalancing
– Zwei Nodes bedeuten doppelt so viel Performance
– Die Load ändert sich durch das Verteilen wenig
Vergleich Technologien - Zusammenfassung
• Nagios / Icinga / Merlin performen in der
Standardkonfiguration fast gleich
• Durch den Einsatz von mod_gearman ist ein
Performancesprung erreichbar
• 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?
• 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
• 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)
Eins noch:
– Nagvis Backend für Business Process AddOns sponsored by
Bacher Systems: http://goo.gl/sftJO
– Ab Version 1.6rc2 in Nagvis

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph Siess

Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
Christian Baranowski
 
Unit Tests für Totalverweigerer
Unit Tests für TotalverweigererUnit Tests für Totalverweigerer
Unit Tests für Totalverweigerer
Peter Hauke
 

Ähnlich wie OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph Siess (20)

OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
 
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas GelfOSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
 
JavaScript Performance
JavaScript PerformanceJavaScript Performance
JavaScript Performance
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der Wahl
 
Unixkurs 07 - Prozess- und Speicherverwaltung
Unixkurs 07 - Prozess- und SpeicherverwaltungUnixkurs 07 - Prozess- und Speicherverwaltung
Unixkurs 07 - Prozess- und Speicherverwaltung
 
Serverless Application Framework
Serverless Application FrameworkServerless Application Framework
Serverless Application Framework
 
NUMA vs. Hugepages
NUMA vs. HugepagesNUMA vs. Hugepages
NUMA vs. Hugepages
 
OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb
OSMC 2008 | Monitoring Microsoft SQL Server by Michael StrebOSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb
OSMC 2008 | Monitoring Microsoft SQL Server by Michael Streb
 
ShareConf 2014: 10 Gründe warum der SharePoint langsam ist
ShareConf 2014: 10 Gründe warum der SharePoint langsam istShareConf 2014: 10 Gründe warum der SharePoint langsam ist
ShareConf 2014: 10 Gründe warum der SharePoint langsam ist
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
 
OSMC 2008 | PNP4Nagios - Installation, Konfiguration und Template Erstellung ...
OSMC 2008 | PNP4Nagios - Installation, Konfiguration und Template Erstellung ...OSMC 2008 | PNP4Nagios - Installation, Konfiguration und Template Erstellung ...
OSMC 2008 | PNP4Nagios - Installation, Konfiguration und Template Erstellung ...
 
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
 
#SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit #SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit
 
Transaktionssysteme
TransaktionssystemeTransaktionssysteme
Transaktionssysteme
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
 
Unit Tests für Totalverweigerer
Unit Tests für TotalverweigererUnit Tests für Totalverweigerer
Unit Tests für Totalverweigerer
 
Die nächste Generation des Unit Testing
Die nächste Generation des Unit TestingDie nächste Generation des Unit Testing
Die nächste Generation des Unit Testing
 

OSMC 2011 | Performance-Vergleich von Nagios Monitoring Lösungen by Christoph Siess

  • 1.
  • 2. Performancevergleich Nagios-Systeme OSMC 2011, Nürnberg Christoph Siess, MSc xs@bacher.at
  • 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