Da dove si parte

Chi ha mai provato a montare un sistema di monitoraggio serio in una PMI sa com'è andata: tre giorni a configurare, un'altra settimana a capire perché gli alert non arrivavano, e alla fine il sistema è rimasto acceso ma nessuno lo guardava.

Non è un problema di volontà. È un problema di rapporto sforzo/risultato. Se il monitoraggio richiede più tempo del problema che dovrebbe prevenire, non lo si usa.

La domanda giusta non è "qual è il tool migliore?" ma: qual è il minimo che serve per non scoprire i problemi dopo che li ha scoperti il cliente?

Tre cose:

1. Qualcosa che avvisa quando un server, un servizio o uno switch ha un problema
2. Un posto dove il problema ha uno stato (aperto, in corso, risolto, chiuso) e un timer
3. I dati, dopo, per rispondere a "cosa è successo?"

Niente altro.

L'architettura in 30 secondi

Il monitoraggio: un container, zero config

Il tool che incrocia tutti questi vincoli è Netdata. Non lo si dice per fargli pubblicità: lo si dice perché è l'unico che si installa in un comando e funziona senza dover decidere "a quale soglia mando l'allarme".

Cosa fa in pratica:

• Lo si lancia su un server con docker compose up -d. Dopo 30 secondi il dashboard è su http://ip:19999
• Auto-rileva CPU, RAM, disco, rete, i servizi che ci girano sopra (Nginx, PostgreSQL, Redis, systemd, Docker…), e i container
• Ha 400+ alert già configurati. CPU alta, disco pieno, servizio down, interfaccia di rete spenta. Li ha già. Non li si configura
• Avvisa su Slack, Telegram o email. Lo si configura una volta, poi non ci si pensa più

Cosa non fa (e non lo si nasconde):

• Non è un NMS in senso stretto. Non fa backup delle configurazioni di rete, non le spinge, non ha 500 profili vendor
• Non riceve syslog nativamente
• La vista aggregata (più server in una schermata) ha un limite di 5 nodi

Per una PMI con 5-15 server e una decina di dispositivi di rete, copre il 90% di quello che serve.

"Ma sono troppe metriche"

È la prima obiezione che viene. La pagina iniziale sembra un pannello di controllo di una centrale nucleare.

In pratica: la home mostra 4-5 gauge e gli alert attivi. Il resto è nel menu laterale, che non si apre da solo. Se anche così troppi, si disabilitano intere sezioni con una riga in un file di config. Un server web alla fine mostra 8 sezioni, non 30.

La rete: SNMP

Netdata fa da poller SNMP. Gli si dà una subnet e le credenziali, lui trova i dispositivi, li classifica per vendor (Cisco, Aruba, FortiGate, Ubiquiti, MikroTik…) e inizia a pollare. Riceve anche le segnalazioni spontanee dei dispositivi (es. "questa interfaccia è caduta") in tempo reale, senza doverle andare a chiedere.

Cosa non fa:

• Non ha 500 profili vendor come LibreNMS. Ne ha 100+. Per i dispositivi mainstream basta. Per uno switch industriale di un vendor di nicchia, no
• Non salva le configurazioni dei dispositivi
• Non applica modifiche a più dispositivi contemporaneamente

Come si risolve:

• Dispositivi di nicchia (2-3 che non sono nella lista): si scrive un profilo custom di 10 righe, oppure si usa SNMP generico che dice almeno se il dispositivo è up e quanto traffico fa
• Backup delle configurazioni: un secondo container (Oxidized) va a prendere la config di ogni dispositivo ogni ora via SSH e la salva su disco con storico locale. Se qualcosa cambia rispetto al backup precedente, il confronto è immediato. Tutto su disco, nessun servizio esterno
• Applicare una modifica a più dispositivi: uno script che legge il file di config aggiornato e lo spinge via SSH su ogni dispositivo della lista. Dopo, Oxidized al giro successivo rilegge la config dal dispositivo e conferma che è stata applicata correttamente. Se i dispositivi crescono oltre i 30, si passa a un tool di automazione (Ansible), ma per una PMI non serve

Syslog

