Schlagwort: zabbix

Tiefkühlfach monitoren

Haus, Home Automation, IT
Comments

Unser Zweit-Kühl­schrank hat eine Macke, und zwar hört er ab und an, die let­zen 3 Wochen viel­leicht 3 mal, auf zu kühlen.
Als Fei­er­abend­bier­trin­ker bemer­ke ich das zwar, aber Moni­to­ring by Bier­trink­tem­pe­ra­tur ist feh­ler­an­fäl­lig, zumal man eigent­lich 24/7 trin­ken müßte.
Der Kühl­schrank erholt sich wie­der, wenn man ihn einen Tag (mög­li­cher­wei­se auch kür­zer, ich habs nicht getes­tet) vom Strom nimmt.
Irgend­wann wer­den wir ihn erset­zen müs­sen, aber nicht demnächst.

Um also die Leber zu ent­las­ten, muß ein Moni­to­ring her, natür­lich mit Alar­mie­rung, Eska­la­tio­nen und dem gan­zen Zinnober.
#Zab­bix!
Heu­te kam das Ther­mo­me­ter, ich habe schon lan­ge eine Wet­ter­sta­ti­on, an die ich meh­re­re Sen­so­ren für Tem­pe­ra­tur und Luft­feuch­tig­keit anknüp­pern kann.
Gemacht, getan, jetzt nur noch die Tem­pe­ra­tur auslesen.
Das kann zwar lokal blei­ben, dann habe ich aber nur eine Anbin­dung an Home Assistant. Ver­mut­lich könn­te ich Zab­bix auch an Home Assistant anflan­schen, aber ein­fa­cher 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

Funk­tio­niert:

❯ ./wetterstation.hwr.eisfach-temperatur.sh
-14.7

Jetzt nur noch ein Item bas­teln in Zabbix:

Und den ent­spre­chen­den Trig­ger, der bei einer Tem­pe­ra­tur gleich oder über ‑15°C aus­lö­sen soll:

Ein­bie­gen auf die Ziel­ge­ra­de, wir brau­chen ja noch die Benachrichtigung:

Und nun nur noch, wer auf wel­chem Wege alar­miert wer­den soll: ich, via Telegram.

Funzt!

Und wenn wir schon dabei sind: #Graf­a­na!

 

Opensource hat nicht nur Nachteile ;-)

IT
Comments

Aus­gangs­si­tua­ti­on: Ich habe einen Zab­bix-Ser­ver im Inter­net, der monit­ort auch mei­nen klei­nen Rech­ner­zoo zu Hau­se, dazu noch IOT wie Wall­box, Mäh­ro­bo­ter, Dru­cker usw.
Dafür steht ein Raspi im Kel­ler, auf dem ein Zab­bix-Pro­xy plus ein Wire­guard mit dem Zab­bix-Ser­ver lau­fen. Der Ser­ver greift über den Wire­guard-Tun­nel auf den Pro­xy zu. Vor­teil mit dem Tun­nel: Die IP im Tun­nel ändert sich nie, auch wenn mein Inter­net-Zugang eine neue IP bekommt, und ich muß mich nicht um Trans­port­ver­schlüs­se­lung küm­mern. Das hat immer gut funk­tio­niert, bis ich auf dem Ser­ver auf Zab­bix 7 LTS hoch­ge­gan­gen bin. Und der woll­te nicht mehr mit dem Pro­xy, der ein Zab­bix 6 LTS ist.
Man soll­te mei­nen: Auf dem Raspi das 7‑er Repo­si­to­ry ein­tra­gen, upgraden und fertig.
So ein­fach ist es dann aber lei­der nicht: Mein Raspi ist 32 Bit (armhf), es gibt aber nur noch 64 Bit (aarch64). Zwar habe ich einen 64-Bit Ker­nel, aber das gesam­te User­land ist 32 Bit. Und Hoch­zie­hen geht nicht, man muß neu instal­lie­ren. Das ist zwar kei­ne Rake­ten­wis­sen­schaft, aber aufwendig.

Und nun?

