Monitoring e Observability: La Guida Definitiva per Applicazioni e Infrastruttura in Produzione

Se la tua applicazione va in crash e non sai perché, non hai un problema tecnico: hai un buco nero informativo. Monitoraggio e observability non sono optional, sono il cruscotto del pilota. Eppure, nella maggior parte delle PMI italiane che seguiamo, vedere un pannello Grafana è ancora un lusso, non una prassi. Noi di Meteora Web ci occupiamo di stack produttivi da oltre otto anni: server, app Laravel, WooCommerce, API. Ogni volta che un cliente ci dice “il sito è lento” senza dati, sappiamo che il problema non è il sito: è la mancanza di metriche. Questa pillar page ti dà le basi per costruire un sistema di monitoring e observability che funziona davvero, senza sbrodolare teoria. Partiamo dai fondamenti e arriviamo agli strumenti che usiamo ogni giorno.

I tre pilastri dell’observability: log, metriche, trace

L’observability nasce dal principio che un sistema software produce dati. Tre famiglie: log (eventi discreti), metriche (misure numeriche aggregate), trace (percorso di una richiesta attraverso i servizi). Senza tutti e tre, stai volando a vista. Esempio: il carrello del tuo e-commerce non funziona. Con le metriche vedi un picco di errori HTTP 500. Con i log trovi l’eccezione “Connection refused” verso il database. Con i trace capisci che è un microservizio di pagamento che cade in timeout. Tre pezzi, un’unica verità.

Noi, di Meteora Web, partiamo sempre da uno stack minimo: Prometheus per le metriche, Loki per i log (alternativa leggera a ELK), e Tempo per i trace (OpenTelemetry). Ma ogni componente può essere sostituito in base al budget e alla maturità del team.

Cosa fare adesso: identifica il punto più dolente della tua app (es: login lento, checkout che va in timeout). Installa un semplice generatore di metriche lato server (es: php artisan metrics su Laravel) e prova a visualizzare un grafico su Grafana. Non serve l’intero stack subito: un dato vale più di zero dati.

Prometheus: metrics scraping, alerting e PromQL

Prometheus è lo standard de facto per il monitoring delle infrastrutture e delle applicazioni. Funziona a pull: lo scrapes (chiede) metriche a endpoint HTTP esposti dai tuoi servizi. Noi lo usiamo per monitorare CPU, RAM, disco, ma anche metriche applicative come numero di ordini al minuto o latenza delle query. La configurazione di base è un file YAML:

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'laravel_app'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['app-server:8000']

Il linguaggio di query PromQL ti permette di calcolare tassi, medie, percentile. Esempio: rate(http_requests_total[5m]) ti dà le richieste al secondo negli ultimi 5 minuti. Con questo puoi impostare alert su Alertmanager: se il tasso di errori supera l’1%, ricevi una notifica.

Cosa fare adesso: se hai un server Linux, installa node_exporter (download ufficiale) e configurane lo scrape. Apri su browser il target /metrics per vedere i dati grezzi. Poi lanci una query in Prometheus: up. Se vedi 1, sei partito.

Grafana: dashboard, datasource, alerting

Grafana è la faccia bella del monitoring. Collega Prometheus, Loki, Elasticsearch, CloudWatch, e ti permette di creare pannelli visuali. Noi costruiamo dashboard su misura per ogni cliente: velocità di caricamento, conversioni, errori 404, uptime. L’importante è non affogare nei grafici. Una dashboard serve a rispondere a domande specifiche: “Il sito è veloce oggi?” “Quanti ordini abbiamo perso per errori 500?”.

Un pannello tipico: rate(http_requests_total{status=~"5.."}[5m]) su un grafico a linee, con soglia rossa a 0.5. Se supera, alert. Grafana ha un sistema di alerting integrato che può notificare via email, Slack, Telegram. Noi preferiamo Telegram perché è diretto e meno rumoroso della mail.

Cosa fare adesso: connetti Grafana al tuo Prometheus (guida ufficiale). Importa una dashboard predefinita per node_exporter (ID 1860). Poi modifica la variabile di intervallo temporale. Hai subito una panoramica del server.

ELK Stack: log centralizzati con Elasticsearch, Logstash, Kibana

