ADMIN

2023

01

2022-12-29T12:00:00

Collaboration

PRAXIS

042

Netzwerkinfrastruktur

Systemmanagement

Sensoren abfragen

Hilfreiche Messdaten

von Andreas Stolzenberger

Veröffentlicht in Ausgabe 01/2023 - PRAXIS

Metrik-Dashboards in Grafana oder vergleichbaren Tools zeigen die Performance Ihrer Infrastruktur. Über Sensorabfragen erhalten Sie zusätzliche Informationen wie Spannungen, Temperaturen oder Lüfterdrehzahlen, mit deren Analyse Sie Ihre IT vor Ausfällen schützen können. Mit welchen Mitteln sich solche Sensorabfragen durchführen lassen, zeigt dieser Beitrag.

Darüber, wie Sie mithilfe von Tools wie InfluxDB, Telegraf oder Collectd Metriken ihrer laufenden Systeme abfragen und in Grafana grafisch darstellen, haben wir bereits mehrfach berichtet. Doch bislang konzentrierten sich die Workshops auf die grundlegende Softwarearchitektur eines TICK-Stacks – Telegraf, InfluxDB, Chronograf, Kapacitor; alternativ TIG mit Grafana statt Chronograf oder CIG mit Collectd statt Telegraf – und wie Sie damit Leistungsdaten ihrer Umgebung einsammeln. Damit wissen Sie zwar, wie voll Ihre Massenspeicher sind und welche Performance die CPUs liefern. Neben den reinen Leistungsdaten wie Systemlast sollten Administratoren aber auch weitere Daten wie Temperaturen oder Spannungen im Auge behalten, denn diese haben einen erheblichen Einfluss auf die Haltbarkeit der Serverkomponenten.
Nun können Sie natürlich externe Sensoren und Temperaturfühler in ihr Rechenzentrum einbauen und diese abfragen. Doch bevor Sie in externe Geräte investieren, lohnt ein Blick auf die im System bereits vorhandenen Sensoren, wie Sie deren Informationen abfragen und Ihrem Metrik-Dashboard hinzufügen. Dieser Pfad empfiehlt sich auch für Nutzer, die gemietete Server eines Hardwareproviders nutzen und keinen physischen Zugriff auf deren Rechenzentren haben. Hier kann die Sensorüberwachung für Überraschungen sorgen. So zum Beispiel, als die Disk-Temperaturen in einem RAID-Verbund offenbarten, dass eine von vier Platten dauerhaft 20 Grad wärmer als alle anderen war. In diesem Fall erklärte das, weshalb dieses Laufwerk innerhalb eines Jahres gleich zwei Mal ausfiel und getauscht werden musste. Aufgrund der aufgezeichneten Metriken erhielt der Nutzer dann eine Austauschmaschine.
Für diejenigen Leser, die noch keinen TIG-Stack in Ihrem Rechenzentrum oder auf Ihrem Cloudserver betreiben, stellen wir nachfolgend eine simple Lösung mit Containern unter Podman vor.
Darüber, wie Sie mithilfe von Tools wie InfluxDB, Telegraf oder Collectd Metriken ihrer laufenden Systeme abfragen und in Grafana grafisch darstellen, haben wir bereits mehrfach berichtet. Doch bislang konzentrierten sich die Workshops auf die grundlegende Softwarearchitektur eines TICK-Stacks – Telegraf, InfluxDB, Chronograf, Kapacitor; alternativ TIG mit Grafana statt Chronograf oder CIG mit Collectd statt Telegraf – und wie Sie damit Leistungsdaten ihrer Umgebung einsammeln. Damit wissen Sie zwar, wie voll Ihre Massenspeicher sind und welche Performance die CPUs liefern. Neben den reinen Leistungsdaten wie Systemlast sollten Administratoren aber auch weitere Daten wie Temperaturen oder Spannungen im Auge behalten, denn diese haben einen erheblichen Einfluss auf die Haltbarkeit der Serverkomponenten.
Nun können Sie natürlich externe Sensoren und Temperaturfühler in ihr Rechenzentrum einbauen und diese abfragen. Doch bevor Sie in externe Geräte investieren, lohnt ein Blick auf die im System bereits vorhandenen Sensoren, wie Sie deren Informationen abfragen und Ihrem Metrik-Dashboard hinzufügen. Dieser Pfad empfiehlt sich auch für Nutzer, die gemietete Server eines Hardwareproviders nutzen und keinen physischen Zugriff auf deren Rechenzentren haben. Hier kann die Sensorüberwachung für Überraschungen sorgen. So zum Beispiel, als die Disk-Temperaturen in einem RAID-Verbund offenbarten, dass eine von vier Platten dauerhaft 20 Grad wärmer als alle anderen war. In diesem Fall erklärte das, weshalb dieses Laufwerk innerhalb eines Jahres gleich zwei Mal ausfiel und getauscht werden musste. Aufgrund der aufgezeichneten Metriken erhielt der Nutzer dann eine Austauschmaschine.
Für diejenigen Leser, die noch keinen TIG-Stack in Ihrem Rechenzentrum oder auf Ihrem Cloudserver betreiben, stellen wir nachfolgend eine simple Lösung mit Containern unter Podman vor.
TIG mit Podman
Ein Setup mit Grafana und Influxdb lässt sich sehr flott mit Containern aufsetzen. Die Verwaltung übernimmt dabei systemd, sodass sich die Container wie ein Systemdienst verhalten und auch per systemctl enable direkt nach dem Systemstart automatisch hochfahren. Für unser Szenario arbeiten die Komponenten eigenständig und mit eigenen IP-Adressen. Damit lassen sich verschiedene Konstellationen ausprobieren und mehrere Versionen der InfluxDB gleichzeitig nutzen.
Damit die Container mit eigenen IP-Adressen arbeiten, benötigen Sie einen Server mit einer Network-Bridge und darauf ein Podman-Netzwerk vom Typ "Bridge" [1]. Im Internet kursieren diverse Anleitungen, die das Bridged-Container-Netzwerk mit dem Typ "Macvlan" erzeugen. Bei diesem Typ können aber die Container nicht mit dem Host selbst kommunizieren. Im Testsetup heißt unser Bridge-LAN "pub_net" und wird in der Datei "/etc/cni/net.d/pub_net.conflist" beschrieben. Das Setup läuft auf einem Server mit RHEL 8, CentOS 8 Stream oder einem Enterprise-Linux-8-Klon und dem installierten Paket "Podman".
InfluxDB mit Flux
Mit der Version 2 hat InfluxDB eine Reihe wesentlicher Änderungen eingeführt, unter anderem die Abfragesprache "Flux" als Standard. Viele Anwender bevorzugen nach wie vor "InfluxQL" der Version 1.x, was auch die Integration mit Grafana wesentlich vereinfacht. Für Flux bietet Grafana leider immer noch keinen komfor-tablen grafischen Query-Editor. Hier hilft Flux-Anfängern übrigens ein simpler Trick: Die neue InfluxDB-Web-UI stellt selbst einen grafischen Query-Editor bereit. Bauen Sie dort Ihre Abfrage zusammen und kopieren Sie dann den resultierenden Flux-Code in das Grafana-Panel.
Das Setup mit Podman erlaubt, dass im Workshop einfach beide Varianten zum Einsatz kommen. So können Sie sich in aller Ruhe mit beiden Versionen auseinandersetzen und dann entscheiden, welche sie produktiv verwenden wollen. Für Influx in der Version 1.8 erstellen Sie einen systemd-Service in der Datei "/etc/ systemd/system/flux18.service" nach der Vorlage im Listingkasten.
Listing: systemd-Service
[Unit]       Description=Influxdb 1.8       After=network-online.target       Wants=network-online.target [Service]       ExecStartPre=mkdir -p /var/pods/flux18/etc       ExecStartPre=mkdir -p /var/pods/flux18/data       ExecStartPre=-/bin/podman kill flux18       ExecStartPre=-/bin/podman rm flux18       ExecStartPre=-/bin/podman pull docker.io/influxdb:1.8       ExecStart=/bin/podman run \            --name flux18 \            --volume /var/pods/flux18/etc:/etc/influxdb:Z \            --volume /var/pods/flux18/data:/var/lib/influxdb:Z \            --net pub_net \            --ip 192.168.2.81 \            --mac-address 52:54:C0:A8:02:51 \docker.io/influxdb:1.8      ExecStop=/bin/podman stop flux18 [Install]       WantedBy=multi-user.target
Wenn Sie nun systemctl start flux18 eingeben, wird systemd zunächst zwei Verzeichnisse unterhalb von "/var/pods/ flux18" anlegen, in die der Container die Configuration (etc) und die eigentlichen Daten (data) ablegt. Damit bleiben diese Informationen auch nach einem Stopp oder Neustart des Containers auf dem Host-System erhalten. Die IP-Adresse des Containers und die Mac-Adresse geben Sie statisch an. Für Tests mit InfluxDB 2 erzeugen Sie die Datei "/etc/systemd/system/flux24.service" nach exakt dem gleichen Schema. Ändern Sie die IP- und Mac-Adresse (in unserem Setup auf ".82" und ":52"), tauschen Sie "flux18" beim Containernamen und den Verzeichnissen gegen "flux24" aus und ändern Sie die beiden Zeilen des Docker-Templates von "docker.io/influxdb:1.8" auf "docker.io/influxdb:2.4". Da InfluxDB 2 standardmäßig keine Zugriffe ohne Logins mehr zulässt, müssen Sie nach dem Start des Containers im Browser auf "http://192. 168.2.82:8086" zugreifen und den Basis-Setup-Wizard durchlaufen. Dort erzeugen Sie auch gleich zwei API-Token für Telegraf und Grafana.
Dem Schema folgend erstellen Sie eine Servicedeklaration für Ihren Grafana-Container. Der Name lautet hier "grafana", das Image verweist auf "docker.io/grafana/grafana". Die beiden Verzeichnisse für den Grafana-Container sind "logs" und "data":
--volume
 /var/pods/grafana/data:/var/lib/grafana:Z \
