Monitoraggio della qualità dell'aria con Checkmk

In qualità di esperti di monitoraggio, ci piace tenere sotto controllo ciò che ci riguarda da vicino. Già dalla conferenza dell’anno scorso sapevamo che la sala conferenze principale aveva bisogno di un sistema di climatizzazione e ventilazione adeguato, e sapevamo anche di poter fare la nostra parte. Scoprite qui come siamo riusciti a non farvi addormentare (oltre ai meriti dei grandi relatori e delle intuizioni affascinanti).

Dal 2022 abbiamo una collaborazione con Watterott Electronic. È iniziata con una pull request per il "Watterott CO2 Ampel", una scheda per sensori di CO2 con funzionalità WiFi. Sebbene la richiesta di pull fosse inizialmente intesa solo a dimostrare che un agente Checkmk può essere implementato su dispositivi estremamente limitati in termini di memoria (in questo caso ARM M0+, programmato con Arduino), l'agente Checkmk è ora parte del firmware standard che viene preinstallato sulle schede dei sensori. Per quanto riguarda questa partnership tecnologica, abbiamo deciso di ordinare un gruppo di schede sensore per testare alcune nuove idee per l'agente minimo e, naturalmente, per monitorare correttamente la qualità dell'aria interna (CO2 e temperatura) durante la conferenza. Un altro aspetto è stato quello di dimostrare le capacità del dashboarding rivisto e dei dashboard pacchettizzabili.

A differenza dei sensori più economici, le schede Watterott utilizzano sensori NDIR (ottici) molto precisi e quindi adatti a soluzioni professionali. Le schede più economiche utilizzano in genere sensori a piastra che rilevano un'ampia gamma di componenti organici volatili provenienti da sudore, respiro e digestione (TVOC), "Total Volatile Organic Components") e stimano la CO2 (eCO2) in base alle letture. I valori stimati possono essere molto lontani in alcune situazioni, per questo quando si cercano sensori di CO2 si opta sempre per i sensori ottici più precisi.

Le schede di Watterott possono essere utilizzate in modo autonomo con indicatori colorati simili a semafori utilizzando quattro LED RGB e un cicalino aggiuntivo. Inoltre, forniscono i dati del sensore tramite un'interfaccia seriale USB. Naturalmente la caratteristica migliore è che, una volta aggiunte a una rete WiFi, forniscono l'output dell'agente Checkmk come endpoint API REST, il che le rende probabilmente le schede sensore più facili da usare con Checkmk. Per includere le schede sensori di CO2 nel monitoraggio, è sufficiente passare da un normale agente sulla porta 6556 a un programma datasource che chiama l'endpoint API REST tramite l'indirizzo IPv4:

curl http://$_HOSTADDRESS_4/cmk-agent

Poiché è incluso un check locale della CO2, le schede con sensori forniscono immediatamente un servizio utile. Oltre ai livelli di CO2 e alla temperatura, queste schede includono anche un sensore di umidità e di pressione barometrica, utilizzando un plug-in disponibile nel nostro Exchange. Lo scopo principale di questi sensori è quello di regolare le letture di CO2, ma possono anche far divertire un po'. Ne parliamo più avanti.

Paulaner am Nockherberg è un luogo ampio ma sorvegliabile. Poiché il WiFi fornito dall'host non consentiva la comunicazione tra le stazioni (un'impostazione predefinita ragionevole), abbiamo preparato un punto di accesso e un vecchio "nettop" per fungere sia da server Checkmk che da display della dashboard. Nonostante fosse una configurazione utilizzabile nell'ambiente di test, la debole antenna WiFi del nettop e lo scarso raffreddamento del processore a temperature fino a 32°C hanno reso il lavoro difficile nell'ambiente reale. Così, verso mezzogiorno del 20 (primo giorno di conferenza) siamo passati a un notebook molto più capace. Questo passaggio è stato facile grazie a omd backup e omd restore.

Abbiamo utilizzato un singolo punto di accesso WiFi OpenWRT doppio per coprire l'intera location. In totale, sono state utilizzate cinque schede sensore: tre WiFi nella sala conferenze principale, una USB presso il server Checkmk e un altro sensore WiFi nel foyer. Abbiamo cercato di posizionare i sensori il più lontano possibile l'uno dall'altro. Il sistema ha funzionato abbastanza bene, anche se l'elevato numero di stazioni attive a 2,4 GHz ha comportato latenze elevate, perdita di pacchetti e salti di canale, con la conseguenza di perdere occasionalmente i dati di monitoraggio. Tuttavia, data la ridondanza dei sensori e l'inerzia del ricambio d'aria, le lacune nelle letture dei sensori sono state considerate accettabili se si mantenevano al di sotto dei 10 minuti.

