Die Netzwerkinfrastruktur gehört wahrscheinlich nicht zu den heißesten Themen im IT-Bereich, nimmt jedoch einen enormen Stellenwert für Administratoren ein. ... (mehr)

OS-Metriken kontinuierlich prüfen

Für die Metriken des Betriebssystems (CP-Load, Disk Usage, Network Traffic) liefert Telegraf eine Reihe sehr simpler Input-Plug-ins, die keiner detaillierten Beschreibung bedürfen und keine besondere Konfiguration erfordern. Auf den zu überwachenden Systemen richten Sie einfach den Telegraf-Dienst ein und statten ihn mit einer simplen Konfiguration aus, die in etwa so aussieht wie im Listing-Kasten "Beispiel für Telegraf-Konfiguration".

Listing 1: Beispiel für Telegraf-Konfiguration



# Telegraf Configuration
[global_tags]
[agent]
      interval = "30s"
      hostname = "(<Servername>)"
[[outputs.influxdb]]
      urls = ["http://<IP-Adresse oder FQDN des Influxdb-Servers>:8086"]
      database = "telegraf"
[[inputs.cpu]]
      percpu = true
      totalcpu = true
[[inputs.net]]
      interfaces = ["eno1","eno2","virbr1"]
[[inputs.disk]]
      ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]
[[inputs.diskio]]
[[inputs.kernel]]
[[inputs.mem]]
[[inputs.processes]]
[[inputs.system]]

Zwar beschreibt dieser Workshop nur Linux-Installationen, Telegraf steht aber zudem in einer Windows-Version zur Verfügung, kann dort die Metriken des Microsoft-OS einsammeln und an Influx senden. Wer das unbedingt möchte, kann natürlich auch InfluxDB und Grafana auf Windows betreiben.

Sammeldienst Collectd

Eigentlich sollte Telegraf im nächsten Schritt IPMI-Daten (CPU-Temperatur, Netzteilspannungen et cetera) des Baseboard Management Controllers eines Servers auslesen und an Influx berichten. Doch gibt es hier scheinbar einen Bug. Zwar liest in allen unseren Tests das korrekt konfigurierte Telegraf-IPMI-Plug-in die gewünschten Sensordaten aus, doch kommen diese nicht in der Influx-Datenbank an – alle anderen von Telegraf gesammelten Metriken jedoch schon.

Das ist aber nicht weiter tragisch, denn im Rahmen des Workshops nutzen wir den Collectd-Dienst, und anders als Telegraf liest und liefert dieser die gewünschten IPMI-Daten.

Im Prinzip erledigen Telegraf und Collectd den selben Job: Sie sammeln Metriken ein und senden sie an ein anderes System zur Aufarbeitung. Collectd gibt es bereits seit 2005 und die Zahl der Plug-ins ist riesig. Telegraf ist deutlich jünger, aber im Rahmen des TICK-Stacks sehr populär und daher ebenfalls mit einer Vielzahl von Plug-ins versehen. Beide Tools können zudem die gesammelten Metriken filtern, bevor sie weitergeleitet werden – worauf wir im Rahmen des Workshops aber nicht näher eingehen.

Collectd steht allerdings nur für Linux, BSD und Solaris zur Verfügung. Wer Windows-Systeme damit überwachen möchte, muss das kostenpflichtige Tool "SSC Serv" kaufen, das das collectd-Protokoll verwendet.

Welches Tool zum Versenden der Metriken zum Einsatz kommt, ist Geschmackssache. Allerdings bedarf es einiger kleiner Vorbereitungen, um collectd mit Influx zu betreiben, während Telegraf ohne Modifikationen funktioniert. Theoretisch verwaltet Collectd selbst seine Metriken und könnte auch ganz ohne Influx unmittelbar als Datenquelle für Grafana dienen. Um offen für verschiedene Quellen zu bleiben, bietet sich jedoch InfluxDB an.

Der collectd-Service verwendet ein anderes Netzwerkprotokoll und eine andere Datenstruktur als Telegraf. Daher benötigt InfluxDB einen "separaten Eingang" für Daten, die von collectd stammen. Deren Transfer erfolgt binär via Port 25826 und InfluxDB muss auf diese Kommunikation hören. Die Konfiguration in "/etc/influxdb/influx.conf" bekommt daher eine kleine Erweiterung:

[[collectd]]
      enabled = true
      bind-address = "(<IP-Adresse des InfluxDB-Servers>):25826"
     database = "collectd"
      typesdb = "/usr/share/collectd/types.db"

