Aufgaben und Lösungen beim Systemmonitoring

IT-Versorger müssen heute nicht nur in der Lage sein, IT-Komponenten bereitzustellen oder zu liefern. Immer wichtiger wird das kontinuierliche Arbeiten an Prozessen, effizientes Change- und Risiko-Management sowie die kosteneffiziente Gewährleistung von Service-Level-Agreements.

Der Alltag sieht aber meist anders aus: Er ist durch reaktives Handeln, fehlende Gesamtübersicht und umständliches Monitoring der Systemlandschaft durch einzelne Herstellertools oder auf manuelle Weise bestimmt. Das alles sind Zeitfresser, die den Kosten- und Handlungsdruck erhöhen.

Effizientes Systemmonitoring kann da Abhilfe schaffen, Aber was macht Systemmonitoring überhaupt aus? Welche Aufgaben fallen bei der Überwachung der IT-Landschaft an? Welche Lösungen hält der Markt derzeit dafür bereit? Welche Informationen können beim Monitoring geprüft werden? Und welches sind die gängigsten Verfahren zur Datengewinnung? Mit diesen Fragen beschäftigt sich der folgende Beitrag. Um sie zu beantworten, sind zunächst einige grundlegende Erläuterungen notwendig.

Das SNMP-Protokoll

Man kann zwar grundlegend viele verschiedene TCP/IP-Protokolle zur Übermittlung der Daten verwenden (zum Beispiel SSH zum Anstoßen eines lokalen Skriptes oder Telnet, das im Vergleich zu SSH aber keine Verschlüsselung nutzt). In der Praxis läuft es aber hauptsächlich auf das SNMP-Protokoll hinaus. Das Protokoll stellt die kleinste gemeinsame Einheit zur Überwachung und Steuerung jeglicher Hardware dar. Es interagiert mit dem Monitoring-Tool auf dem Session-Layer. Neben der Lese- und Schreibfähigkeit unterstützt es die Datenlieferung in SNMP v1 über TCP, SPX oder UPD.

Allerdings sind die Authentifizierungsmöglichkeiten gering. Schutz bieten lediglich die in „Lese-/Schreibzugriff“ und „reiner Lesezugriff“ aufgeteilten Communities mit ihren eigenen, in Klartext übertragenen Passwörtern. SNMP existiert bereits in Version 3. Neben allen v2-Funktionalitäten beherrscht die aktuellste Version 64-Bit Zähler, Benutzerkonten und Authentifizierung, zusätzlich die Verschlüsselung in DES und AES unter Nutzung von VACM.

Aktuellere Hardware unterstützt meist alle Varianten, in der Praxis wird innerhalb von LANs hinter der Firewall aber SNMP v1 bevorzugt. Gründe dafür sind Performance, Einfachheit und Kompatibilität. Bei SNMP v1 werden lediglich ein oder zwei „Community-Namen“ konfiguriert. Nur bei besonderem Bedarf, etwa der ISO27001-Zertifizierung, ist es sinnvoll, SNMP v3 zu nutzen. V3 bietet zwar Abwärtskompatibilität, ist aber sehr komplex und verlangt viel Zeit für die Konfiguration.

Funktionen wie SNMP-WALK prüfen, welche Geräte, Objekte und Informationen sich abfragen lassen. Die anschließende Konfiguration von Parametern, Schwellwerten, Ausführungszeitplänen und das Hinterlegen von verantwortlichen Kontaktpersonen dient der Auswertung und der Benachrichtigung im Bedarfsfall. Die kann über Telefon, E-Mail, SMS oder Instant Messaging erfolgen.

Das Entsenden von aktiven SNMP-Checks durch das Monitoring-Tool liefert Statusdaten in fest konfigurierten Intervallen und validiert sie nach einer fixen Anzahl an Prüfungen von Soft-State zu Hard-State-Zuständen. Diese sogenannten SNMP-GETS fragen Daten im Auftrag der Anwendung aktiv ab.

Eine moderne Überwachungslösung sollte jedoch zusätzlich den Empfang von passiven SNMP-TRAPS unterstützen. Bei diesem Verfahren werden die Gerätekomponenten so konfiguriert, dass sie bei zeitkritischem Status selbständig Ereignisse über einen aktiven Agenten übermitteln. Die Kommunikationsmöglichkeiten zwischen SNMP und Hardware ergeben sich durch die hardwareseitig integrierten und in der Monitoring-Anwendung migrierten MIBs (Management-Information-Base, das heißt: Beschreibungsdateien) der Hersteller. Sie können auch durch die menschlich lesbaren Object Identifier (OIDs) manuell eingepflegt werden. OIDs sind meist in umfangreichen Listen im Internet zu finden.

Die Sensorik

Rechenzentren und Serverräume unterliegen besonderen Sicherheitsvorschriften. Schon ein Kabelbrand im Serverschrank kann katastrophale Folgen für ein Unternehmen haben. Für entsprechende Hardware oder potenzialfreie Schaltungen, zum Beispiel an Zugangstüren, können Zustände über einen Agenten mittels des SNMP-Protokolls abgeholt, ausgewertet, validiert und an die hinterlegte Kontaktperson oder -gruppe gesendet werden. Um Auskunft über klimatische und räumliche Gegebenheiten, seismographische Aktivitäten, Statusinformationen von der USV oder sogar kompletten Produktionsanlagen zu bekommen, gibt es unterschiedliche Module, zum Beispiel für Rauch, Gas, Wasser, Erschütterung oder Bewegung.