I log sono la cronaca di ogni evento. Per i progetti più grandi – o per analisi di sicurezza – usiamo ELK. Elasticsearch indicizza e rende ricercabili i log, Logstash li trasforma e li spedisce (o Filebeat per leggere file di log), Kibana li visualizza. La configurazione di Logstash è semplice:

input {
  file {
    path => "/var/www/laravel/storage/logs/*.log"
    start_position => "beginning"
  }
}
filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{GREEDYDATA:message}" }
  }
}
output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "laravel-logs-%{+YYYY.MM.dd}"
  }
}

ELK è potente ma pesante: richiede RAM e manutenzione. Per team piccoli, noi consigliamo Loki di Grafana: meno feature ma molto più leggero. La scelta dipende dal volume di log e dal budget.

Cosa fare adesso: se sei su Laravel, attiva il logging strutturato (vedi sezione sotto) e invia i log a un indice Elasticsearch di prova. Usa Kibana per cercare la parola “error” negli ultimi 15 minuti. Se trovi qualcosa, hai già vinto.

OpenTelemetry: lo standard aperto per tracing e metriche

OpenTelemetry (OTel) è il framework che unifica la raccolta di trace, metriche e log. Nato dalla fusione di OpenTracing e OpenCensus, è oggi il modo più pulito per instrumentare applicazioni. Noi lo abbiamo integrato in Laravel tramite un middleware personalizzato: ogni richiesta genera uno span che viene inviato a un collector (es: Jaeger o Tempo).

Il vantaggio? Non sei più legato a un vendor. Con OTel puoi passare da DataDog a Grafana Cloud senza riscrivere il codice. È uno standard che consigliamo a tutti i clienti che iniziano un nuovo progetto backend.

Cosa fare adesso: esamina la documentazione ufficiale OpenTelemetry. Installa il SDK per il tuo linguaggio (PHP: composer require open-telemetry/opentelemetry) e instrumenta un endpoint. Verifica che il trace arrivi a un collector. Un’ora di setup oggi ti risparmia settimane di debugging domani.

APM: Application Performance Monitoring a confronto

APM (come New Relic, Datadog, Dynatrace) ti dà visibilità end-to-end sulle performance delle applicazioni: transazioni lente, query database, stack trace. Sono strumenti pronti all’uso, ma a caro prezzo. New Relic costa circa 0,30€ per GB di dati ingeriti, Datadog ha un pricing base per host. Per una piccola impresa, il conto può arrivare a centinaia di euro al mese.

Alternativa open source: SigNoz (basato su OpenTelemetry) o HyperDX. Noi abbiamo scelto una via ibrida: OpenTelemetry per il tracing, Grafana per la visualizzazione, e paghiamo solo lo storage cloud (sotto i 20€/mese per un piccolo cluster). La scelta dipende da quanto sei disposto a investire in setup vs canone. Ma il ritorno è enorme: sapere che una query impiega 2 secondi invece di 50ms può far risparmiare ore di indagine.

Cosa fare adesso: se hai già uno di questi APM, controlla la sezione “Service Map” o “Transaction Dashboard”. Trova la transazione più lenta. Ottimizzala (es: aggiungi un indice al database). Se non hai APM e il sito è lento, valuta prima un approccio manuale: Xdebug e log strutturati. Poi, quando ne hai bisogno, scegli OpenTelemetry.

Log strutturati: JSON logging best practice

I log testuali sono il nemico della ricercabilità. “Errore: qualcosa è andato storto” non ti aiuta. Il log strutturato in JSON permette di filtrare per livello, contesto, utente, ID richiesta. Esempio in Laravel:

Log::channel('stack')->error('Pagamento fallito', [
    'order_id' => 12345,
    'amount' => 99.99,
    'gateway' => 'stripe',
    'user_agent' => request()->userAgent()
]);

Con questo, in Kibana o Loki puoi cercare tutti i pagamenti falliti per Stripe sopra 50€. Non solo: aggiungi context per correlare log e trace (es: trace_id). Questa è la base dell’observability. Noi lo facciamo in tutti i progetti Laravel che portiamo in produzione.

Cosa fare adesso: modifica il canale di logging in config/logging.php per usare 'driver' => 'daily', con 'tap' => [App\Logging\CustomizeFormatter::class] che aggiunga il log in JSON. Poi verifica con tail -f storage/logs/laravel.log che i messaggi siano in formato JSON.