Die Datei "types.db" stammt aus dem Umfeld von collectd. Sie müssen sie von einem collectd-Host auf das Influx­DB-System kopieren oder collectd einfach via »yum install collectd« dort installieren.

Auf den zu überwachenden physischen Servern richten Sie dann den collectd-Service mit den nötigen Plug-ins ein. Der Dienst selbst bringt nur die nötigsten Basisfunktionen mit. Die Plug-ins stecken in separat zu installierenden Paketen. Unter CentOS/RHEL übernimmt yum die Installation:

yum install OpenIPMI-libs OpenIPMI collectd collectd-ipmi collectd-disk ipmitool

Auf Debian/Ubuntu-Systemen gibt es die entsprechenden deb-Pakete für die Installation via apt-Packetmanager.

Das IPMI-Tool braucht collectd eigentlich nicht, jedoch hilft es Ihnen dabei, eine Liste der verfügbaren IPMI-Sensoren zu erstellen. Die sind bei nahezu jedem Serverhersteller unterschiedlich. Die Konfiguration von "/etc/collectd.conf" beginnt recht simpel:

Hostname "(<Name des überwachten Systems>)"
 
LoadPlugin cpu
LoadPlugin interface
LoadPlugin load
LoadPlugin disk
LoadPlugin df
LoadPlugin memory
LoadPlugin ipmi
LoadPlugin network

Collectd nutzt nur die explizit geladenen Erweiterungen. Gibt es keine separate Plug-in-Konfiguration, setzt der Dienst die Default-Werte ein:

<Plugin "ipmi">
      IgnoreSelected false
      NotifySensorAdd false
     NotifySensorRemove true
      NotifySensorNotPresent false
</Plugin>

Im Plug-in "IPMI" können Sie jeden auszulesenden Sensor einzeln mit einer Konfigurationszeile wie Sensor "Sensorname" angeben. Simpler ist es jedoch, erst einmal alle auszulesen. Dann bekommen Sie die exakten Sensornamen in der InfluxDB angezeigt und können später die Konfiguration von collectd anpassen und das IPMI-Plug-in auf einige wenige Sensoren beschränken wie im Listing-Kasten "Sensoren spezifizieren" ersichtlich.

Listing 2: Sensoren spezifizieren



<Plugin df>
      Device "/dev/sdb1"
      MountPoint "/vm"
      FSType "xfs"
</Plugin>
<Plugin cpu>
      ReportByCpu true
</Plugin>
<Plugin disk>
      Disk "/^[hs]d[a-f][0-9]?$/"
</Plugin>
<Plugin interface>
      Interface "br0"
      Interface "br1"
</Plugin>

Sie können jedes Plug-in individuell anpassen. Im Beispiel im genannten Kasten möchten wir etwa nur vom Dateisystem unter "/vm" die Belegung wissen und auch nur Netzwerkmetriken von den Bridges "br0" und "br1" einsammeln. Die Informationen leitet collectd über das Network-Plug-in an InfluxDB:

<Plugin network>
      Server "(<IP-Adresse oder FQDN des InfluxDB Servers>)" "25826"
</Plugin>

Die über collectd versandten Metriken landen dabei in einer eigenen Influx-Datenbank namens "collectd".

Über zusätzliche Erweiterungen kann collectd auch direkt den Status einer Applikation abfragen, wie beispielsweise Postgres, Mysql oder Apache. In einer anderen Testinstallation kommt etwa ein Nginx-Webserver zum Einsatz. Dabei kann collectd dessen Statusinformationen auslesen und als Metrik senden. Das setzt allerdings voraus, dass Nginx eine Statusseite zur Verfügung stellt. Für unseren Workshop läuft collectd auf demselben Server wie Nginx. Die passende Konfiguration für die Status-Page steht hier in der Datei "/etc/nginx/nginx.conf" im Abschnitt "server { listen 80 default_server;":

location /status {
      stub_status on;
      access_log off;
      allow 127.0.0.1;
      deny all;
      }

Das bedeutet, dass nur das lokale System Zugriff zur Statusseite bekommt. Somit können Sie sich eine komplexere Konfiguration mit SSL-Verschlüsselung und Basic Authentication sparen.

Hierfür muss natürlich das Plug-in "collectd-nginx" auf dem System vorhanden sein. Die passenden Zeilen in "/etc/collectd.conf" lauten dann einfach:

LoadPlugin nginx
<Plugin nginx>
      URL "http://127.0.0.1/status?auto"
</Plugin>

Schon meldet collectd Informationen zu aktiven Verbindungen und Seitenaufrufen an Influx.

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

Ausgabe /2020