La prima conclusione che si può trarre da questa esperienza pratica è che in ambienti con un elevato rumore radio nella banda dei 2,4 GHz, o in generale in siti di grandi dimensioni, è consigliabile utilizzare la versione con un modulo trasmettitore LoRa aggiuntivo. Purtroppo ad oggi non esiste un'integrazione software per LoRa, quindi chiedete a Watterott un preventivo se siete interessati a un'integrazione completa.

L'immagine in alto mostra la nostra configurazione al tavolo del bistrot nel foyer. Lo schermo mostra la nostra prima dashboard con grafici di quattro ore. Quando sono stati disponibili dati sufficienti, siamo passati a 25 ore. La finestra del terminale è stata utilizzata per mostrare l'output dell'agente Arduino minimo.

Durante la conferenza abbiamo creato e regolato la dashboard su una macchina separata e li abbiamo copiati solo nell'ambiente di produzione. Questo è possibile grazie alla nuova funzione delle dashboard personalizzabili, disponibile dalla versione 2.2.0. In pratica, a causa dei diversi formati delle schermate tra il notebook di sviluppo e la schermata di monitoraggio, sono stati necessari piccoli aggiustamenti. Ma questo ha causato molta meno confusione rispetto, ad esempio, al dover gestire più dashboard per lo stesso scopo, come accade quando si sviluppa una dashboard sul sito Checkmk di produzione clonando una dashboard presente.

I dati del monitoraggio sono stati inizialmente "poco impressionanti", nel senso migliore del termine: La CO2 all'inizio non ha superato gli 800 ppm, il che è ottimo se si considera l'ampia location e le numerose letture di 1200 ppm registrate durante la conferenza dello scorso anno. Inoltre, la differenza di temperatura tra l'area del palco, dove era disponibile la maggior parte dell'aria condizionata, e il fondo della sala era significativa: Le temperature minime sul palco erano di circa 24°C e le temperature massime sul retro erano di circa 33°C, con una differenza tipica di 2-3°C tra il palco e il retro della sala.

Tutto è andato bene fino al malfunzionamento dell'aria condizionata il secondo giorno. In questo caso l'aumento della CO2 è stato molto più rapido dell'aumento della temperatura. Perlomeno, questo indicatore precoce ha portato a un'individuazione tempestiva del guasto e ci ha permesso di ripararlo durante la pausa pranzo. La schermata successiva mostra la dashboard finale mezz'ora dopo l'ultimo intervento. Il picco di 1400 ppm è chiaramente visibile come il normale funzionamento del pomeriggio.

Naturalmente, abbiamo riscontrato alcune anomalie interessanti che vorremmo condividere con voi. Cosa è successo qui? Cosa può aver causato il picco di calore tra le 7:00 e le 8:30?

Abbiamo avuto qualche perplessità su questo aspetto e abbiamo ipotizzato che fosse in qualche modo legato alla pulizia. La conferma è arrivata quando hanno finito di pulire la sala con una lavasciuga mobile.

Non abbiamo verificato se la macchina utilizzata fosse a batteria o a propano, ma data la bassa efficienza (e quindi l'elevata emissione di calore) dei motori a propano, abbiamo optato per questa seconda opzione. Il fatto che anche i livelli di CO2 abbiano mostrato il loro primo leggero aumento intorno alle 7:00 del mattino sembra confermarlo.

Un altro risultato interessante è stato il grafico della diminuzione della pressione atmosferica il primo giorno: Tutti i partecipanti sospettavano l'arrivo della pioggia.

Per quanto riguarda la precisione delle nostre misurazioni, non tutto è stato perfetto: un sensore non ha mai rilevato valori inferiori a 530 ppm e un altro è sceso fino a 370 ppm. Entrambe le cose non sono molto plausibili, dal momento che ci si può aspettare circa 420-430 ppm dopo le prime ore del mattino.

In entrambi i casi i sensori avrebbero dovuto essere ricalibrati. In questo caso lo "shock da trasporto" potrebbe essere la causa più probabile. Se, nonostante l'impostazione dell'altitudine corretta, le letture del sensore sono molto lontane da quelle attese, non è colpa né di Watterott né di Sensirion (produttore del sensore). La causa più probabile potrebbe essere una gestione poco attenta del pacco. Non volendo interrompere la serie temporale, questa volta non abbiamo ricalibrato.