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 :-)

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

ISPConfig: snippet per reverse proxy con socket.io

Pubblicato il Pubblicato in #sysadmin

Qualche settimana fa stavo uscendo pazzo per un problema alla UI di una web app dietro reverse proxy, mi sono accorto che era un problema sul reverse proxy ispezionando la pagina con le WebTools di Chrome e notando che alcune richieste non andavano a buon fine: tutte quelle di socket.io.

ISPconfig -> Siti -> [vhost sito] -> Opzioni -> Direttive Apache

ProxyRequests Off
ProxyPreserveHost On
ProxyPass /.well-known/ !
ProxyPass /               http://10.8.10.11/
ProxyPassReverse /  http://10.8.10.11/

ProxyVia on      
RewriteEngine On

RewriteEngine On
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://10.8.10.11:8080/$1 [P,L]

ProxyPass               /socket.io http://10.8.10.11:8080/socket.io
ProxyPassReverse        /socket.io http://10.8.10.11/socket.io

Raccogliere i log da remoto con rsyslog, differenziarli in base all’IP e ruotarli con logrotate

Pubblicato il Pubblicato in #sysadmin

Le indicazioni di questo post sono state testate con delle antenne Ubiquity e sono valide per qualsiasi sistema che utilizzi ancora rsyslog e logrotate e qualsiasi hardware che sia in grado di spedire i propri log in remoto. Lo scenario è quello di un logserver Debian che riceve i syslog di access points e stations e li divide in base all’IP di provenienza.

Per prima cosa bisogna dire ad rsyslog di ascoltare su una porta UDP o TCP per poter ricevere i log, su /etc/rsyslog.conf decommentare le righe inerenti al protocollo che si desidera utilizzare:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Successivamente, sempre su /etc/rsyslog.conf o come snippet in /etc/rsyslog.conf.d/ vanno inserite direttive tipo queste:

if $fromhost-ip startswith '192.168.10.' then /var/log/ubnt-stations.log
& ~
if $fromhost-ip startswith '192.168.2.' then /var/log/ubnt-stations.log
& ~

if $fromhost-ip startswith '192.168.1.' then /var/log/ubnt-APs.log
& ~

Molto utile ed importate è la riga ” & ~ ” posta immediatamente dopo la singola direttiva, vuol dire: “fermati li dove hai loggato e non andare avanti”, per evitare di spammare altri logfile tipo syslog o messages. Un restart di rsyslogd ed andiamo avanti.

Ultimo step è quello di configurare logrotate per ruotare anche questi nuovi logfile ed evitare che /var/log/ si riempia troppo presto. Le politiche più adatte spettano a voi, potete anche riciclare delle impostazioni già esistenti tra /etc/logrotate.conf.d/ o crearne una vostra, a seconda di quanto vi serva tenere i log.

Nel mio caso bastava una settimana ed ho aggiunto quei file di log (anche con wildcard) allo stesso snippet che fa ruotare syslog, ovvero ogni giorno e per una settimana, /etc/logrotate.conf.d/rsyslog:

/var/log/syslog
/var/log/ubnt-*.log
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Moodle, opcache e le pagine bianche

Pubblicato il Pubblicato in #sysadmin

Mi è capitato di installare Moodle su ISPConfig e riscontrare spesso e volentieri delle pagine bianche nell’interfaccia di admin che lo rendevano davvero poco utilizzabile. Dopo un po’ di troubleshooting ed una ricerca sono riuscito a trovare il problema: opcache, parte di Zend. Conosco ancora poco moodle e non so il motivo esatto di questo comportamento nè quanto possa effettivamente giovarne in performances riuscendolo a farlo funzionare correttamente con opcache attivo… resta il fatto che disattivando opcache scompaiono le pagine bianche.

La direttiva per disattivarlo è opcache.enable:

php.ini:

opcache.enable = 0

apache (conf vhost o .htaccess):

php_admin_value opcache.enable Off
php_flag opcache.enable Off