--volume
/var/pods/grafana/logs:/var/log/grafana:Z \
Zudem können Sie am Anfang der Datei angeben, dass systemd den Grafana-Container bei Systemstart erst nach dem Influx-Container startet.
After=network-online.target flux18.service
Im Testsetup erhält Grafana die IP-Adresse .80 und die entsprechende Mac-Adresse :50. Auch bei Grafana durchlaufen Sie im Browser zunächst das initiale Setup auf "http://192.168.2.80:3000".
Sensoren im System
Je nach Hardware verfügen die meisten Motherboards und Chipsätze bereits über eine ganze Reihe eingebauter Sensoren, die sich über das Betriebssystem abfragen lassen. Das passende Toolset hierfür hört auf den Namen "Linux Management Sensors" und lässt sich auf EL-Systemen via yum/dnf install lm_sensors einrichten. Um die vorhandenen Sensoren aufzuspüren, bringt das Paket das Tool "sensors-detect" mit. Dies erkennt die Chipsatz-Sensoren sowie i2c-Busse, daran angebundene Sensoren und schreibt die initiale Modulkonfiguration in die Datei "/etc/sysconfig/ lm_sensors". Ein Aufruf des Tools "sensors" listet die gefundenen Sensoren und deren Werte. Je nach System sind nicht alle davon tatsächlich brauchbar. Stellenweise findet lm-sensors Sensoren, die es im System gar nicht gibt. Das liegt häufig daran, dass der Hardwarehersteller zwar den Anschluss nebst Controller, nicht aber den Sensor selbst eingebaut hat. Solche Sensoren fallen aber sofort auf, denn Gehäusetemperaturen von 0 oder -273 Grad sind dann doch eher unwahrscheinlich.
In der Praxis findet Sensors jedoch bei nahezu allen Systemen zumindest das "Core"-Package und damit die Temperaturinformationen des CPU-Chips und aller darin enthaltenen CPU-Kerne. Das gibt dem Anwender schon mal eine wichtige Einsicht, was besonders bei passiv gekühlten Edge-Devices oder Servern mit einem kleinen Formfaktor (etwa Intel NUC) eine große Rolle spielt. Sollte das System zudem keine Sensoren für die Lüfterdrehzahlen haben, lässt die CPU-Temperatur Rückschlüsse auf Lüfterprobleme zu.
Bild 2: Sensordaten via SNMP laufen in das Dashboard der Online-USV ein. Anders als bei einer Standby-USV filtert hier der Doppelwandler alle Netzschwankungen heraus
Festplatten überwachen
Ein besonderes Augenmerk sollten Sie auf die Überwachung der Festplatten richten. Dabei spielt es keine Rolle, ob es sich dabei um altmodische mechanische Laufwerke oder moderne SSDs handelt. Hier gibt es eine ganze Reihe wichtiger Metriken, die es zu überwachen gilt. Bei den mechanischen Laufwerken spielt natürlich die Temperatur eine große Rolle. Falls der Server keinen separate Temperaturfühler im Gehäuse hat, können Sie auch über die Plattentemperatur Rückschlüsse auf die Raumtemperatur im Rechenzentrum selbst ziehen. Fällt beispielsweise die Klimaanlage eines Serverraums aus, zeigt sich das recht schnell durch den Anstieg der Laufwerkstemperatur. Zudem verfügen sowohl klassische Platten als auch SSDs über die SMART-Funktion. Diese versucht, Defekte und Ausfälle des Massenspeichers vorherzusagen. Für den Administrator sind dabei Informationen zu Lese- und Suchfehlern wichtig, die auf Probleme mit einzelnen Laufwerken oder dem kompletten Array schließen lassen.
Auf Linux-Servern gibt es zwei wesentliche Tools, die Informationen zu den Lauf-werkstemperaturen ermitteln: hddtemp und smartctl. Wie der Name bereits vermuten lässt, liefert hddtemp nur die Temperatur eines Laufwerks, während smartctl auch Daten zu Fehlerraten und dem SMART-Status zurückgibt. Letztere Werte sind allerdings mit Vorsicht zu genießen, da verschiedene Festplattenhersteller sehr unterschiedliche Werte zurückliefern. In den Setups des Workshops erhalten wir beispielsweise von Seagate-Enterprise-Platten dauerhaft hohe Werte bei Such- und Lesefehlern, während Toshiba-Laufwerke nur "0" zurückliefern. Seagate wird hier die rohen Fehlerraten vor der internen Fehlerkorrektur ausgeben. Die SMART-Spezifikation legt nicht exakt fest, was die Ausgabewerte zurückliefern. Da beide Tools Root-Rechte zum Abfragen der Informationen benötigen, können Metrik-Kollektoren wie Telegraf, das im Userspace läuft, nur mit leichten Umwegen auf die Daten zugreifen. Dazu später mehr, wenn es darum geht, die gesammelten Werte zu Influx zu senden. Die Tools installieren Sie auf einem EL8-System via dnf install hddtemp und dnf install smartmontools.
Intelligentes Plattform-Management mit IPMI
Serverhersteller bauen in der Regel einen BMC-Chip (Baseboard Management Controller) in ihre Server ein, der dann ein IPMI (Intelligent Platform Management Interface) bereitstellt. Über dieses Interface erhalten Sie sehr detaillierte Informationen zum System, die der BMC unabhängig vom Betriebssystem sammelt. Je nach Implementierung lässt sich das IPMI vom lokalen System aus oder auch via LAN ansprechen. Was sich via IPMI alles abrufen lässt, hängt vom verwendeten BMC ab und unterscheidet sich je nach Hersteller und Alter des Servers. Für diesen Workshop setzen wir verschiedene Systeme ein: einen Intel NUC und einen Cloudserver von Hetzner, die über keinen BMC verfügen.
Ein älterer HP-Microserver der 8. Generation liefert zumindest ein paar Temperaturwerte von RAM, Chipset und Gehäuse, sein großer Bruder der DL380- Generation 8 verrät dagegen den aktuellen Stromverbrauch des Netzteils und Unmengen von Temperaturen an nur jeder erdenklichen Stelle im Chassis. Neuere Dell- und Fujitsu-Server berichten darüber hinaus noch sehr detailliert über Drehzahlen der Lüfter sowie Spannungen und Ströme der Chipsets, DIMMs und Prozessoren. Um auf das lokale IPMI zugreifen zu können, benötigen Sie das Ipmitool, das Sie ganz einfach via dnf install ipmitool einrichten. Die Liste der verfügbaren Sensoren und Werte verrät: ipmitool sdr elist.
Daten über die USV sammeln
In einem Serverraum darf natürlich die unterbrechungsfreie Stromversorgung, kurz USV, nicht fehlen. Je nach Bauart und Überwachungsanschluss erhält der Administrator auch von diesem Gerät wertvolle Informationen zum Zustand seiner IT. Dabei geht es nicht nur um die Akkulaufzeit und die Auslastung. Auch der Spannungsverlauf liefert wichtige Informationen. Abstürze von Maschinen oder ein unerwartetes Ableben einer Komponente wie einer Festplatte gehen oftmals mit Spannungsschwankungen der Netzversorgung einher.
Große USV mit LAN-Management-Adapter geben diese und andere Informationen via SNMP preis, dazu gleich mehr. Einfache USV kommen ohne LAN-Interface, aber mit einer seriellen oder USB-Schnittstelle fürs Monitoring. Oft kommt dann das Toolset "NUT" (Network UPS Tools) zum Einsatz, das die USV überwacht und kontrollierte Shutdowns mehrerer Systeme im LAN organisiert. Der UPS-Daemon "upsd" aus dem NUT-Toolset steht dabei permanent mit der USV-Anlage in Kontakt und fragt laufend die Metriken ab. Über die geeigneten Metrik-Grabber gelangen dann auch diese Informationen zu Influx und in das Grafana-Dashboard.
Abfragen via SNMP
Viele aktive Komponenten im LAN offerieren das Simple Network Management Protocol. SNMP kommt heute nur selten zur aktiven Verwaltung der Komponenten an sich zum Einsatz, jedoch eignet es sich hervorragend, um Metriken abzufragen und einzusammeln. Die SNMP-Protokollversionen 1 und 2 gelten als unsicher. Fast alle Geräte mit SNMP erlauben jedoch den Betrieb dieser Protokolle beschränkt auf das lokale LAN und lediglich im "ReadOnly"-Modus. Mit dem installierten Paket "net-snmp" auf dem System kann Telegraf einzelne SNMP-Werte oder komplette Tabellen einlesen und an InfluxDB weiterleiten. Welche Werte das sind, hängt meist von der herstellereigenen SNMP-Management-Information-Base (MIB) ab. Diese gibt Aufschluss darüber, welche Object IDs (OID) existieren und wie deren Adresse lautet. Für die Custom-SNMP-MIBs finden sich ausführliche Dokumentationen auf den Webseiten der jeweiligen Hersteller.
Im konkreten Beispiel mit einer USV von APC (Schneider Electric) sieht eine passende Konfiguration für die Custom-MIB des Herstellers wie folgt aus. Der Eintrag
[[inputs.snmp]]
      agents = ["<IP-Adresse des UPS-Management-Boards>:161"]
      version = 2
      community = "public"
      name = "snmp"
