von Redaktion IT-A…
Lesezeit
4 Minuten
Installation und Betrieb von Check_MK (3)
Check_MK will das komplexe Nagios-Monitoring vereinfachen. Als freies Out-of-the-Box-Monitoring mit automatischer Konfiguration erfreut es sich daher zunehmender Beliebtheit. Aber auch seine vielfältigen Einsatzmöglichkeiten durch bereitgestellte Module und eigenentwickelte Plug-ins wecken das Interesse von IT-Verantwortlichen. Dieser Artikel zeigt den Aufbau einer Check_MK-Umgebung und liefert zwei Praxisbeispiele für die vielfältigen Einsatzmöglichkeiten. Im dritten und letzten Teil der Serie zeigen wir anhand von zwei Anwenderberichten, wie die Nagios-Migration mit Check_MK in der Praxis verläuft und was Sie beim SPS-Monitoring beachten sollten.
Check_MK in der Praxis
Anhand von zwei Praxisbeispielen zeigen wir im Folgenden, wie schnell, unkompliziert und flexibel Check_MK einsetzbar ist. Das erste Beispiel zeigt die Migration von einer vorhandenen Nagios-Installation zu Check_MK. Durch die Kompatibilität zu Nagios kann eine Migration mit wenig Aufwand erfolgen. Das zweite Beispiel widmet sich der Integration vom SPS-Monitoring (Speicher programmierbarer Steuerungen) in Check_MK. Bis dahin war es nicht möglich, SPS-Geräte mit Check_MK zu überwachen. Auf Kundenwunsch ist ein Konzept für die Überwachung entstanden.
Nagios-Migration in der Praxis
Die Firma Richter+Frenzel ist bereits seit 1895 als Familienunternehmen im Bereich Sanitär- und Haustechnik tätig und gehört in diesen Segmenten zu den führenden Großhändlern in Deutschland. Das Unternehmen beschäftigt an über 170 Standorten rund 3500 Mitarbeiter und hatte bereits eine Nagios-Installation im Einsatz. Das Monitoring insgesamt bestand aus unterschiedlichen einzelnen Open-Source-Komponenten. Die Konfiguration und Abstimmung der Teilpakete erfolgte durch einen einzigen IT-Mitarbeiter. Der personelle Einsatz, die einzelnen Komponenten auf dem aktuellen Stand zu halten, war aufwendig.
Im Zuge des Updates einer Komponente wurde vorab geprüft, ob diese auch kompatibel zum vorhandenen System ist. Die Verantwortung für die Einrichtung und Pflege von den Hosts und Services lag bei diesem Mitarbeiter. Es war nicht möglich, die Pflege an andere Personen zu übertragen, weil die Anforderungen an das entsprechende Wissen zu hoch waren. Das aktive Melden von Änderungen in der IT-Infrastruktur erschwerte die Pflege des Monitorings. Aus diesem Grund konnte das Monitoring nahezu nie die aktuelle Umgebung abbilden.
Check_MK wird bei Richter+Frenzel auf einem physischen Server betrieben, um unabhängig von der Virtualisierungsumgebung zu sein. Die Installation erfolgte mit einem bereitgestellten Paket, das alle benötigten Komponenten als Abhängigkeiten enthält. Dadurch war keine zusätzliche manuelle Installation weiterer Komponenten nötig. Dieser Vorteil sorgt dafür, dass bereits nach kurzer Zeit eine voll lauffähige Installation von Check_MK zur Verfügung steht. Die beinhalteten Komponenten von Check_MK sind bereits aufeinander abgestimmt und können sofort den Dienst verrichten.
Richter+Frenzel betreibt die wesentliche IT-Infrastruktur in einem Rechenzentrum. Aufgrund dieser Struktur reicht für die Überwachung eine Instanz aus. Die SNMP-Geräte sind in einem Ordner logisch gruppiert und erben die grundlegenden Einstellungen wie die Abfrage über SNMP. Die Aufnahme der Geräte erfolgte mit einem Massenimport. Dies heißt, dass die Geräte alle im Check_MK mit dem entsprechenden DNS-Namen angelegt wurden, eine Bulk-Discovery alle Services suchte und im System passend mit den Standardwerten einrichtete.
Ähnlich verhielt es sich bei den Hosts. Hier sind auf den zu überwachenden Hosts die Check_MK-Agenten installiert. Die Agenten liefern für jede Plattform automatisch die Grunddaten wie beispielsweise zur Ausnutzung von Arbeitsspeicher oder Festplattenbelegung, Netzwerkstatus und CPU-Auslastung. Durch die Mischumgebung von Windows und Linux sowie besondere Dienste wie Datenbanken und Domaincontroller erfolgte eine passende Gruppierung über Ordner. Die Ordner enthalten wieder die grundlegenden Einstellungen für die Hosts und die Datenabfrage. Das Discovery erzeugte für diese Hosts alle automatisch erkannten Checks als Services und die Überwachung begann sofort.
Bild 5: Dieser Beispiel-Graph stellt die Ausführungszeiten vom Check_MK Service dar.
Nach Abschluss der Aufnahme stand das Feintuning der Schwellenwerte an. Die Router und Switche wurden als Erstes näher betrachtet. Eine Trennung der Hardware für Rechenzentrum und Clients machte die Konfiguration sehr leicht. Auf den Geräten für das Rechenzentrum werden die Interfaces mit Geschwindigkeiten und Fehlerraten überwacht. Die Ports mit den Clientgeräten werden nur dann überwacht, wenn ein Netzwerkdrucker angeschlossen ist. Aus dieser Anforderung heraus entstanden Regeln, die genau diese Anforderungen abdecken. Die Interfaces für das Rechenzentrum werden detailliert überwacht. Die Überwachung gewährleistet dabei, dass die Interfaces einen Link oder die gewünschte Übertragungsgeschwindigkeit haben, sowie, dass keine Fehlerraten vorhanden sind. Bei den Ports für die Netzwerkdrucker wird nur die Fehlerrate überwacht. Sonderkonfigurationen für Hosts oder Services sind über Tags abgebildet. Die Datenbankserver haben einen Host-Tag erhalten, der weitere Regeln dafür aktiviert.
Regeln lassen sich zum einen global, ordnerspezifisch, tagspezifisch oder auf einzelne Hosts oder Services anwenden. An diesem Tagging hängen weitere Abweichungen von den Standardwerten wie die Erweiterung von den Agenten um die Plug-ins für die Prüfung von Datenbank und Tabellen, Anpassung der Schwellenwerte für Arbeitsspeicher, Pagefile und Festplattenbelegung. Mit wenigen Regeln und Anpassungen war das Monitoring konfiguriert und betriebsbereit.
Eine Besonderheit bei Richter+Frenzel ist die Anbindung der 170 Standorte. Die Standorte sind in diesem Fall die Clients, die die Daten aus dem Rechenzentrum benutzen und auf diese angewiesen sind. Ein Dienstleister betreibt die WAN-Verbindungen und die Standorte selber besitzen einen Router, Accesspoints und Switche. Für die Überwachung ist wieder Check_MK im Einsatz, das die Router und die einzelnen Verbindungen zu den Standortroutern über SNMP im Blick hat. Für die Verbindungen betreibt der zuständige Dienstleister eine autarke Seite für die Überwachung. Richter+Frenzel wollte diese Informationen in das eigene Monitoring integrieren, was normalerweise über den Livestatus möglich ist. Besteht kein Zugriff auf den Livestatus oder steht diese Option nicht zur Verfügung, kommt das Skript "multisite_to_mrpe" zum Einsatz. Dieses ruft die Daten über die Multisite ab und speist sie über MRPE in das Monitoring ein. Das Monitoring hat somit alle wichtigen Informationen zusammengetragen und stellt diese übersichtlich dar. Die Alarmierung erfolgt über Regeln, die die jeweiligen Verantwortlichen benachrichtigen, in Problemfällen wird entsprechend eskaliert. Die Eskalation besteht darin, weitere verantwortliche Personen beziehungsweise Vorgesetzte zu benachrichtigen.
Die Instanz enthält aktuell in etwa 1800 Hosts mit rund 19.000 Services und wird von 30 Usern benutzt. Die Administration erfolgt seit der Umstellung in Teams: Das Monitoring-Team pflegt nur noch die Monitoring-Infrastruktur, während die Pflege der Hosts und die Regelerstellung bei den jeweiligen Fachteams liegt. Dies garantiert, dass alle Hosts und Services entsprechend im Monitoring zur Verfügung stehen. Die regelbasierte Konfiguration hilft, den Überblick über die einzelnen Parameter zu behalten. Die Einrichtung beziehungsweise Anpassung der Hosts wird mit der Discovery-Funktionalität wesentlich vereinfacht. Die Migration zu Check_MK erfolgte innerhalb weniger Wochen. Das eingesetzte Monitoring liefert mehr und genauere Daten. Vorhandene Lücken deckte die Mathias Kettner GmbH auf und löste sie kurzfristig telefonisch wie auch remote. Mit Check_MK wurde ein wichtiges Instrument zur Aufrechterhaltung der IT-Services bei Richter+Frenzel eingeführt, das außerdem planerisch zum Capacity-Management zum Einsatz kommt.
Seite 1: Check_MK in der Praxis
Seite 2: SPS-Monitoring mit Check_MK
jp/ln/Karl Deutsch, Mathias Kettner und Sven Rueß
Anhand von zwei Praxisbeispielen zeigen wir im Folgenden, wie schnell, unkompliziert und flexibel Check_MK einsetzbar ist. Das erste Beispiel zeigt die Migration von einer vorhandenen Nagios-Installation zu Check_MK. Durch die Kompatibilität zu Nagios kann eine Migration mit wenig Aufwand erfolgen. Das zweite Beispiel widmet sich der Integration vom SPS-Monitoring (Speicher programmierbarer Steuerungen) in Check_MK. Bis dahin war es nicht möglich, SPS-Geräte mit Check_MK zu überwachen. Auf Kundenwunsch ist ein Konzept für die Überwachung entstanden.
Nagios-Migration in der Praxis
Die Firma Richter+Frenzel ist bereits seit 1895 als Familienunternehmen im Bereich Sanitär- und Haustechnik tätig und gehört in diesen Segmenten zu den führenden Großhändlern in Deutschland. Das Unternehmen beschäftigt an über 170 Standorten rund 3500 Mitarbeiter und hatte bereits eine Nagios-Installation im Einsatz. Das Monitoring insgesamt bestand aus unterschiedlichen einzelnen Open-Source-Komponenten. Die Konfiguration und Abstimmung der Teilpakete erfolgte durch einen einzigen IT-Mitarbeiter. Der personelle Einsatz, die einzelnen Komponenten auf dem aktuellen Stand zu halten, war aufwendig.
Im Zuge des Updates einer Komponente wurde vorab geprüft, ob diese auch kompatibel zum vorhandenen System ist. Die Verantwortung für die Einrichtung und Pflege von den Hosts und Services lag bei diesem Mitarbeiter. Es war nicht möglich, die Pflege an andere Personen zu übertragen, weil die Anforderungen an das entsprechende Wissen zu hoch waren. Das aktive Melden von Änderungen in der IT-Infrastruktur erschwerte die Pflege des Monitorings. Aus diesem Grund konnte das Monitoring nahezu nie die aktuelle Umgebung abbilden.
Check_MK wird bei Richter+Frenzel auf einem physischen Server betrieben, um unabhängig von der Virtualisierungsumgebung zu sein. Die Installation erfolgte mit einem bereitgestellten Paket, das alle benötigten Komponenten als Abhängigkeiten enthält. Dadurch war keine zusätzliche manuelle Installation weiterer Komponenten nötig. Dieser Vorteil sorgt dafür, dass bereits nach kurzer Zeit eine voll lauffähige Installation von Check_MK zur Verfügung steht. Die beinhalteten Komponenten von Check_MK sind bereits aufeinander abgestimmt und können sofort den Dienst verrichten.
Richter+Frenzel betreibt die wesentliche IT-Infrastruktur in einem Rechenzentrum. Aufgrund dieser Struktur reicht für die Überwachung eine Instanz aus. Die SNMP-Geräte sind in einem Ordner logisch gruppiert und erben die grundlegenden Einstellungen wie die Abfrage über SNMP. Die Aufnahme der Geräte erfolgte mit einem Massenimport. Dies heißt, dass die Geräte alle im Check_MK mit dem entsprechenden DNS-Namen angelegt wurden, eine Bulk-Discovery alle Services suchte und im System passend mit den Standardwerten einrichtete.
Ähnlich verhielt es sich bei den Hosts. Hier sind auf den zu überwachenden Hosts die Check_MK-Agenten installiert. Die Agenten liefern für jede Plattform automatisch die Grunddaten wie beispielsweise zur Ausnutzung von Arbeitsspeicher oder Festplattenbelegung, Netzwerkstatus und CPU-Auslastung. Durch die Mischumgebung von Windows und Linux sowie besondere Dienste wie Datenbanken und Domaincontroller erfolgte eine passende Gruppierung über Ordner. Die Ordner enthalten wieder die grundlegenden Einstellungen für die Hosts und die Datenabfrage. Das Discovery erzeugte für diese Hosts alle automatisch erkannten Checks als Services und die Überwachung begann sofort.
Bild 5: Dieser Beispiel-Graph stellt die Ausführungszeiten vom Check_MK Service dar.
Nach Abschluss der Aufnahme stand das Feintuning der Schwellenwerte an. Die Router und Switche wurden als Erstes näher betrachtet. Eine Trennung der Hardware für Rechenzentrum und Clients machte die Konfiguration sehr leicht. Auf den Geräten für das Rechenzentrum werden die Interfaces mit Geschwindigkeiten und Fehlerraten überwacht. Die Ports mit den Clientgeräten werden nur dann überwacht, wenn ein Netzwerkdrucker angeschlossen ist. Aus dieser Anforderung heraus entstanden Regeln, die genau diese Anforderungen abdecken. Die Interfaces für das Rechenzentrum werden detailliert überwacht. Die Überwachung gewährleistet dabei, dass die Interfaces einen Link oder die gewünschte Übertragungsgeschwindigkeit haben, sowie, dass keine Fehlerraten vorhanden sind. Bei den Ports für die Netzwerkdrucker wird nur die Fehlerrate überwacht. Sonderkonfigurationen für Hosts oder Services sind über Tags abgebildet. Die Datenbankserver haben einen Host-Tag erhalten, der weitere Regeln dafür aktiviert.
Regeln lassen sich zum einen global, ordnerspezifisch, tagspezifisch oder auf einzelne Hosts oder Services anwenden. An diesem Tagging hängen weitere Abweichungen von den Standardwerten wie die Erweiterung von den Agenten um die Plug-ins für die Prüfung von Datenbank und Tabellen, Anpassung der Schwellenwerte für Arbeitsspeicher, Pagefile und Festplattenbelegung. Mit wenigen Regeln und Anpassungen war das Monitoring konfiguriert und betriebsbereit.
Eine Besonderheit bei Richter+Frenzel ist die Anbindung der 170 Standorte. Die Standorte sind in diesem Fall die Clients, die die Daten aus dem Rechenzentrum benutzen und auf diese angewiesen sind. Ein Dienstleister betreibt die WAN-Verbindungen und die Standorte selber besitzen einen Router, Accesspoints und Switche. Für die Überwachung ist wieder Check_MK im Einsatz, das die Router und die einzelnen Verbindungen zu den Standortroutern über SNMP im Blick hat. Für die Verbindungen betreibt der zuständige Dienstleister eine autarke Seite für die Überwachung. Richter+Frenzel wollte diese Informationen in das eigene Monitoring integrieren, was normalerweise über den Livestatus möglich ist. Besteht kein Zugriff auf den Livestatus oder steht diese Option nicht zur Verfügung, kommt das Skript "multisite_to_mrpe" zum Einsatz. Dieses ruft die Daten über die Multisite ab und speist sie über MRPE in das Monitoring ein. Das Monitoring hat somit alle wichtigen Informationen zusammengetragen und stellt diese übersichtlich dar. Die Alarmierung erfolgt über Regeln, die die jeweiligen Verantwortlichen benachrichtigen, in Problemfällen wird entsprechend eskaliert. Die Eskalation besteht darin, weitere verantwortliche Personen beziehungsweise Vorgesetzte zu benachrichtigen.
Die Instanz enthält aktuell in etwa 1800 Hosts mit rund 19.000 Services und wird von 30 Usern benutzt. Die Administration erfolgt seit der Umstellung in Teams: Das Monitoring-Team pflegt nur noch die Monitoring-Infrastruktur, während die Pflege der Hosts und die Regelerstellung bei den jeweiligen Fachteams liegt. Dies garantiert, dass alle Hosts und Services entsprechend im Monitoring zur Verfügung stehen. Die regelbasierte Konfiguration hilft, den Überblick über die einzelnen Parameter zu behalten. Die Einrichtung beziehungsweise Anpassung der Hosts wird mit der Discovery-Funktionalität wesentlich vereinfacht. Die Migration zu Check_MK erfolgte innerhalb weniger Wochen. Das eingesetzte Monitoring liefert mehr und genauere Daten. Vorhandene Lücken deckte die Mathias Kettner GmbH auf und löste sie kurzfristig telefonisch wie auch remote. Mit Check_MK wurde ein wichtiges Instrument zur Aufrechterhaltung der IT-Services bei Richter+Frenzel eingeführt, das außerdem planerisch zum Capacity-Management zum Einsatz kommt.
Seite 1: Check_MK in der Praxis
Seite 2: SPS-Monitoring mit Check_MK
| Seite 1 von 2 | Nächste Seite >> |
jp/ln/Karl Deutsch, Mathias Kettner und Sven Rueß
