Monitorare microservizi e Kubernetes: oltre i semplici controlli di uptime

La crisi del monitoraggio dei microservizi#

Il monitoraggio uptime tradizionale chiede: "Il tuo sito risponde?"

L'architettura moderna a microservizi chiede: "Tutti i 47 microservizi rispondono, e si rispondono correttamente tra di loro?"

Una piattaforma a microservizi è composta da decine di servizi interconnessi:

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

Se UNO di questi servizi fallisce:

• Auth Service down = nessuno può autenticarsi
• Payment Service down = i clienti non possono pagare
• Search Service down = i clienti non trovano i prodotti
• Cache Redis down = il sistema rallenta (guasto a cascata)

Il monitoraggio uptime tradizionale ignora completamente questa complessità.

---

Perché il monitoraggio dei microservizi è diverso#

1. Guasti distribuiti

Nei sistemi monolitici, il guasto è binario: up o down.

Nei microservizi, i guasti sono parziali e a cascata:

Scenario 1: Search Service lento
  - Le richieste di search impiegano 10 secondi (normalmente 200ms)
  - Le richieste frontend vanno in timeout aspettando i risultati
  - La latenza delle richieste API aumenta di 10x
  - Gli utenti vedono "pagina lenta a caricare"
  - Non rilevato dai semplici controlli uptime (l'API tecnicamente risponde)

Scenario 2: Cache Service degradato
  - L'hit rate della cache Redis scende dal 90% al 20%
  - Il database riceve 4x più query
  - La CPU del database sale al 100%
  - Tutte le richieste rallentano (anche quelle non correlate)
  - Guasto a cascata su tutto il sistema

Scenario 3: Guasto comunicazione tra servizi
  - Auth Service è up
  - User Service è up
  - Ma un problema di rete impedisce la comunicazione Auth → User
  - Gli utenti non possono autenticarsi
  - Entrambi i servizi appaiono "up" nel monitoraggio

2. Guasti specifici di Kubernetes

Kubernetes aggiunge complessità:

Ciclo di restart dei Pod:
  - Il pod va in crash per memory leak
  - Kubernetes riavvia automaticamente il pod
  - Il pod sta ripartendo, non risponde al traffico
  - Appare "up" (il pod esiste) ma non serve richieste

Guasto del Node:
  - Un node Kubernetes va down
  - Lo scheduler sposta i pod su altri node
  - I pod stanno bene ma sono temporaneamente non disponibili durante la migrazione
  - Brevi fallimenti di richieste durante la transizione

Problema di Deployment:
  - Il nuovo deployment ha un bug nello startup
  - I pod non riescono a partire
  - I pod esistenti continuano a servire le richieste
  - Il sistema è degradato ma non completamente down

3. Complessità del Service Mesh

Con service mesh (Istio, Linkerd):

Il Service Mesh aggiunge un altro livello:
  - Service → Sidecar → Network → Sidecar → Service
  - Il sidecar può iniettare guasti (rate limiting, timeout)
  - I circuit breaker possono scattare (impedendo le richieste)
  - Il load balancing può essere disuguale (alcune istanze ricevono più traffico)

Il monitoraggio deve includere:
  - Salute del sidecar
  - Stato dei circuit breaker
  - Distribuzione del load balancing
  - Salute del control plane del service mesh

---

Architettura di monitoraggio dei microservizi#

Livello 1: Disponibilità del servizio#

Monitora ogni servizio individualmente:

Auth Service:
  - Il servizio è in esecuzione? (pod count > 0)
  - Risponde ai health check? (GET /health restituisce 200)
  - Qual è il response time? (P95 < 100ms)
  - Qual è l'error rate? (< 0.1%)

Payment Service:
  - Il servizio è in esecuzione?
  - Risponde? (GET /health)
  - Può comunicare con Stripe? (Stripe risponde)
  - Qual è la latenza? (P95 < 500ms)

Livello 2: Comunicazione tra servizi#

Monitora la comunicazione service-to-service:

Auth Service → User Service:
  - Auth Service riesce a raggiungere User Service? (connettività di rete)
  - Qual è la latenza? (P95 < 50ms)
  - Qual è l'error rate? (< 0.01%)

User Service → Database:
  - User Service riesce a raggiungere il database? (salute del connection pool)
  - Il connection pool è esaurito? (in attesa di connessioni)
  - Qual è la latenza delle query? (P95 < 100ms)

Livello 3: Tracing distribuito delle transazioni#

Monitora i flussi completi delle richieste:

Flusso login utente:
  1. API Gateway riceve la richiesta di login
  2. Instrada ad Auth Service (latenza: 10ms)
  3. Auth Service interroga User Service (latenza: 15ms)
  4. User Service interroga il database (latenza: 20ms)
  5. Auth Service firma il JWT token (latenza: 5ms)
  6. API Gateway restituisce la risposta (latenza: 2ms)

Latenza totale: 52ms (accettabile)

Se la query a User Service impiega 500ms invece di 20ms:
  - La latenza totale balza a 532ms
  - L'utente vede un login lento
  - La performance dell'applicazione degrada
  - Il monitoraggio cattura la causa principale (query a User Service lenta)

Livello 4: Monitoraggio specifico Kubernetes#

Monitora l'infrastruttura Kubernetes:

Salute dei Pod:
  - Pod restart count (avviso se > 5 in 24h)
  - Pod memory usage (avviso se vicino ai limiti)
  - Pod CPU usage (avviso se sostenuto > 80%)

Salute dei Node:
  - Stato del node (Ready, NotReady, Unknown)
  - Pressione disco del node (avviso se > 85% pieno)
  - Pressione memoria del node (avviso se < 10% disponibile)

Salute dei Deployment:
  - Replica desiderate vs. ready (avviso se mismatch)
  - Latenza di creazione pod (avviso se > 30 secondi)
  - Errori di image pull (avviso se i pod non partono)

---

Guasto reale di monitoraggio microservizi#

Organizzazione: Piattaforma FinTech con oltre 30 microservizi, 50 pod Kubernetes

Architettura:

• API Gateway (5 repliche)
• Auth Service (3 repliche)
• Payment Service (5 repliche)
• Notification Service (3 repliche)
• Data Pipeline (2 repliche)
• Cache (cluster Redis)
• Database (PostgreSQL)

L'incidente: Elaborazione pagamenti lenta

Cronologia:

• 14:00: I pod di Notification Service riavviano (memory leak)
• 14:05: Creazione lenta dei pod di Notification Service (scheduler Kubernetes sovraccarico)
• 14:10: Le richieste di Payment Service a Notification Service vanno in timeout (il servizio non risponde)
• 14:10: Payment Service implementa retry client-side (exponential backoff)
• 14:15: La tempesta di retry si propaga all'API Gateway
• 14:15: API Gateway sovraccarico, la coda richieste si accumula
• 14:20: Tutte le richieste utente vanno in timeout
• 14:20: Incidente dichiarato, ingegnere on-call allertato

Cosa avrebbe colto il monitoraggio:

• 14:01: Avviso "Notification Service pod restart count superato la soglia"
• 14:06: Avviso "Notification Service pod creation latency > 30 secondi"
• 14:07: Avviso "Notification Service health check fallisce"
• 14:08: Avviso "Payment Service → Notification Service picco di latenza"
• 14:09: Avviso "Payment Service picco di error rate"

Avvisi precoci avrebbero potuto prevenire la cascata: riavviare manualmente Notification Service, o aggiustare la strategia di retry in Payment Service.

---

Implementazione del monitoraggio microservizi#

Opzione 1: DIY con Prometheus + Grafana#

Prometheus:
  - Fa scraping dell'endpoint /metrics di ogni servizio
  - Memorizza le metriche in un database time-series
  - Esegue regole di alert (se la metrica supera la soglia, avvisa)

Grafana:
  - Visualizza le metriche da Prometheus
  - Dashboard per servizio
  - Dashboard per servizio e cross-service

Implementazione: Open-source, gratuito, richiede competenze infrastrutturali
Costo: Basso (solo infrastruttura), Alto (tempo ingegneristico)
Adatto per: Team con competenze DevOps

Opzione 2: Servizio gestito (Datadog, New Relic)#

Agent Datadog/New Relic:
  - Gira come sidecar in ogni pod
  - Raccoglie metriche, log, trace
  - Invia al servizio gestito

Dashboard:
  - Dashboard pre-costruite per Kubernetes
  - APM per la comunicazione tra servizi
  - Tracing distribuito integrato

Implementazione: Strumento vendor, configurazione complessa, potente
Costo: Alto (prezzi per host/per GB), Basso (tempo ingegneristico)
Adatto per: Team con budget, meno competenze ops

Opzione 3: Service Mesh con monitoraggio integrato#

Istio/Linkerd:
  - Il sidecar proxy intercetta tutta la comunicazione tra servizi
  - Traccia automaticamente latenza, errori, traffico
  - Fornisce osservabilità senza modifiche al codice

Monitoraggio:
  - Le dashboard del service mesh mostrano le dipendenze tra servizi
  - Stato dei circuit breaker
  - Distribuzione del traffico
  - Latenza richieste per route

Implementazione: Cambio a livello infrastrutturale, potente ma complesso
Costo: Overhead infrastrutturale (CPU/memoria del sidecar)
Adatto per: Grandi organizzazioni con molti servizi

---

Checklist monitoraggio microservizi#

Per servizio#

☐ Endpoint health check implementato (/health restituisce 200 quando in salute)
☐ Endpoint metriche esposto (/metrics per scraping Prometheus)
☐ Disponibilità del servizio monitorata (pod in esecuzione, health check passa)
☐ Response time del servizio monitorato (latenza P95 tracciata)
☐ Error rate del servizio monitorato (errori 4xx, 5xx tracciati)
☐ Log del servizio centralizzati (ELK, Splunk, o simili)

Per comunicazione tra servizi#

☐ Latenza tra servizi monitorata (servizio A → servizio B)
☐ Error rate per comunicazione tra servizi tracciato
☐ Stato dei circuit breaker monitorato (se applicabile)
☐ Gestione timeout verificata (logica di retry corretta)

Per cluster Kubernetes#

☐ Salute dei pod monitorata (restart count, memoria, CPU)
☐ Salute dei node monitorata (stato, disco, memoria)
☐ Salute dei deployment monitorata (repliche desiderate vs. ready)
☐ Salute dei persistent volume monitorata (spazio disponibile, errori I/O)
☐ Uso risorse per namespace monitorato (limiti CPU, memoria)

Tracing distribuito#

☐ Trace delle richieste raccolti (request ID propagato attraverso i servizi)
☐ Visualizzazione trace disponibile (vedere il flusso della richiesta)
☐ Breakdown latenza dei trace visibile (quale servizio è lento?)
☐ Rilevamento errori nei trace (quale servizio è fallito?)

---

Best practice per il monitoraggio dei microservizi#

1. Correlation ID per tracing distribuito

Ogni richiesta dovrebbe avere un ID univoco propagato attraverso tutti i servizi:

Richiesta utente:
  Header: X-Request-ID: 12345

Service A:
  log: "Request 12345: Started"
  chiama Service B con header: X-Request-ID: 12345

Service B:
  log: "Request 12345: Received from Service A"
  chiama Service C con header: X-Request-ID: 12345

Service C:
  log: "Request 12345: Processing complete"

Più tardi, recupera tutti i log per la richiesta 12345 per vedere il flusso completo

2. Logging strutturato

Non loggare: "Error occurred" Logga: JSON con contesto

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Payment authorization failed",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. Pattern Circuit Breaker

Implementa circuit breaker per prevenire guasti a cascata:

Normale:
  Payment Service → chiama Stripe API
  Stripe restituisce 200 (success)
  La richiesta continua

Modalità guasto (Circuit Open):
  Stripe API restituisce 503 (servizio down)
  Dopo 5 fallimenti, il circuit breaker si apre
  Le richieste successive falliscono velocemente (nessun tentativo di chiamata Stripe)
  La latenza delle chiamate Stripe scende da 2s a 50ms
  Il sistema degrada gradualmente invece di guasto a cascata

Recupero:
  Circuit breaker semi-aperto (testa 1 richiesta)
  Se ha successo, aumenta lentamente le richieste a Stripe
  Se fallisce, il circuit torna aperto

---

Gotcha specifici di Kubernetes#

Gotcha 1: l'IP del Pod cambia al riavvio#

Quando un pod si riavvia, il suo IP cambia. I record DNS devono essere aggiornati.

Il monitoraggio deve tenerne conto:

• Monitora per nome del servizio, non IP del pod
• Usa Kubernetes DNS (service-name.namespace.svc.cluster.local)
• Monitora gli endpoint dei servizi Kubernetes (i pod sono registrati?)

Gotcha 2: ritardi degli init container#

Gli init container Kubernetes girano prima del container principale. Se l'init container è lento:

Stato del pod: "Running" (tecnicamente corretto)
Ma in realtà: l'init container sta ancora girando, il servizio non è ancora pronto
Gli health check potrebbero fallire (il servizio non risponde ancora)

Soluzioni:

• Non avvisare sui fallimenti di health check nei primi 60 secondi
• Usa startup probe (diverse dalle liveness probe)
• Monitora la latenza di completamento degli init container

Gotcha 3: i limiti di risorse impattano la performance#

Se il limite CPU del pod è troppo basso:

Stato del pod: Running
Ma in realtà: CPU throttled, picco di latenza
Il monitoraggio mostra picco di latenza ma l'uso CPU mostra 100% throttled

Soluzione: Monitora sia l'uso CPU SIA il throttling CPU
Avvisa se il throttling CPU > 20% del tempo

---

Nova Uptime per il monitoraggio dei microservizi#

Il piano Free di Nova Uptime può monitorare microservizi:

1. Health Check dei servizi: monitora gli endpoint health di ogni servizio
2. Monitoraggio API: traccia response time e error rate
3. Monitoraggio webhook: verifica la comunicazione service-to-service
4. Monitoraggio email: verifica che il servizio di notifica stia consegnando email
5. Monitoraggio Public API: se i servizi espongono API pubbliche

Per un monitoraggio microservizi completo, usa strumenti specializzati (Prometheus, Datadog, New Relic). Ma Nova Uptime può completarli monitorando la salute dei servizi esterni e le API rivolte ai clienti.

---

Riepilogo: monitoraggio microservizi oltre il semplice uptime#

I microservizi richiedono un monitoraggio più sofisticato dei sistemi tradizionali.

Il tuo piano d'azione:

1. Implementa endpoint health check in ogni microservizio
2. Esponi metriche (endpoint /metrics per Prometheus)
3. Aggiungi correlation ID a tutti i flussi di richieste
4. Implementa circuit breaker per prevenire guasti a cascata
5. Usa logging strutturato con contesto della richiesta
6. Monitora la comunicazione tra servizi (latenza, errori)
7. Monitora l'infrastruttura Kubernetes (pod, node, deployment)
8. Imposta tracing distribuito (vedere il flusso completo della richiesta)
9. Crea dashboard per servizio (visibilità su ciascun servizio)
10. Avvisa sul degrado (non solo sui guasti completi)

Inizia con Nova Uptime per monitorare le tue API rivolte ai clienti. Aggiungi il monitoraggio degli health check. Completa con Prometheus/Grafana o un servizio gestito per un monitoraggio infrastrutturale più profondo.

I tuoi microservizi sono complessi. Il tuo monitoraggio dovrebbe essere all'altezza di quella complessità.