Tutte le guide
DevOpsIntermedio

Monitoraggio server e alerting con Slack e n8n

Configura controlli di uptime, monitoraggio HTTP, alert su CPU e RAM con notifiche su Slack e Telegram e regole di escalation

30 marzo 20266 min readIntermedio

Panoramica

Un sistema di monitoraggio efficace è la prima linea di difesa contro i downtime. Con n8n puoi costruire un sistema personalizzato che controlla lo stato dei tuoi server, monitora gli endpoint HTTP, verifica l'utilizzo di CPU e RAM, e invia alert su Slack o Telegram con regole di escalation intelligenti. A differenza delle soluzioni SaaS costose, con n8n hai il pieno controllo sulla logica di alerting.

Prerequisiti

  • Istanza n8n self-hosted funzionante (idealmente separata dai server monitorati)
  • Workspace Slack con un'app configurata e token Bot con permesso chat:write
  • Bot Telegram con token (opzionale, per escalation)
  • Accesso SSH o API ai server da monitorare
  • Canale Slack dedicato agli alert (ad esempio #server-alerts)

Step 1: Uptime check con HTTP monitoring

Crea un workflow con un nodo Schedule Trigger impostato per eseguire ogni 5 minuti. Questo è l'intervallo ideale per bilanciare tempestività e consumo di risorse.

Aggiungi un nodo HTTP Request per ogni endpoint da monitorare. Configura ciascuno con:

  • URL: l'indirizzo completo dell'endpoint (ad esempio https://api.tuodominio.it/health)
  • Method: GET
  • Timeout: 10 secondi (un tempo di risposta superiore indica problemi)
  • Options: disabilita "Follow Redirects" se vuoi verificare che l'endpoint risponda direttamente

Attiva l'opzione "Continue on Fail" sul nodo HTTP Request. In questo modo, se la richiesta fallisce, il workflow continua invece di fermarsi, e puoi gestire l'errore nel nodo successivo.

Dopo ogni HTTP Request, aggiungi un nodo IF che verifica:

  • Il codice di risposta è 200 (o il range 2xx)
  • Il tempo di risposta è inferiore a 3 secondi
  • Il body contiene una stringa attesa (ad esempio "ok" o "healthy")

Se una qualsiasi condizione fallisce, il ramo "false" attiva l'alert.

Step 2: Monitoraggio CPU, RAM e disco

Per il monitoraggio delle risorse di sistema, hai due opzioni:

Opzione A - Via API esterna: installa un agent leggero sul server (come node_exporter di Prometheus) e interroga le metriche tramite HTTP Request. Questa è la soluzione più pulita e non richiede accesso SSH da n8n.

Opzione B - Via SSH: usa il nodo SSH per eseguire comandi direttamente sui server. Configura le credenziali SSH in n8n e usa questi comandi:

Per la CPU: esegui top -bn1 | grep "Cpu(s)" | awk '{print $2}' che restituisce la percentuale di utilizzo della CPU.

Per la RAM: esegui free -m | awk '/Mem:/{printf "%.1f", $3/$2*100}' che restituisce la percentuale di RAM utilizzata.

Per il disco: esegui df -h / | awk 'NR==2{print $5}' | tr -d '%' che restituisce la percentuale di spazio disco occupato sulla partizione root.

Dopo ogni comando SSH, usa un nodo Code per parsare l'output e convertirlo in numero. Poi un nodo IF confronta il valore con le soglie:

  • CPU sopra l'85%: warning
  • CPU sopra il 95%: critical
  • RAM sopra il 90%: warning
  • Disco sopra l'85%: warning
  • Disco sopra il 95%: critical

Step 3: Configurare gli alert su Slack

Per ogni condizione di alert, aggiungi un nodo Slack con l'operazione "Send Message". Configura il messaggio con Block Kit per renderlo leggibile e azionabile:

Struttura il messaggio con questi elementi:

  • Emoji indicatore di severità (warning o critical)
  • Nome del server e dell'endpoint coinvolto
  • Metrica fuori soglia con valore attuale e soglia configurata
  • Timestamp dell'evento
  • Link diretto al server o alla dashboard per investigare

Per evitare lo spam di notifiche, implementa un meccanismo di deduplicazione. Usa un nodo Code che salva lo stato dell'ultimo alert in una variabile statica o in un file. Se lo stesso alert è stato inviato meno di 15 minuti fa, non reinviarlo. Questo previene il flood di notifiche quando un problema persiste.

Step 4: Regole di escalation

Configura una logica di escalation progressiva per assicurarti che i problemi critici non vengano ignorati:

Livello 1 - Slack channel: il primo alert va nel canale #server-alerts. Il team DevOps lo vede durante l'orario lavorativo.

Livello 2 - Messaggio diretto Slack: se dopo 15 minuti il problema persiste (il check successivo fallisce ancora), invia un messaggio diretto al DevOps di turno su Slack. Usa il nodo Slack con l'operazione "Send Message" e specifica l'utente invece del canale.

Livello 3 - Telegram: se dopo 30 minuti il problema è ancora presente, invia una notifica Telegram al responsabile tecnico. Il nodo Telegram con l'operazione "Send Message" è ideale perché le notifiche Telegram arrivano anche a telefono bloccato.

Per tracciare i livelli di escalation, usa un nodo Google Sheets o un database per registrare quando un alert è stato generato e a che livello si trova. A ogni esecuzione del workflow, controlla se esistono alert aperti e a quale livello sono arrivati.

Step 5: Dashboard di stato

Crea un secondo workflow che genera un report giornaliero dello stato dell'infrastruttura:

Configura un Schedule Trigger alle 9:00 di ogni giorno lavorativo. Il workflow:

  1. Legge il log degli alert delle ultime 24 ore dal foglio Google Sheets
  2. Aggrega i dati: numero di incidenti per server, tempo medio di risposta degli endpoint, percentuale di uptime
  3. Formatta un messaggio di riepilogo con le metriche principali
  4. Invia il report sul canale Slack #daily-status

Per calcolare l'uptime, conta il numero totale di check (288 al giorno con intervalli di 5 minuti) e il numero di check falliti. L'uptime è (check_totali - check_falliti) / check_totali * 100.

Step 6: Gestione dei recovery

Non basta notificare i problemi: è importante anche segnalare quando un servizio torna operativo. Aggiungi questa logica:

Quando un check che era in stato di errore torna a rispondere correttamente, invia un messaggio di "recovery" su Slack con:

  • Nome del server o endpoint ripristinato
  • Durata del downtime
  • Timestamp del ripristino

Per implementare questa logica, mantieni uno stato persistente (Google Sheets o variabile di workflow) che registra gli endpoint attualmente in errore. Quando un endpoint in errore torna sano, genera la notifica di recovery e rimuovilo dalla lista.

Questo sistema di monitoraggio ti offre visibilità completa sull'infrastruttura con alert intelligenti che non sovraccaricano il team ma garantiscono che nessun problema passi inosservato.

Altre guide DevOps