KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

Clientbasiertes Discovery

Nach einer solchen netzwerkbasierten Inventur der Infrastruktur kann das Monitoring der Systeme natürlich noch verfeinert werden. Abhängig vom Betriebssystem gelingt das beispielsweise, indem man SNMP benutzt oder lokale Agenten einspielt.

Als Beispiel für einen Agenten bietet etwa die bekannte Nagios-Lösung check_mk [5] die Möglichkeit, den Host nach vorhandenen Services zu durchsuchen und diese zu überwachen. Solche Agenten sind für die gängigen Linux-Plattformen und Windows verfügbar. Für den Einsatz unter Windows bietet sich auch NSClient++ an, dessen Standardmodule auf jedem Client aktiviert werden können. Eine Besonderheit ist, dass NSClient++ in der Lage ist, die Resultate selbst zu ermitteln und dann als passives Ergebnis an den Monitoringserver zu senden.

Gerade unter Sicherheits- und Update-Gesichtspunkten ist es aber oft problematisch, individuelle Clients einzuspielen. Oft sind nur Pakete aus der jeweiligen Distribution zugelassen. Hier kann die Erweiterung des lokalen »snmpd« und die Verwendung von »check_snmp_extend« [6] Abhilfe schaffen. Die Idee dahinter ist einfach und genial zugleich. Neue Kommandos zur Abfrage von Monitoring-Informationen werden in die »snmpd.conf« -Datei eingetragen und lassen sich dann mit einem normalen Plugin-Aufruf ausführen, wenn die korrekte SNMP Community angegeben wird.

Das folgende Beispiel illustriert die Überwachung eines Software-Raid mithilfe dieses Eintrags in die »snmpd.conf« :

extend raid-md0 /usr/local/bin/check_raid.pl --device=md0

Nach einem Neustart des »snmpd« ist die Abfrage sofort verfügbar und kann mit folgendem Nagios- oder Icinga-Snip verwendet werden.

define service{
 use generic-service
 host_name snmp_server
 service_description SOFTRAID status
 check_command check_snmp_extension!raid-md0
}

Bringt man die entsprechenden »snmpd.conf« -Erweiterungen mit einer Paketverteilung oder besser einem Konfigurationsmanagement auf die Clients aus, lassen sich die verfügbaren Informationen durch eine NMap-Erweiterung abfragen und automatisch in die Konfiguration übernehmen.

Zu Fuß

Alle bisher beschriebenen Szenarien inventarisierten die Umgebung vollständig und nahmen alle gefundenen Komponenten in das Monitorung auf. Dieses Verfahren hat aber den Nachteil, dass man von der Vielzahl an Services leicht erschlagen wird und die wichtigen Komponenten nur schwer identifiziert.

Ein anderer, jedoch manueller Ansatz ist die Konfiguration und Einrichtung auf Basis der vorhandenen Geschäftsprozesse. Dabei beginnt die Inventarisierung nicht durch Definition aller Komponenten, sondern vielmehr mit einer genauen Analyse der Geschäftsprozesse. Bei diesen Prozessen kann es sich um eine Mail-Lösung, das SAP-System oder auch die eigene Active-Directory-Domain handeln. Nach Festlegung der entsprechenden Prioritäten beginnt man also den Prozess zu zerlegen und seine Einzelbausteine zu identifizieren.

Bleiben wir beim Beispiel des zentralen Exchange-Clusters (Abbildung 1). Um den Mail-Service zu gewährleisten, sind verschiedene Subsysteme notwendig, die ebenfalls eigene Abhängigkeiten aufweisen. Durch Definition eines solchen Service-Abbildes lassen sich diese Abhängigkeiten identifizieren und die einzelnen Subsysteme auch in anderen Prozessen weiterverwenden. So ist der DNS-Cluster mit großer Wahrscheinlichkeit auch für andere Teilprozesse von großer Bedeutung und muss dann nicht neu definiert werden.

Abbildung 1: Schematische Darstellung der Service-Abhängigkeiten in einem Mail-Cluster.

Die beteiligten Hosts und Services lassen sich auf diese Weise konfigurieren und dann überwachen. Nach und nach entsteht so ein Prozessabbild der eigenen Umgebung, was in der Regel ein besseres Verständnis der IT-Umgebung ermöglicht als es mit einem Sammelsurium unabhängiger Einzeldienste möglich wäre. Auch für bestehende Monitoringumgebungen ist dieses Vorgehen ein guter Revisions- und Optimierungsprozess.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019