stellt die Verbindung zum Management Adapter via UDP her. Informationen über die Batterietemperatur, die Eingangs- sowie Ausgangsspannung liefert
[[inputs.snmp.field]]
      name = "Battery Temperature"
      oid = "1.3.6.1.4.1. 318.1.1.1.2.2.2.0"
[[inputs.snmp.field]]
      name = "PowerIN"
      oid = "1.3.6.1.4.1.318.1.1.1.3.2.1.0"
[[inputs.snmp.field]]
      name = "PowerOUT"
      oid = "1.3.6.1.4.1. 318.1.1.1.4.2.1.0"
Ähnliche Metriken können Sie auf diesem Weg auch von Switches oder von Routern erhalten.
Daten sammeln via Telegraf
Es gibt viele verschiedene Wege, um die Sensordaten von den vorgestellten Tools abzurufen und an Influx zu übermitteln. Anwender können beispielsweise eigene Skripte schreiben, die entweder direkt mit der InfluxDB-API auf Port 8068 des InfluxDB-Servers kommunizieren oder über den InfluxDB-Client Abfragen senden.
In den meisten Fällen kommen jedoch Metrik-Kollektoren wie Telegraf oder Collectd auf den Systemen zum Einsatz. Beide bringen Input-Module mit, die alle oben vorgestellten Sensorquellen direkt unterstützen. Im Workshop sehen wir uns die Telegraf-Konfiguration an. Vor den Input-Modulen stehen in der "/etc/telefgraf/telegraf.conf"-Datei jedoch zunächst die Outputs. Passend zum Workshopbeispiel soll der zu überwachende Host seine Daten sowohl an den InfluxDB-1.8- als auch den 2.4-Host liefern. Die passenden Einträge sehen daher wie folgt aus: Für Influx 1.8
[[outputs.influxdb]]
      url = "http://192.168.2.81:8086"
     database = "telegraf"
