#zabbix
Mein Grafana konnte über Nacht keine Daten mehr aus Zabbix auslesen. Ich verwende dieses Plugin dafür, das hat all die Jahre funktioniert – und nun plötzlich nicht mehr?
Die Verbindung geht über https zum Zabbix-Server. Username/Paßwort haben sich definitiv nicht geändert.
Drölfzigmal habe ich das Paßwort neu eingegeben, die Connection entfernt, das Plugin neu installiert – alles umsonst.
Ah Moment: Neulich habe ich doch 2FA (TOTP) im Zabbix angeschaltet?!?
Dann war es schnell erledigt: Im Zabbix ein API-Token erzeugt, sicherheitshalber ohne Ablaufdatum 😉
Und dann die Auth umgestellt:
Tja, und schon geht die Schei*e!
CVE-2024-22116 (CVSS 9.9): Critical RCE Vulnerability Found in Zabbix Monitoring Solution https://securityonline.info/cve-2024-22116-cvss-9-9-critical-rce-vulnerability-found-in-zabbix-monitoring-solution/
Unser Zweit-Kühlschrank hat eine Macke, und zwar hört er ab und an, die letzen 3 Wochen vielleicht 3 mal, auf zu kühlen.
Als Feierabendbiertrinker bemerke ich das zwar, aber Monitoring by Biertrinktemperatur ist fehleranfällig, zumal man eigentlich 24/7 trinken müßte.
Der Kühlschrank erholt sich wieder, wenn man ihn einen Tag (möglicherweise auch kürzer, ich habs nicht getestet) vom Strom nimmt.
Irgendwann werden wir ihn ersetzen müssen, aber nicht demnächst.
Um also die Leber zu entlasten, muß ein Monitoring her, natürlich mit Alarmierun, Eskalationen und dem ganzen Zinnober.
#Zabbix!
Heute kam das Thermometer, ich habe schon lange eine Wetterstation, an die ich mehrere Sensoren für Temperatur und Luftfeuchtigkeit anknüppern kann.
Gemacht, getan, jetzt nur noch die Temperatur auslesen.
Das kann zwar lokal bleiben, dann habe ich aber nur eine Anbindung an Home Assistant. Vermutlich könnte ich Zabbix auch an Home Asstant anflanschen, aber einfacher gehts über die API im Internet:
#!/bin/bash
/usr/bin/curl -s \
'https://api.ecowitt.net/api/v3/device/real_time?application_key=[…]&api_key=[…]&mac=[…]&call_back=all&temp_unitid=1' | \
/usr/bin/jq -r .data.temp_and_humidity_ch8.temperature.value
Funktionert:
❯ ./wetterstation.hwr.eisfach-temperatur.sh
-14.7
Jetzt nur noch ein Item basteln in Zabbix:
Und den entsprechenden Trigger, der bei einer Temperatur gleich oder über -15°C auslösen soll:
Einbiegen auf die Zielgerade, wir brauchen ja noch die Benachrichtigung:
Und nun nur noch, wer auf welchem Wege alarmiert werden soll: ich.
Funzt!
Und wenn wir schon dabei sind: #Grafana!
Wir schießen uns in die Füße, erneut
Das Schöne an Linux ist ja, daß man als root über sämtliche Waffen vefügt, um sich gepflegt in die Füße zu schießen, und nutzerfreundlich wie Linux nun mal ist, sind diese Waffen auch schon geladen, ausgerichtet und entsichert – man muß nur noch abdrücken.
Vor ein paar Wochen: Ich wollte ein Video mit nach AV1/Opus umcodieren und hatte irgendwie nicht begriffen, daß die Encoder bei Debian im ganz normalen Repository liegen und war also der Meinung, ich müsse das selbst übersetzen. Das ist ein ziemlich dickes Brett, was man da bohren muß, zum Beispiel sind manche Bibliotheken in golang geschrieben, so daß man noch ein go nachinstallieren muß. Ich fing also an, und natürlich wurden erstmal tonnenweise Abhängigkeiten nachinstalliert, bevor es überhaupt ans Bauen ging. Am Ende hatte es funktioniert – und ich stellte fest, daß das völlig umsonst war: Debians ffmpeg liefert alles mit, was ich brauche. Lehrgeld.
Der Rechner hat eine relativ kleine Root-Partition, und der große Rest wird für ZFS verwendet. Alle Dienste, die ins Internet exponiert sind, laufen dort. Also jedenfalls / war arg voll, aber ich wußte nicht mehr, was ich alles sinnloserweise nachinstalliert hatte. Da kam mir eine Idee: Einfach alle dev-Pakete löschen und hinterher noch ein autoremove, damit auch die Abhängigkeiten gelöscht werden. Hat gut funktioniert, danach war wieder einiger Platz frei. Das war vor ein paar Tagen.
Heute sehe ich mal wieder ins Zabbix. Da steht auf einmal, daß zfs-zed.service nicht laufen würde. Also versuche ich ihn zu starten, doch systemctl meint, es gäbe ihn nicht, und in der Tat: es gibt ihn nicht. Ich ahne etwas:
Start-Date: 2024-05-05 20:58:18
Commandline: apt -y purge dpkg-dev
Purge: build-essential:amd64 (12.9), zfs-zed:amd64 (2.2.3-1~bpo12+1), zfs-dkms:amd64 (2.2.3-1~bpo12+1), dpkg-dev:amd64 (1.21.22), xtables-addons-dkms:amd64 (3.23-1), dkms:amd64 (3.0.10-8+deb12u1)
End-Date: 2024-05-05 20:58:53
ZFS-on-Linux ist aus Lizenzgründen als dynamisches Kernelmodul realisiert. Und muß mit dkms(8) gebaut werden, was diverse Header erwartet, die eben in dev-Paketen liegen. Die hatte ich aber gelöscht, und mein tapferes autoremove hatte dann das komplette ZFS wegrasiert (aber nicht die Daten). Und solange die Büchse läuft, macht das auch nichts.
Heute dachte ich dann, ich sollte nicht länger warten mit einem Reboot. Code, der nur noch im RAM liegt, nee, muß nicht sein. Also reboot und tja, kein ZFS, keine Dienste.
Die Lösung: Nachsehen, ob der Pool noch da ist (zpool import) und dann importieren (zpool import <poolname>) Reboot, alles wieder schön.
Und die Flinten nachladen nicht vergessen fürs nächste mal!
Hat jemand eine Vorstellung, warum man in #Zabbix mit der Eulerschen Zahl rechnen wollte?
https://www.zabbix.com/documentation/current/en/manual/appendix/functions/math#exp
Ich suche eine Möglichkeit, mich via #Zabbix über neue Releases bei #Nextcloud informieren zu lassen. Eine Website, die sich nur bei neuem Release ändert, wäre OK, also sowas wie https://gthub.com/nextcloud/server/releases - aber da sind auch die ganzen Prereleases drin. Auch einen (RSS|Atom)-Feed würde ich nehmen, ein Email-Newsletter hilft mir nicht.
Ideen?
Ich glaube, ich werde #Influxdb als Datenquelle für #Grafana wieder rauswerfen.
Da Grafana auch #Zabbix als Datenquelle verwenden kann und die Trigger/Notifications bei Zabbix weitaus mächtiger als die von Grafana sind, sehe ich keinen Grund für Influx.
Damit entfällt dann auch #Telegraf, zumal das weitaus umständlicher als Zabbix zu konfigurieren ist.
Warum Linux für Vollpfosten segensreich ist:
Ich hatte vor vielleicht 4 Wochen einen Webserver von Opensuse auf Debian umgestellt. Das ist wahrlich keine Raketentechnologie, hat aber ein paar Stolperfallen. Hat aber geklappt, alle waren zufrieden.
Bis auf ein zänkischen #Zabbix, das mir soeben meldet, ein Zertifikat (da laufen mehrere virtual hosts) würde in 3 Wochen auslaufen.
Was ist passiert? Nun, ganz klar, das ganze Lets-Encrypt Gedöns hatte ich komplett vergessen. Na großartig, die Maschine wurde komplett neu aufgesetzt, da gibt es die alten Skripte nicht, die sind weg :-(
Doch ist da noch ein freundliches #rsnapshot, das den Rechner über 12 Monate sichert, und natürlich habe ich dort die alten Skripte, die alte crontab.
Die werde ich heute Abend oder morgen gemütlich rüberkopieren, gegebenenfalls anpassen und testen - bin sehr zuversichtlich, daß die LE-Zertifikate wieder fein eintrudeln werden danach.
Also: Hasenfüße nehmen besser Linux, da gibt es einfache Lösungen für uns!
PS: Ich machs bislang mit dehydrated, mod_md sieht aber interessant aus - hat jemand damit Erfahrungen?
Zabbix: Downtime/Maintenance für einen einzigen Check?
Folgendes Problem mit #Zabbix: Ich habe einen Check der ab und zu für eine gewisse Zeit hin und her flapped (Disk I/O aus dem Linux-Template). Den würde ich nun gerne für ein paar Tage via Maintenance ruhig stellen, leider scheint Zabbix diese Möglichkeit nicht zu bieten. Ich kann eine ganze Hostgruppe, einzelne Hosts oder Tags in die Wartung nehmen, aber anscheinend nicht spezifische Checks.
Ich hatte mich jetzt damit beholfen auf dem Host das Tag Application gleich Performance in die Wartung zu nehmen, das ist aber weitgehender als nur einen einzelnen Check ruhigzustellen.
Das wundert mich doch massiv, so eine Funktion - für eine gewisse Zeit einen oder mehrere spezifische Checks ruhigzustellen - ist doch eigentlich Standard im Monitoring, oder übersehe ich was?
Ich wollte zu Studienzwecken eine REEST-API mit #Zabbix anknabbern.
COVID-Zahlen meines Heimatkreises.
Das geht:
~$ curl -s https://api.corona-zahlen.org/districts | jq '.data["13075"].delta.cases'
302
~$
Das ist nur der Einfachheit halber ein einziger Wert, nachher möchte ich mir in einem Rutsch gleich mehrere holen:
~$ curl -s https://api.corona-zahlen.org/districts | jq '.data["13075"].delta'
{
"cases": 302,
"deaths": 0,
"recovered": 274,
"weekIncidence": -7.64490276104101
}
~$
Wunderbar, das könnte ich in einem externalscript verwursten. Aber Zabbix kann das ja auch direkt?
Ich bastle mir also ein Item:
Das braucht einen Präprozessor, der die Daten verarbeitet, bevor sie in der DB landen:
Doch ach, das funktioniert nicht :-(
Hat jemand einen gut begründbaren Verdacht, was hier flasch ist?
#Zabbix ist ja bekanntermaßen Gottes eigenes Monitoring-Tool. Und dank UserParameter und externalscripts kann es faktisch JEDEN Input abspeichern und verarbeiten, den es gibt.
Nur sind die Dashboards und Graphen in Zabbix leider eher hölzern. Danke, Alexander Zobnin, für Dein Plugin! Damit kann man Zabbix als Datasource für #Grafana verwenden und sich so die schönsten dashboards malen :-)
Jetzt kann ich auch meine Lüftungsanlage mit #Zabbix auslesen.
Nicht daß das irgendwie sinnvoll wäre - aber hey, ein sprechender Frosch ist cool! :-)
