Da Zabbix 3.2 a 5.0, prima e dopo PostgreSQL/TimescaleDB passando per MySQL

Pubblicato il Pubblicato in #floss-stuff, #sysadmin

In questo post voglio raccontarvi la mia personale esperienza con Zabbix negli ultimi 5 anni circa, ovvero da quando lavoro al NOC di un provider locale in costante crescita. Conoscevo Zabbix da tempo ma lo avevo usato in ambiti dove non c’erano da monitorare più di 30 dispositivi e quindi le risorse hardware necessarie non erano particolareggiate, una VM Debian con MySQL su 4GB di RAM, 64GB di disco ed un paio di vCPU mi era sempre bastata, ed infatti per i primi due anni queste stesse risorse sono bastate tranquillamente a far girare Zabbix 3.2 dentro una VM e monitorarci i primi pezzi di infrastruttura ed i primi clienti.

Poi MySQL ha iniziato ad ingolfarsi ed ho deciso di lasciare zabbix-server sulla vm e spostare MySQL bare metal su un HP Microserver Gen8 con 16GB di RAM, Debian/ZFS con due dischi meccanici RAID 1 più due dischi SSD per cache e ZIL. Si è ripreso alla grande ed è andato avanti per altri due anni, fino a quando ha raggiunto il limite. Con 1200+ dispositivi SNMP da monitorare e 600+ VPS (Valori Per Secondo di Zabbix) il DB era arrivato a 120GB e le slow query erano troppe, rallentavano l’operatività del server e generavano troppi falsi positivi.

Ho provato allora il partitioning MySQL che ha funzionato facendo tirare la baracca ancora qualche mese per poi ricominciare con le slow query, ingolfamenti e falsi positivi. Iniziavo a valutare alternative perché stare col dubbio che si tratta di un falso positivo che rientrerà in non-sai-quanti-minuti appena completate le slow query o stare col dubbio che un cliente, magari pure importante, o un apparato è realmente down è davvero snervante. Ho dunque iniziato a documentarmi sulle nuove versioni di Zabbix e le nuove funzionalità, ho anche provato a tenere la configurazione ed svuotare lo storico convinto che fossero eventuali record orfani a fare ingolfare 4 anni di MySQL… durava una settimana poi si ingolfava di nuovo, avevo capito che ero incappato in una legge di Murphy:

Una volta aperta una scatola di vermi, l’unico modo di rimetterli in scatola è usarne una più grande.

Prima legge di Zymurgy sulla dinamica dei sistemi in evoluzione

Non avendo mai prima scalato Zabbix su così tanti dispositivi non avevo abbastanza esperienza, ho alzato bandierina bianca e chiesto aiuto a dei consulenti certificati che mi hanno rassicurato che con TimescaleDB non avrei avuto problemi e sarebbe bastata anche una sola VM un po’ più grossa delle precedenti e nemmeno un proxy! Non ci credevo ma non avevo altro da fare che fidarmi e farmi seguire nell’aggiornamento a Zabbix 5.0.

Abbiamo dunque messo su Zabbix 5.0 su una VM con 16GB di RAM, 4 vCPU e 512GB di disco, importato la configurazione di host, gruppi e templates e fatto macinare il tutto… solo che per una svista durante la procedura non abbiamo attivato l’estensione TimescaleDB di PostgreSQL. Questo è stato un errore che mi è servito parecchio a rendermi conto per la prima volta di come funziona e macina dati PostgreSQL… perchè praticamente con questo errore stavo usando Zabbix con un DB PostgreSQL pulito senza alcuna estensione o TimescaleDB, solo che ancora non lo sapevo!

La prima cosa di cui ti accorgi, più che le performances è la stabilità nonostante i rallentamenti notturni dovuti ai backup: nettamente superiori a MySQL, pur senza partitioning (che TimescaleDB poi di fatto implementa ma un PostgreSQL pulito no!) il sistema non si è mai ingolfato ne rallentato nonostante il DB fosse arrivato a quasi 300GB!! Allucinante per me che avevo visto MySQL ingolfarsi su un DB di 120GB su un server bare metal! PostgreSQL su una VM invece continuava tranquillo ad ingurgitare dati con ottime performance e nel frattempo gestiva le query in lettura del frontend come se gli stessero facendo il solletico! Credevo che semplicemente TimescaleDB fosse questo: una figata, fin quando non si è riempito il disco e si è piantato tutto. Solo pochi giorni dopo ho capito che PostgreSQL/TimescaleDB era una iper-figata.

Da un lato ero gasato che le performance erano nettamente superiori a prima nonostante un DB così grosso, dall’altro ero deluso perché ero reincappato nella stessa legge di Murphy e pensavo mi servisse hardware dedicato più costoso. Il disco pieno rendeva la VM inutilizzabile, dunque ho ripristinato il backup del giorno prima con ancora qualche GB libero e mi ci sono fatto un giro per revisionare la situazione… è stato li che mi sono accorto che l’estensione TimescaleDB non era attiva, ci era scappata. Dunque l’ho attivata e ricaricato lo schema del DB, è partita una stored procedure che ha macinato più di 24 ore e poi il miracolo sintetizzato da questo grafico: la prima metà è il DB PostgreSQL di Zabbix 5.0 senza TimescaleDB… la seconda metà è lo stesso DB PostgreSQL con TimescaleDB pienamente operativo: ditemi voi se non è ALLUCINANTE.