Etwas aufwendiger wird es bei InfluxDB 2.4. Hier müssen Sie zuvor in der Basis-Konfiguration des InfluxDB-Pods ein API-Token, die Organisation und einen Bucket anlegen:
[[outputs.influxdb_v2]]
      urls = ["http://192.168.2.82:8086"]
      token = "<token>"
      organization = "<organisation>"
      bucket = "<bucket>"
Wenn Sie beide Outputs in Ihrer "telegraf.conf"-Datei angeben, wird Telegraf auch alle Metriken an beide Influx-Pods senden. Alternativ könnten Sie statt InfluxDB auch Prometheus verwenden. Um den Rahmen des Workshops nicht zu sprengen, lassen wir diese Option an dieser Stelle außen vor. Die Input-Quellen können Sie ebenfalls direkt in "/etc/telegraf/telegraf.conf" anhängen.
Für Debug-Zwecke empfiehlt es sich jedoch, für jeden Input eine eigene CONF-Datei unter "/etc/telegraf/telegraf.d/" zu erstellen. Dann können Sie sehr einfach mithilfe der Kommandozeile
telegraf --test --config /etc/telegtaf/telegraf.d/<sensor>.conf
die Ausgabe der Sensorquellen einzeln testen und die gelieferten Daten prüfen.
Um lm-Sensors zu nutzen, brauchen Sie nichts anderes als eine CONF-Datei namens "sensors.conf" mit dem Einzeiler "[[inputs.sensors]]". Natürlich müssen Sie auf dem System zuvor das Toolset "lm_ sensors" installiert und konfiguriert haben. Dasselbe gilt auch für den Ipmi-Input. Hier genügt die Konfigurationszeile "[[inputs. ipmi_sensor]]" in der passenden CONF-Datei.
Etwas aufwendiger wird es bei SMART oder hddtemp. Beide Tools brauchen root-Rechte, der Telegraf-Client arbeitet jedoch im Userspace und erhält somit keinen Zugriff auf Geräte unterhalb von "/dev". Hddtemp umgeht das Problem recht elegant mit einem eigenen Daemon, den Sie via systemctl enable hddtemp --now aktivieren. Der Daemon stellt dann die abgefragten Plattentemperaturen über einen simplen TCP-Port auf "localhost:7634" für den Userspace bereit. Mit dem laufenden hddtemp-Dienst genügt in der Konfigurationsdatei "hddtemp. conf" dann ebenfalls der Einzeiler "[[inputs.hddtemp]]".
SMART auf der anderen Seite kommt um root-Rechte nicht herum. Um diesen Input zu nutzen, müssen Sie dem Nutzer "telegraf" root-Rechte am "smartctl"-Tool verschaffen. Legen Sie dazu eine Datei "/etc/sudoers.d/telefraf" mit folgendem Inhalt an:
telegraf ALL = NOPASSWD: /usr/sbin/smartctl
Dann können Sie in der Telegraf-Konfigurationsdatei "smart.conf" den Input aktivieren:
[[inputs.smart]] use_sudo = true
In unseren verschiedenen Workshopsetups sorgte smartctl allerdings für Probleme, speziell auf dem HP-Microserver mit einer schwachen Celeron-CPU. Hier verursachte der SMART-Input nämlich stellenweise extrem hohe CPU-Belastungen, die sich negativ auf die laufenden Dienste auswirkten. Auf diesem System kommt somit ausschließlich hddtemp zum Einsatz.
Um die Werte einer via NUT verwalteten USV abzurufen, brauchen Sie die IP-Verbindung zum NUT-Server und einen passenden Monitoring-User samt Passwort, den Sie auf dem NUT-Server in "/etc/ups/ upsd.user" deklariert haben. Der Eintrag in der "/etc/telegraf/telegraf.d/ups. conf" lautet dann entsprechend:
[[inputs.upsd]]
      server = <Server-IP-Adresse>
      port = 3493
      username = "<upd-user>"
      password = "<ups-user-password>"
