Am zis ca am cateva postari cu Zabbix si Telegram. Well, am mintit, postarea o sa fie mai mult despre Telegram, si poate prea putin despre modul cum am integrat Zabbix-ul cu Telegramul. Hai sa-i dam drumul.

Probabil ati citit postarea in care am integrat Zabbix cu Slack, ei bine, cum sunt total fanul conturilor multe si inutile si aplicatiilor instalate pe telefon care nu aduc un plus de valoare, am zis ca e momentul sa renunt la Slack (il foloseam doar pentru notificarile din Zabbix) si sa aduc cumva notificarile intr-o aplicatie ce o folosesc mai des: Telegram.

Am cautat o modalitate sa integrez Zabbix cu Telegram si am gasit si o solutie oficiala. Cum se procedeaza pe scurt? Iti faci un bot, primesti un token, faci un canal nou in care te adaugi pe tine si bot-ul creat, apoi cu putin kung-fu pe care-l gasiti in documentatia oficiala ajungi sa integrezi alertele de Zabbix cu Telegram. Mesajele se primesc in canalul pe care l-ai creat anterior. Simplu, eficient.

Partea misto la TelegramBot e ca de fapt faci un request prin cURL cu ce mesaj vrei tu si asta m-a facut sa ma gandesc la un script semi-misto si putin inutil, dar I did it for fun, deci nu conteaza. Vorbim de script in urmatoarea postare, momentam va las sa macinati informatia asta.

Ah, BTW, merge integrat si Nagios cu Telegram prin aceeasi metoda. Not a fan of Nagios, chiar il urasc din toata inima si din adancul sufletului, dar ma gandesc ca sunt fani Nagios pe aici care se intreaba daca merge o integrare Nagios + Telegram. Raspunsul este: Da, merge.

Ne vedem in postul urmator.

Am lipsit un an si ceva, am fost ocupat cu altele. Am vreo doua postari de scris, nimic deosebit, ceva cu Zabbix, Telegram, Uptime Kuma.

Intre timp puteti sa va uitati la ce am lucrat anul trecut: vechea mea pasiune, fotografia. Imi puteti gasi galeria foto pe Instagram direct sau pe pagina embedded din blog.

In orice caz, sper ca v-ati vaccinat si n-ati murit de la Covid (sigur cei care citesc n-au murit) si sper sa va paca contentul ce urmeaza. (Vorbesc cu voi, cei din robots.txt, ca nu stiu cine ma mai citeste)

Undeva intre “Arata-mi IP-ul!” si “E vineri 13?” gasim incepand de azi un nou link: htop.

Voiam sa fac de mai mult chestia asta (am vazut-o acum cativa ani pe undeva si mi-a placut), dar ori nu am avut timp si cand am avut timp nu am reusit(voiam alta abordare), ori nu mi s-a mai parut interesanta ideea, dar azi am facut-o.

Ce este? Htop “in timp real” (in urma cu cateva secunde, dar heh, who cares). Comanda htop rulata pe server si pusa “imaginea” intr-un html, apoi servit via Apache.

Sursa:

#!/bin/bash
export TERM=xterm-256color
export COLUMNS=200
export LINES=42
echo q | htop | aha --title htop --black --line-fix > /var/www/html/linux365.ro/htop.html

Daca va uitati la cod, vedeti ca e un simplu export intr-un fisier. Un “snapshot” al htop-ului asa cum e cand a fost rulat. Acum vine intrebarea de 1000 de puncte: cum am facut sa se actualizeze in timp real? Raspunsul este: systemd.

cat /etc/systemd/system/htop.service

[Unit]
Description=htop service
After=network.target
StartLimitIntervalSec=0

[Service]
Restart=always
RestartSec=1
ExecStart=/root/bin/htop.sh

[Install]
WantedBy=multi-user.target

Evident, serviciul a trebuit activat la restart si repornit. That’s it.

TODO (si won’t do in acelasi timp): ar trebui sa centrez output-ul.

Titlu de senzatie si semi-clickbait.

Trecand peste titlul de tabloid, am stocat 3TB in 120GB cu btrfs, snapshots si compresie.

Ce vedeti mai sus este serverul meu de backup. Un VM care trage in fiecare seara schimbarile de pe serverele la care fac backup. Am backup-uri zilnice de la inceputul anului pana in ziua de azi. De pe 29.12.2019 pana pe 3.10.2020. 10 luni de backup in 120GB (~90GB, dar 120GB este dimensiunea HDD-ului pe care se fac backup-urile).

Scriptul de backup il gasiti aici.

Cum e posibila chestia asta? Snapshots si compresie. Compsize arata practic cat spatiu ar trebui sa am pe un sistem de fisiere “normal” daca as avea aceeasi politica de backup.

Compresia banuiesc ca stiti cum functioneaza. Pe filesystem este transparenta si e exact ca si cum ai arhiva cu 7zip un fisier, doar ca asta se intampla automat pe btrfs cand un fisier se creeaza pe disk. (e de discutat si pe tema asta, dar just go with it. Pe scurt: unele fisiere se comprima mai bine decat altele)

Snapshot-urile sunt insa ceva mai interesant. Sa zicem ca ai fisierul A de 1MB si vrei sa-i faci snapshot din 10 in 10 minute, timp de o ora. La finalul orei o sa ai 6 snapshot-uri ale fisierului A. Teoretic, ai fisierul A de 6 ori, practic ai 5 referinte catre fisierul A original, de 1MB. Compsize calculeaza chestia asta insa ca avand fisierul A de 6 ori (in coloana Referenced), adica un total de 6MB, nu de 1MB. Fake? Nu chiar. Clickbait worthy? Poate. Daca tu la minutul 35 modifici fisierul A si ii cresti dimensiunea la 2MB, o sa ai primele snapshots de 1MB, apoi urmatoarele de 2MB, in total insumand 3MB. Compsize calculeaza asta in coloana de referenced ca 1MB+1MB+1MB+2MB+2MB+2MB = 9MB.

That’s it. Asta e marea smecherie. Asa bagi 3TB in 120GB.

PS: cele mai mari snapshot-uri sunt cele ale bazelor de date. Am ales optiunea sa fac compresie la nivel de filesystem si nu in timpul backup-ului. Scriptul de backup pentru mysql este o combinatie intre ce am avut eu nevoie si alte exemple gasite pe stackoverflow/github, dar pe scurt asta e linia care face tot: $MYSQLDUMP -h $MyHOST -u $MyUSER -p$MyPASS $db > $FILE

Nu recomand daca vreti ceva mai serios. Scriptul de backup mysql este locking. La baze de date mai mari (sunt multumit de cat de repede se face backup un DB de 2GB) e naspa ca iti pune productia pe jos. Se poate tuna si se mai pot adauga optiuni la backup, dar pentru ce am eu nevoie e destul.