Linux-/Unixbasierte Systeme überwachen

Durch den Einsatz von SSH- oder tooleigener Daemons lassen sich lokal installierte Skripte (zum Beispiel Shell und Perl) mit ihren Commands ausführen, um Antworten zu erhalten. Der Log-in kann per Public-Key-Methodik erfolgen. Auch Syslog-Events sind über aktive Checks direkt abfragbar.

Eine andere Methode ist der Einsatz eines lokalen Agenten. Dieser wird vom Monitoring-Server aktiv aufgefordertt, sämtliche ungefilterte Informationen zu liefern. Für Linux/Unix-Umgebungen bietet sich NET-SNMP (bereits in v5.x.x) mit eigenem Daemon an. Dieser enthält eine Vielzahl nützlicher Kommandozeilen-Tools, Agenten und Bibliotheken, welche die Grundlage für die SNMP-Implementierung im Open-Source-Bereich darstellen.

Windowsbasierende Systeme mit Agenten überwachen (clientbased)

Die Daten des Windows-Eventlog müssen auf eine andere Art als die der Unix-Syslog abgefragt werden. Hier besteht keine direkte Transfermöglichkeit der Plug-ins. Grundsätzlich bieten windowsbasierende Systeme mehrer Möglichkeiten zur Abfrage an, zum Beispiel durch NSClient++, OpMon-Agent, NC_Net. Dazu kommen die herstellerspezifischen Möglichkeiten des jeweiligen Tools. Wichtig ist, dass der entsprechende Agent auf dem Windows-System aktiv ist.

WMI – Checks ohne Agenten (clientless)

Windowsbasierende Workstations und Server bringen bereits die WMI-Schnittstelle mit, so dass auf eine direkte lokale Installation auf dem Client-PC verzichtet werden kann. Die Schnittstelle besitzt Lese- und Schreibfähigkeit und kann auf fast alle Einstellungen des Systems zugreifen – sowohl auf Betriebs- als auch Anwendungsebene. Zur Überwachung werden daher häufig Perfmon-Werte, Ereignisseprotokolle, Inventardaten oder Dienste und Prozesse ausgewertet. Es handelt sich dabei um eine Query-Language, die eine Anmeldung am System erfordert und für die Administration und Fernwartung besonders hilfreich ist.

Voraussetzung ist ein Windows-Server, auf dem alle WMI-Skripte installiert sind. Er stellt das Kommunikationsprotokoll für die Übermittlung der Daten zwischen WMI-Proxy und Monitoring-Tool bereit. Das Protokoll sorgt dafür, dass die Parameter an die lokalen Plug-ins übergeben werden.

Bei der Frage nach clientless oder clientbased Monitoring ist ein grundlegendes Problem, dass die binäre Implementierung von Client-Software ein Eingriff in das bestehende System darstellt und Probleme hervorrufen kann. Deshalb werden häufig clientless Standardmethoden verwendet.

Applikationen über CCMS überwachen (clientless)

CCMS (Computer Center Management System) ist ein SAP-eigenes Monitoringwerkzeug, das der zentralen Überwachung der SAP-Netweaver-Komponenten dient. Dadurch lässt sich das Verhalten von SAP-Systemen bewerten und ihre größtmögliche Verfügbarkeit sicherstellen. Der SAP-Alert-Monitor als Monitorsammlung empfängt Daten unter anderem von Agenten der Satellitensysteme, die Auskunft über Performance- oder Zustandsdaten abliefern.

Dazu gehören zum Beispiel Speicher-/CPU-Auslastung, Disk I/Os, Datenbanken, Antwortzeiten, Ausgabesteuerung oder Security- und Systemlogs. SAP liefert dazu verschiedene sinnvolle Templates, die manuell ergänzt werden können. Auf der Monitoring-Seite ist ein Client installiert, der mit aktiven Plug-ins die CCMS-Daten über eine der RFC-Schnittstellen abfragt. Voraussetzungen für den Remotezugriff sind die Installation der SAP-Bibliotheken auf Windows und Linux/Unix. Je nach Tool können auch SLA-Reportings, Business-Process-Monitoring und Trendanalysen zur Funktionalität gehören.

Systemnahe Applikationen

J2EE-, Web-, Domain-Name-, Mail-, Fileserver, Proxies und entsprechende Queues lassen sich problemlos über die netzwerkfähigen Protokolle SMTP, HTTP, DNS, DIG, POP3, IMAP oder FTP abfragen (mit oder ohne Verschlüsselung). Nicht jedes Protokoll besitzt passende Plug-ins. Individuelle bestehende Plug-ins nutzen die Protokolle, um zu prüfen, ob der TCP oder UDP-Port offen ist und dort ein Dienst existiert. Für eine Überwachung in die Tiefe finden spezifische Agenten Verwendung. Die Antworten wertet das Monitoring-Tool aus.

Cloud

Auch ESX-, KVM-, Citrix- oder XEN-Farms können im Bereich der Auslastung einzelner Komponenten überwacht werden. Ebenso sind der Traffic, eingeloggte User, Lizenzen oder laufenden Sessions kontrollierbar. Abfragen werden über die vom Hersteller gelieferten APIs abgewickelt, so dass keine zusätzliche systemseitige Installation nötig ist.