Laufen nut und Telegraf auf demselben Host, entfällt die Zeile "server".
Telegraf ohne Plug-in verwenden
Die Auswahl der Plug-ins für Telegraf ist groß. Dennoch könnten Sie mit proprietären Metrikquellen konfrontiert werden, die Telegraf nicht kennt. Hier könnten Sie zum einen ein Skript verwenden, das wie eingangs erwähnt direkt mit der InfluxDB-API kommuniziert. Falls Sie aber ausschließlich via Telegraf Daten versenden möchten, nutzen Sie dessen Option "[[input.exec]]". Dabei führt Telegraf ein angegebenes Skript (Bash, Python, Perl et cetera) aus und sendet die zurückgelieferten Daten an InfluxDB. Die Antwortdaten verlangt "input.exec" im Format name key=value, also beispielsweise
raumtemperatur kueche=20
Ein passender Eintrag in der Telegraf-Konfiguration würde dann beispielsweise so aussehen:
[[inputs.exec]]
       commands = ["sh /etc/telegraf/ script/script1.sh",
]
timeout = "5s"
data_format = "influx"
Wichtig ist dabei, dass Telegraf das Custom-Skript in seinem Userspace, also mit Rechten des Benutzers "telegraf" ausführt. Hier kommen Anwender beim Testen ihrer Inputs stellenweise ins Schleudern, wenn sie telegraf --test auf einer Kommandozeile mit root-Rechten ausführen und dort alles funktioniert, während der Telegraf-Daemon im Nutzerkontext von "telegraf" läuft und dann plötzlich keine Werte liefert. Tests müssen Sie daher immer im Rechtekontext von "telegraf" ausführen.
Collectd direkt oder mit Umwegen
Als Metrikkollektor funktioniert collectd nahezu identisch wie Telegraf, zumindest wenn Sie InfluxDB in der Version 1.8 einsetzen. Diese Version nimmt noch Metriken von collectd direkt entgegen. In unserem Beispiel finden Sie die InfluxDB-Konfiguration für den Influx­DB-1.8-Container im Host-Vertzeichnis "/var/pods/flux18/etc/influxdb.conf":
[[collectd]]
       enabled = true
       bind-address = "192.168.2.81:25826"
       database = "collectd"
       typesdb = "/usr/share/collectd/types.db"
