htop and how I did it

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.

BTRFS. (sau cum am stocat 3TB in 120GB)

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.

Ce rulez in Docker

Pe scurt:

Pe lung:

  • nut-influxdb-exporter – exporter de metrici pentru NUT. Metricile se citesc dintr-un server de NUT si se trimit in InfluxDB, apoi din InfluxDB le vad in Grafana cu dashboard-ul asta.
  • kanboard – kanban board. Eu l-am setat ca un TODO board cu trei coloane: to do, in progress si done. Imbatranesc si ma lasa memoria.
  • observium_db – mariadb pentru observium (vezi mai jos)
  • grafana – Grafana. Metrici. Grafice. Chestii. O sa fac o gluma si o sa zic “lasati Grafana si invatati Cacti!” (cine stie cunoaste)
  • prometheus – time series database. Data source pentru Grafana. (vezi mai jos)
  • influxdb – time series database. Data source pentru Grafana. Colectez datele cu telegraf si le salvez in influx.
  • chronograf – dashboard pentru Influx dar poate fi folosit ca un client de Influx de unde poti gestiona datele. (eu pentru asta l-am instalat)
  • observium_app – Observium. Se conecteaza la observium_db si salveaza datele acolo. Grafice. Metrici. Niciodata nu sunt destule. Daca Grafana este utila si personalizabila dupa bunul plac, Observium e mai mult indreptat catre retelari.
  • portainer_agent – agentul de Portainer.io, pentru ca lene si pentru ca imi place docker dar nu prea. Nu am chef sa stau sa invat si sa fac retete de docker cand pot sa dau 3 click-uri si sa am un container.
  • mikrotik-exporter – exporter de metrici pentru device-urile Mikrotik. Datele se scriu in Prometheus si le vad in Grafana cu dashboard-ul asta.
  • pihole-exporter – exporter de metrici pentru PiHole. Datele se scriu in Prometheus si le vad in Grafana cu dashboard-ul asta.
  • cerebro – web admin tool pentru Elasticsearch.
  • watchtower – autoupdater pentru imaginile de docker.

Bonus:

  • bitwarden – self hosted password manager, because I don’t trust anybody.
  • jitsi – Jitsi Meet – self hosted chat/video room. Conferinte video open-source, nu trebuie sa te inregistrezi nicaieri, ai camere private, it just works. Asta e remasita din pandemie, cred ca l-am folosit de vreo 3-4 ori si am uitat de el.
  • portainer – masterul pentru portainer.io