Ubiquiti AirControl su Fedora 33

Pubblicato il Pubblicato in #sysadmin

Non essendo uno sviluppatore Java ed avendo a che fare -fortunatamente- con pochissima roba in Java ci sono stato un po’ a capire perché lanciando AirControl ottenevo solo una finestra nera. Qualche anno fa, sempre con AirControl, avevo avuto bisogno di esportare una variabile di ambiente (che ho perso e non ricordo più) per farlo partire… era legata all’accelerazione grafica, tanto che -visto che AirControl non è più sviluppato in favore di UNMS- mi ero convinto non ci fosse nulla da fare e che il problema fosse legato a Wayland o X.Org. Conoscendo davvero poco le differenze tra versioni di JRE/JDK che pensavo essere retrocompatibili mi ero convinto definitivamente che quindi la finestra nera era per forza qualcosa di legato al rendering/compositing della mia scheda video.

Minchiate: è una questione di versione di Java. Non chiedetemi perché, non lo voglio nemmeno sapere! Di Java mi serve solo AirControl e così mi sta benone.

Fedora 33 esce con java-11-openjdk di default che è una dipendenza di libreoffice. AirControl ha invece bisogno che java-1.8.0-openjdk sia il JRE di default per girare correttamente. Quindi:

$ sudo dnf install java-1.8.0-openjdk icedtea-web

[...]

$ sudo alternatives --config java

Ci sono 2 programmi che forniscono 'java'.

  Selezione    Comando
-----------------------------------------------
 + 1           java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.272.b10-0.fc33.x86_64/jre/bin/java)
*  2           java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.9.11-0.fc33.x86_64/bin/java)

Invio per mantenere l'attuale selezione[+], o inserire il numero di selezione: 1

PS: proprio oggi leggevo che Python sta scalando Java nella classifica dei linguaggi più utilizzati, ci sarà un motivo :-)

Bye bye freeDB CDDB

Pubblicato il Pubblicato in #blog, #musica

Oggi mi era partita un po’ la vena rock e mi andava di mettere un po’ di Rage Against The Machine mentre lavoravo, quindi mi loggo in remoto al mio pc con scheda audio esterna che fa da mediaserver, apro Musique, navigo la cartella dei rage e faccio partire la playlist e mi accorgo che un album era senza tag ID3v2: sacrilegio, per un musicofilo come é impensabile avere mp3 non taggati e la cosa mi ha turbato tantissimo, soprattutto perché credevo che la mia discoteca fosse scrupolosamente taggata ed invece quell’album mi era scappato.

Poco male, come dicevo nel mio ultimo post mi sto ritrovando ad usare Windows 7 per poter avere operativo Cubase, siccome sono un musicofilo la prima cosa che mi sono assicurato di poter avere su cygwin+Xming prima di ipcalc é stata easytag, applicazione che uso da una vita e con cui ho potuto taggare tutta la mia musica e poter utilizzare qualsiasi player senza trovarmi qualche Artista Sconosciuto tra i coglioni. Lancio easytag, navigo la cartella dei rage senza titoli, selezioni tutto e li mando in pasto a CDDB: «impossibile contattare il server». Cambio le impostazioni sul gateway musicbrainz, «impossibile contattare il server». Azz, sará qualche impostazione di rete di cygwin, eppure il resto su cygwin naviga. Provo a fare una ricerca di server alternativi CDDB e mi ritrovo questo annuncio:

freedb.org and its services was scheduled to be shut down on March 31 of 2020. As of May 28, 2020 the site was still operational. On the 13th of June 2020 it was observed that the URL used for lookups, freedb.freedb.org, no longer resolved to a host name and as a result the service no longer appears to operate.

Manco un mese fa!! Manco il tempo!! Magix, nota software house che con il loro software ha permesso negli utlimi quindici anni ad un sacco di DJ spacciarsi per musicisti facendo musica di merda con quattro click ha acquisito (e spento) freeDB.

rsync su cygwin tra NTFS ed exFAT

Pubblicato il Pubblicato in #sysadmin

Per una serie di questioni prolisse da raccontare mi sto ritrovando ad usare Windows 7 e dover fare dei backup di dati con rsync su cygwin verso un hard disk esterno USB formattato in NTFS.

Il problema è proprio questo, NTFS. Credevo fosse il filesystem più compatibile tra dispositivi diversi, invece quest’ultimo è exFAT perchè non ha tutta la parte dei permessi ed ownership dei file che tra sistemi diversi diventa un bagno di sangue.

Certo, da un punto di vista Enterprise questi medatati sono sicuramente utili ed importanti, ma per una singola persona no: usate exFAT che la tab sicurezza-col-tasto-destro-proprietà nemmeno ce l’ha!

$ rsync -avr /cydrive/$ORIGINE/ /cygdrive/$DESTINAZIONE/ --progress --delete --size-only --no-perms -O