Ab der Version 2 gibt es bei InfluxDB keinen direkten collectd-Input mehr. Wer mit collectd Metriken sammelt, muss hier den Umweg über eine telegraf-Instanz nehmen, die in etwa wie folgt konfiguriert ist:
[[inputs.socket_listener]]
       service_address = "udp://:25826"
       data_format = "collectd"
Gefolgt von "[[outputs.influxdb_v2]]", wie weiter oben im Text beschrieben. Bei den Inputs liefert Collectd alle erwähnten Funktionen. Ein Config-Beispiel in "/etc/collectd.conf", bei dem Collectd hddtemp abfragt und die Werte zum Influx 1.8-Server liefert, sieht dann so aus:
LoadPlugin hddtemp
<Plugin hddtemp>
       Host "127.0.0.1"
       Port "7634"
</Plugin>
<Plugin network>
           Server "192.168.2.81" "25826"
</Plugin>
Fazit
Mit Sensordaten erscheinen die reinen Performancemetriken Ihrer Server- und Cloudsysteme in einem anderen Kontext. Plötzlich können Sie Performanceeinbrüche eines Server seiner überhitzten CPU zuordnen und dieses Problem vielleicht mit einem zu langsamen Lüfter in Verbindung bringen. Sie sehen dann auch Plattenausfälle im Kontext von Stromschwankungen oder Peaks.
Neben der reinen Überwachung und Visualisierung der Sensordaten können Sie das Alerting und Systemmanagement damit verbinden. Sollte die "Intake"-Temperatur eines Ihrer Server über 40 Grad ansteigen, gibt es wahrscheinlich ein Problem mit der Klimaanlage im Serverraum und Sie sollten alle oder zumindest weniger wichtige Systeme zum Schutz der Hardware herunterfahren.
(dr)
Link-Codes