Zen-Funk Panda

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:

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.