Ein­fach: Zab­bix ist ja Open Source, also habe ich mir die Sourcen gezo­gen, ./configure --enable-ipv6 --prefix=/usr/local/zabbix-7.0.0 --enable-proxy --with-net-snmp --with-mysql && make install — und natür­lich hat das erst­mal nicht funk­tio­niert, weil diver­se Hea­der gefehlt haben. Also muß man die ent­spre­chen­den *-dev Pake­te nach­in­stal­lie­ren — und: Läuft.
Jetzt noch ein Unit-File für sys­temd schrei­ben, und alles ist wie­der fein.

Und irgend­wann dann doch auf 64 Bit gehen, dann kann ich auch wie­der das offi­zel­le Zab­bix-Repo­si­to­ry verwenden

Warum eine zentrale DB nicht immer eine gute Idee ist

IT
Comments

Ich ver­such­te, ein Zab­bix auf die aktu­el­le 7‑er Ver­si­on zu zie­hen und der Ver­such schlug fehl, das Front­end mecker­te, daß die DB-Ver­si­on zu alt sei.
Nach eini­ger Zeit fand ich im Log:

3888423:20240610:221530.805 current database version (mandatory/optional): 06040000/06040003
3888423:20240610:221530.805 required mandatory version: 07000000
3888423:20240610:221530.805 mandatory patches were found
3888423:20240610:221530.808 starting automatic database upgrade
3888423:20240610:221530.843 completed 0% of database upgrade
3888423:20240610:221530.905 completed 1% of database upgrade
3888423:20240610:221530.991 completed 2% of database upgrade
3888423:20240610:221531.038 completed 3% of database upgrade
3888423:20240610:221531.065 [Z3005] query failed: [1060] Duplicate column name 'allow_redirect' [alter table `dchecks` add `allow_redirect` integer default '0' not null]
3888423:20240610:221531.066 database upgrade failed on patch 06050012, exiting in 10 seconds

Auf einer ande­ren Kis­te hin­ge­gen hat­te es geklappt, ich glau­be aber, von einer 6.0 LTS eben auf 7.0 LTS. Die­ses hier war eine 6.4, und schein­bar soll­te erst zu 6.5 upge­gra­det wer­den, was fehl schlug, war­um auch immer. Kühn und bie­rer­mu­tigt habe ich dann ein­fach dchecks.allow_redirect gelöscht — mit mäßi­gem Erfolg: Folgefehler.
Der Zab­bix-Rech­ner ist eine VM im VMWare, da kann man (natür­lich vor Updates!) Snapshots anle­gen — und wenn das Update fehl schlägt, rollt man ein­fach zurück. Das ist eine Sache von ein paar Sekun­den. Doch wenn die DB auf einem ent­fern­ten Rech­ner liegt, mit eige­nem DBA, dann nützt ein Snapshot nichts.
So wer­de ich mor­gen den Kol­le­gen bit­ten müs­sen, einen Dump zurück zu spie­len. Und dabei die Daten von ca. 12 Stun­den ver­lie­ren (das ist aber nicht schlimm).
Erkennt­nis: Loka­le Daten­ban­ken sind schmerzfreier.

Wir schießen uns in die Füße, erneut

IT
Comments

Das Schö­ne an Linux ist ja, daß man als root über sämt­li­che Waf­fen vefügt, um sich gepflegt in die Füße zu schie­ßen, und nut­zer­freund­lich wie Linux nun mal ist, sind die­se Waf­fen auch schon gela­den, aus­ge­rich­tet und ent­si­chert — man muß nur noch abdrücken.

Vor ein paar Wochen: Ich woll­te ein Video mit nach AV1/Opus umco­die­ren und hat­te irgend­wie nicht begrif­fen, daß die Enco­der bei Debi­an im ganz nor­ma­len Repo­si­to­ry lie­gen und war also der Mei­nung, ich müs­se das selbst über­set­zen. Das ist ein ziem­lich dickes Brett, was man da boh­ren muß, zum Bei­spiel sind man­che Biblio­the­ken in golang geschrie­ben, so daß man noch ein go nach­in­stal­lie­ren muß. Ich fing also an, und natür­lich wur­den erst­mal ton­nen­wei­se Abhän­gig­kei­ten nach­in­stal­liert, bevor es über­haupt ans Bau­en ging. Am Ende hat­te es funk­tio­niert — und ich stell­te fest, daß das völ­lig umsonst war: Debi­ans ffmpeg lie­fert alles mit, was ich brau­che. Lehrgeld.

