Speaker
Description
Il monitoraggio di un datacenter di calcolo scientifico richiede due cose distinte: raccogliere metriche in modo affidabile, e sapere con precisione cosa c'è nell'infrastruttura. Il primo è ben coperto da Prometheus e Grafana con protocolli standard — SNMP, IPMI, Redfish. Il secondo — mantenere un inventario coerente quando le fonti di informazione sull'infrastruttura possono divergere silenziosamente — è il problema che questo sistema affronta.
La scelta architetturale centrale è tenere la logica vicina ai dati: un database PostgreSQL come source of truth, dove vivono le regole operative — stato delle macchine, eligibilità al monitoraggio, integrità dell'inventario. I target Prometheus sono generati dinamicamente da query sul database, non gestiti a mano. Ogni componente del sistema — schema, logica di probe, regole di riconciliazione, CLI — è ispezionabile e modificabile senza toccare una piattaforma esterna. Questo ha un costo: non c'è una GUI dedicata, e la curva di apprendimento per un nuovo operatore non è banale. Ma significa anche che il sistema si adatta al datacenter, non il contrario.
L'interfaccia verso gli operatori è un pacchetto Python con strumenti CLI per la gestione dell'inventario, il monitoraggio attivo, la verifica dei certificati X.509 e la sanitizzazione dei dati — evoluto da una prima generazione di script Bash.
Due componenti di osservazione chiudono il ciclo. Il primo raccoglie e storicizza osservazioni ARP, segnala conflitti e discrepanze, e supporta l'onboarding di nuovi nodi. Il secondo confronta sistematicamente tre fonti — Netdisco, scan ARP e database interno — per rilevare anomalie e proporre aggiornamenti alla topologia dichiarata, con scoring sull'affidabilità delle osservazioni e conferma esplicita dell'operatore. La topologia L2 è costruita combinando dati LLDP da Netdisco con una discovery diretta degli switch via SNMP, correlata con l'inventario e visualizzata come mappa HTML interattiva.
L'architettura aperta rende il sistema adattabile: chi dispone già di un CMDB esterno può usarlo come sorgente dell'inventario, alimentando il database e mantenendo l'intera pipeline funzionante. Non è un'integrazione pronta — richiede un adattatore specifico per l'infrastruttura — ma l'interfaccia è semplice e ben definita.
Gli sviluppi in corso riguardano due direzioni principali: rendere l'audit multidimensionale, sostituendo un insieme fisso di probe per macchina con un modello configurabile e componibile; e applicare uno scoring di stabilità anche alle osservazioni ARP, analogamente a quanto già fatto per la topologia L2. Restano aperte diverse strade e idee ancora da implementare con vario grado di dettaglio, per rendere il sistema più ergonomico.