Alert management: Alertmanager, PagerDuty e come ridurre l’alert fatigue

Gli alert sono come gli allarmi antincendio: troppi falsi positivi e nessuno li ascolta. Con Prometheus e Alertmanager puoi raggruppare, silenziare e instradare le notifiche. Regole di esempio:

groups:
  - name: example
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Errori HTTP 5xx superiori all'1%"

Poi in Alertmanager configuri un canale (Slack, Telegram, PagerDuty). L’errore comune è attivare alert su ogni picco. Noi usiamo la tecnica del “for”: se l’allarme dura più di 5 minuti, scatta. Questo evita falsi allarmi da picchi momentanei. Inoltre, categorizziamo per severità: critico (rispondi subito), warning (da valutare), info (da ignorare in produzione).

Cosa fare adesso: rivedi le tue regole di alert. Hai alert che scattano più di una volta al giorno? Alza la soglia o aggiungi un for di 10 minuti. Implementa una finestra di manutenzione per i deploy. Se non usi Alertmanager, installalo e connettilo a un canale Telegram.

Uptime monitoring: strumenti e SLA

L’uptime è la promessa minima che fai al cliente. Ma monitorarlo solo dal tuo server interno è come controllare la temperatura di casa stando dentro casa: se non arriva Internet, non te ne accorgi. Per questo usiamo servizi esterni: Better Stack (già Uptime Robot, ora più completo), Checkly, o StatusCake. Configuri un check HTTP ogni minuto (o 5 minuti) da più località globali. Se il timeout supera i 10 secondi, scatta un alert.

Noi consigliamo Better Stack per il rapporto qualità/prezzo: piano gratuito fino a 50 heartbeat, paghi solo per playbook o SSL. Inoltre, ti mostra lo storico dell’uptime e il tempo di risposta medio. Per e-commerce è essenziale: ogni minuto di downtime può costare centinaia di euro.

Cosa fare adesso: crea un account gratuito su Better Stack. Aggiungi il tuo sito come monitor HTTP. Imposta soglia di timeout a 15 secondi. Riceverai una notifica su Slack/Telegram se il sito cade. Poi esporta il report di uptime mensile per confrontarlo con l’SLA del tuo hosting.

Laravel Telescope e Horizon: monitoring applicativo nativo

Se sviluppi con Laravel, hai due gioielli: Telescope per il debugging in tempo reale (requests, queries, jobs, mail, log) e Horizon per la gestione delle code Redis. Noi li usiamo in tutti i progetti Laravel. Telescope è perfetto per sviluppo e staging; in produzione, abilitalo solo per utenti autorizzati (es: admin) e con retention limitata (es: 24h). Horizon mostra code, job falliti, runtime medio.

Ma attenzione: Telescope ha un overhead. Non metterlo su un app ad alto traffico senza limitare i dati raccolti. Noi lo limitiamo a un campionamento del 10% delle richieste, oppure lo spegniamo in produzione e usiamo Loki per i log delle eccezioni. Horizon invece è leggero e indispensabile se usi code per email o elaborazioni batch.

Cosa fare adesso: se hai Laravel, esegui php artisan telescope:install e segui la doc ufficiale. Apri /telescope e guarda le ultime richieste. Trova quella più lenta. Poi installa Horizon con composer require laravel/horizon e configura le code. Ora hai un cruscotto interno che nessun APM esterno ti dà gratis.

In sintesi – cosa fare subito

Non serve implementare tutto in un giorno. Scegli una priorità:

1. Uptime esterno – Better Stack o Uptime Robot, gratis, costa 5 minuti.
2. Metriche server base – Prometheus + node_exporter + Grafana. Dati in un’ora.
3. Log strutturati – JSON logging per errori applicativi. Fondamentale per debug.
4. Alert mirati – una regola sola: errori 5xx > 1% per 5 minuti. Poi aggiungi lentamente.
5. Strumenti nativi Laravel – Telescope in staging, Horizon in produzione se usi code.

Noi, di Meteora Web, lo facciamo tutti i giorni. La flessibilità dei data center, ad esempio, si basa su un monitoring granulare. Senza dati, non esiste decisione. Inizia oggi.