Netdata non riceve syslog dei dispositivi di rete. Se servono i log del firewall nella stessa timeline delle metriche, si mette un container intermedio (OpenTelemetry Collector, 50 MB di RAM, 10 righe di config) che riceve il syslog e lo passa a Netdata.

Se non servono i log di rete, non lo si mette. Netdata legge già i log dei server nativamente.

Spazio su disco

Il database interno tiene i dati a tre risoluzioni:

Totale: ~4 GB per server. Su un SSD da 256 GB non si sente.

Se si vuole più storia, i numeri sono lineari: un server medio fa ~25 GB/anno di dati per-secondo. Per 5 server e 1 anno di storia, parliamo di 100-150 GB extra. Un SSD NVMe da 500 GB costa 50 €. Non è un problema.

L'help desk: Faveo Community

Perché serve

Il monitoraggio dice cosa è successo. Ma poi? Chi se ne occupa? In quanto tempo lo risolve? E se tra un mese qualcuno chiede "dove siamo arrivati?", la risposta non può essere "credo che Marco ci abbia dato un'occhiata". Serve un posto dove il problema ha uno stato, un nome, e un'ora.

Cos'è Faveo Community

Faveo è un help desk open source (licenza OSL 3.0). Non è un ITSM, non è un ServiceNow, non ha 40 schermate di configurazione. Si apre e si vede il ticket.

La versione Community è gratuita e senza limiti di utenti né di ticket.

La versione Community include:

• Ticket con 4 stati (Aperto → In corso → Risolto → Chiuso)
• Timer SLA per priorità (es. critica: 15 min, bassa: 8 ore)
• Notifica a scadenza SLA
• Agenti e ticket illimitati
• Knowledge base (FAQ)
• Portal self-service per il cliente
• Routing automatico (regole di assegnazione)
• API REST e webhook
• Email piping (rispondi all'email → aggiorna il ticket)
• Priorità e categorie

Cosa non c'è:

• Salto automatico di livello (se nessuno risponde, avvisa il responsabile) → si implementa con webhook + script di 10 righe
• AI / chatbot → solo versioni a pagamento

Per una PMI con 2-3 tecnici, SLA di base (timer + notifica a scadenza) è tutto quello che serve. Le escalation a catena servono quando si hanno 20 agenti e 5 turni

Cosa si vede nel ticket

Quando si apre un ticket in Faveo si vede:

• Soggetto (es. "CPU server-web01 al 95%")
• Stato (il colore cambia: rosso, arancio, verde, grigio)
• Priorità (bassa, media, alta, critica)
• Assegnato a (nome del tecnico)
• Timer SLA (quanti minuti mancano alla scadenza)
• Timeline (ogni commento, ogni cambio stato, con data e ora)

Niente "stato: In attesa di conferma da parte del fornitore" da 3 settimane. Se è aperto, è aperto. Se è risolto, è risolto. Lo si vede dal colore.

Installazione

Faveo si installa con uno script ufficiale che genera il compose e configura tutto:

git clone https://github.com/ladybirdweb/faveo-helpdesk-docker-v2.git
cd faveo-helpdesk-docker-v2
chmod +x faveo-community-run.sh

./faveo-community-run.sh -domainname helpdesk.azienda.it \
  -email admin@azienda.it \
  -ssl B

Lo script crea 4 container:

Primo avvio: si configura il dominio, l'SMTP, si crea l'utente admin. Dieci minuti.

Il ponte: allarme → ticket

Il collegamento tra i due è un webhook. Netdata invia un JSON, uno script di 5 righe lo trasforma in una chiamata API a Faveo, e il ticket nasce da solo.

Se non si vuole il ticket automatico (e all'inizio non serve), si punta il webhook su Slack e si crea il ticket a mano. Per 1-2 tecnici il tempo è trascurabile. Il ponte automatico diventa utile quando gli allarmi superano i 10 al giorno.

Cosa non si risolve (e perché va bene)

Nessuno di questi limiti blocca l'uso quotidiano. Se un giorno si cresce, si aggiunge un componente. Non si rifà tutto.

Quanto costa

Per confronto: un tool commerciale di monitoraggio + help desk per 10 nodi parte da 3.000 €/anno, con contratto di 3 anni.

Le cose che contano

1. Il monitoraggio che non si usa non esiste. Se richiede 2 ore al giorno per essere "gestito", non si gestisce. Deve essere qualcosa che si accende e si dimentica
2. 400 alert preconfigurati battono 10 alert perfetti. Meglio un falso positivo in più che non avere l'allarme per un problema che non si era pensato
3. Il ticket a 4 stati è più utile di quello a 12. Se lo stato non è ovvio a colpo d'occhio, nessuno lo aggiorna
4. Non serve il tool perfetto. Serve il tool che non fa pensare. Netdata non è LibreNMS. Faveo non è ServiceNow. E per quello che serve a una PMI, è la cosa giusta

Il setup, in sintesi

• 1 container Netdata per ogni server da monitorare
• 4 container Faveo (una volta, non per server)
• 1 container Oxidized (opzionale, per backup config rete)
• 1 container OTel Collector (opzionale, per syslog rete)

Tutto su un server con 4 GB di RAM. Tutto in docker-compose.yml. Tutto in Git, così se il tecnico se ne va, il nuovo apre 3 file e sa cosa c'è.

Le garanzie: quanto sono stabili questi tool

La domanda legittima è: "Se tra due anni uno di questi progetti viene abbandonato, cosa succede?"

I numeri:

Netdata — nato nel 2015, 11 anni di vita. Rilasci stabili ogni 6 settimane (ultimo: settembre 2026). Ha una società dietro (Netdata, Inc.) che lo mantiene e lo vende in versione cloud, ma la versione open source (GPLv3+) resta gratuita e illimitata per sempre. La licenza lo garantisce: anche se la società chiude, il codice è libero e la community può portarlo avanti.

Faveo — nato nel 2017, 9 anni di vita. Rilasci ogni 2-3 mesi (ultimo: agosto 2026). Ha una roadmap pubblica con feature pianificate fino a fine 2026. La versione Community (OSL 3.0) è gratuita senza limiti. Stesso principio: anche se il vendor sparisce, il codice resta.

Oxidized — nato nel 2013, 13 anni di vita. Rilasci 3-4 volte l'anno (ultimo: maggio 2026). È un progetto community-driven senza società dietro, ma è così piccolo e stabile (fa una cosa sola: prendere le config e salvarle) che il rischio di abbandono è minimo. Anche se un giorno smettesse di ricevere update, continuerebbe a funzionare: non ha dipendenze complesse, non parla con servizi esterni, fa solo SSH e salva file.

Cosa succede se un tool viene abbandonato:

In tutti e tre i casi, il resto dello stack non si tocca: il container problematico si rimuove dal docker-compose.yml e si sostituisce. Dieci minuti.

Un'ultima precauzione: ogni container si usa a una versione fissa, non "l'ultima disponibile". Si aggiorna una volta al mese, si verifica che tutto funzioni, e si passa. Se qualcosa non va, si torna alla versione precedente in pochi minuti. Non si è mai esposti a un aggiornamento che rompe tutto senza che nessuno se ne accorga.

Conclusioni

Il monitoraggio non è un lusso. È la differenza tra "il cliente ci chiama alle 9 e noi scopriamo che il server era down da 3 ore" e "alle 3:07 riceviamo un messaggio su Slack, alle 3:12 il problema è risolto, il cliente non sa nulla".

Per una PMI, il costo di non avere un sistema di monitoraggio non è il software. È l'ora di fermo, la spiegazione al cliente, e il fatto che non si può dire quando è successo, quanto è durato, e chi l'ha risolto.

Lo stack descritto in questo articolo risolve esattamente questo:

• Un container che monitora tutto e avvisa da solo
• Quattro container che gestiscono il ticket con uno stato chiaro e un timer
• Un container (opzionale) che salva le configurazioni di rete con storico
• Zero euro di licenze, zero abbonamenti, zero vendor
• Un pomeriggio di setup, dieci minuti al mese di manutenzione

Non è la soluzione più completa che esista. Non è quella che userebbe un'azienda con 500 server e 20 tecnici. È la soluzione più piccola che risolve il problema: smettere di scoprire i problemi dopo che li ha scoperti il cliente.

E per questo basta.