Der Rech­ner hat eine rela­tiv klei­ne Root-Par­ti­ti­on, und der gro­ße Rest wird für ZFS ver­wen­det. Alle Diens­te, die ins Inter­net expo­niert sind, lau­fen dort. Also jeden­falls / war arg voll, aber ich wuß­te nicht mehr, was ich alles sinn­lo­ser­wei­se nach­in­stal­liert hat­te. Da kam mir eine Idee: Ein­fach alle dev-Pake­te löschen und hin­ter­her noch ein autore­mo­ve, damit auch die Abhän­gig­kei­ten gelöscht wer­den. Hat gut funk­tio­niert, danach war wie­der eini­ger Platz frei. Das war vor ein paar Tagen.
Heu­te sehe ich mal wie­der ins Zab­bix. Da steht auf ein­mal, daß zfs-zed.service nicht lau­fen wür­de. Also ver­su­che ich ihn zu star­ten, 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 Lizenz­grün­den als dyna­mi­sches Ker­nel­mo­dul rea­li­siert. Und muß mit dkms(8) gebaut wer­den, was diver­se Hea­der erwar­tet, die eben in dev-Pake­ten lie­gen. Die hat­te ich aber gelöscht, und mein tap­fe­res autore­mo­ve hat­te dann das kom­plet­te ZFS weg­ra­siert (aber nicht die Daten). Und solan­ge die Büch­se läuft, macht das auch nichts.
Heu­te dach­te ich dann, ich soll­te nicht län­ger war­ten mit einem Reboot. Code, der nur noch im RAM liegt, nee, muß nicht sein. Also reboot und tja, kein ZFS, kei­ne Dienste.

Die Lösung: Nach­se­hen, ob der Pool noch da ist (zpool import) und dann impor­tie­ren (zpool import <poolname>) Reboot, alles wie­der schön.

Und die Flin­ten nach­la­den nicht ver­ges­sen fürs nächs­te mal!

 

Zabbix ist toll

IT
Comments

Heu­te haben wir des Soh­nes neu­en PC in Betrieb genom­men. Und nun, neben all den Ras­pians, Debi­ans, Ubun­tus, MacOS ist was neu­es dazu gekommen:

[moritz ~]# lsb_release -a
LSB Version:    n/a
Distributor ID: ManjaroLinux
Description:    Manjaro Linux
Release:        20.2
Codename:       Nibia
[moritz ~]#

Span­nend ist das weil lüf­ter­lo­ses x86. Da inter­es­sie­ren mich die Tem­pe­ra­tu­ren schon. Doch wie bekommt man die? Ich ver­wen­de auch im Haus­netz Zab­bix. Tem­pe­ra­tu­ren sind ein Son­der­fall: dafür braucht man Sen­so­ren, und an die muß man ran­kom­men. Man kommt ran:

[moritz ~]# sensors
amdgpu-pci-0400
Adapter: PCI adapter
vddgfx:           N/A
vddnb:            N/A
edge:         +42.0°C  (crit = +80.0°C, hyst =  +0.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
Vcore:         1.02 V
Vsoc:        731.00 mV
Tctl:         +42.8°C
Tdie:         +42.8°C
Icore:        26.00 A
Isoc:          1.50 A

[moritz ~]#

Damit kann aber weder SNMP¹ noch der Zab­bix-Agent etwas (direkt) anfan­gen. Aber über Umwege:

[moritz ~]# grep ^UserPa /etc/zabbix/zabbix_agentd.conf
UserParameter=UserParameter-TempGPU,sensors | awk '/^edge/ {print $2}' | sed -e 's/+//' -e 's/°C//'
UserParameter=UserParameter-TempCPU,sensors | awk '/^Tdie/ {print $2}' | sed -e 's/+//' -e 's/°C//'
[moritz ~]#

Und schon gibts Gra­phen, Trig­ger, Alarme…

#zab­bix

¹ Man kann mit net-snmp sei­ne eige­nen OIDs defi­nie­ren, die ihre Daten aus einem Shell­skript oder sonst­wo­her holen