Monitoring IT — Cheat Sheet

Tag: monitoring, observability, metrics, logs, tracing, alertmanager, prometheus, grafana

Livello: intermedio

TL;DR: Fondamenti di monitoraggio infrastrutturale e applicativo, gestione delle metriche chiave, logging centralizzato e strategie di alerting per garantire SLA ed elevata affidabilità.

Concetti chiave

Distinzione netta tra monitoraggio (rilevare guasti noti) e osservabilità (comprendere stati interni imprevisti).

I tre pilastri dell'osservabilità: metriche (aggregazioni numeriche), log (eventi discreti), trace (flusso distribuito).

Le quattro Golden Signals di Google SRE: latenza, traffico, errori e saturazione delle risorse di sistema.

Metodologia USE per le risorse infrastrutturali: Utilization, Saturation, Errors.

Metodologia RED per i servizi architetturali: Rate (richieste/sec), Errors (fallimenti/sec), Duration (latenza).

Push vs Pull: Prometheus interroga gli endpoint (/metrics), agenti stile Telegraf o Datadog inviano dati.

Alerting orientato ai sintomi percepiti dagli utenti finali piuttosto che alle mere cause tecniche interne.

Definizione rigorosa di SLI (indicatore reale), SLO (obiettivo interno concordato) e SLA (accordo formale contrattuale).

Retention policy differenziata per bilanciare granularità storica, requisiti di audit e costi di archiviazione.

Black-box monitoring (test sintetici esterni) integrato con white-box monitoring (metriche esposte dall'applicazione).

Domande tipiche e risposte pronte

Q: Come imposti la soglia di un alert per evitare il fenomeno dell'alert fatigue?R: Allineo gli alert agli impatti diretti sugli SLO e sugli utenti, riservando le notifiche immediate solo ad anomalie critiche e actionable.

Q: Qual è la differenza applicativa tra RED e USE nei tuoi progetti?R: Uso la metodologia RED per analizzare servizi HTTP e API backend, mentre applico la USE per componenti infrastrutturali come CPU, RAM e dischi.

Q: Come gestisci il logging distribuito in ambienti a microservizi?R: Centralizzo i log iniettando un Correlation ID univoco tramite middleware HTTP, propagato attraverso tutte le chiamate interne per tracciare le richieste end-to-end.

Insidie e errori comuni

Generare notifiche su soglie statiche di CPU senza correlazione con degradi effettivi delle performance.

Mancanza di deduplica e grouping nelle regole di invio alert, provocando cascate di notifiche ridondanti.

Loggare dati sensibili o PII in chiaro nei flussi di stdout, violando standard di conformità.

Ignorare la cardinalità elevata nei label delle metriche dimensionali, saturando la memoria del Time Series Database.

Monitorare esclusivamente l'infrastruttura sottostante trascurando l'esperienza e la transazionalità utente.

Snippet e comandi

# Esempio regola Prometheus Alertmanager per errori HTTP
groups:
  - name: service_alerts
    rules:
      - alert: HighHttpErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100 > 5
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Tasso di errori HTTP 5xx superiore al 5% negli ultimi 5 minuti"

Bash

# Verifica rapida dello stato dei processi e dell'I/O su host Linux
top -b -n 1 | head -n 20
iostat -xz 1 3
journalctl -u app-service.service -n 50 --no-pager

Da ripassare

[ ] Regole di aggregazione e funzioni temporali PromQL (rate vs irate)

[ ] Configurazione dei bucket di latenza negli istogrammi OpenTelemetry

[x] Differenza tra metriche di tipo Counter, Gauge, Histogram e Summary

[x] Strategie di sampling per distributed tracing ad alto volume

Jarvis Interviews
Jarvis