Pila di osservabilità

1) Perché una pila di osservabilità

RCA rapido e riduzione di MTTR da sintomo a causa in minuti.
Gestione SLO: misurazione degli errori/latitanza, allerting del budget errato.
Controllo dei rilasci: cartelle canarie, auto-rollback per metriche.
Sicurezza e controllo: piste di accesso, anomalie, Legale Hold.
Trasparenza FinOps: costo di archiviazione/query, cost-per-SLO.

Metodologie: Golden Signals (latency/traffic/errors/saturation), RED, USA.

2) Architettura base stack

Componenti per livello

Raccoglimento/agenti: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Depositi: S3/GCS/MinIO di oggetti (freddo prolungato), SSD (righe calde).
Query/visualizzazione: Grafana (pannelli, widget SLO), Kibana (se ELK).
Gestione: Alertmanager/Grafano-alert, servizio-catalogo, RBAC, segreto-manager.

Pattern di distribuzione

Managed (Grafana Cloud/Cloud Services) è veloce e costoso in quantità.
Self-hosted in K8s - controllo completo, ha bisogno di essere utilizzato e FinOps.

3) Standard di dati: un unico «schema di osservabilità»

3. 1 Metriche (Prometheus/OpenMetrics)

Etichette obbligatorie: «env», «region», «cluster», «namespace», «service», «variante», «tenant», «endpoint».
Nome: «snake _ case», suffissi «_ total», «_ seconds», «_ byties».
Istogrammi fissi «buckets» (SLO-orientati).
Cardinalità: non includere «user _ id», «sollest _ id» nelle etichette.

3. 2 Loghi

Formato: JSON; i campi obbligatori «ts», «level», «service», «env», «trace _ id», «span _ id», «msg».
PII - Maschera su agente (PAN, token, e-mail, ecc.).
Etichette di Loki: solo bassa cardinalità («app», «namespace», «level», «tenant»).

3. 3 Piste

OTTEL semantica: 'service. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: i percorsi di destinazione p99 sono «always _ on »/tail-sampling, il resto è« part/ratio ».
Incorporare l'ID: scorrere «trace _ id/span _ id» nei fogli e nelle metriche (labels/fields).

4) Correlazione M-L-T (Metrics/Logs/Pista)

Dal grafico dell'alert (metrico) vengono i loghi filtrati sù trace _ id "per una pista specifica.
Dalla pista (span lento) viene richiesta una metrica di un backend specifico all'intervallo di span.
I pulsanti Drilldown nei pannelli sono «ai fogli» e «alle piste» con la sostituzione delle variabili («$ env», «$ service», «$ trace _ id»).

5) OpenTelemetry Raccoglitore: pipline di riferimento

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Alerting: SLO e multi-burn

L'idea è che l'alertim non è CPU> 80%, bensì su Errore Budget.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7) Dashboard: struttura delle cartelle

00 _ Overview - piattaforma: SLO, p95, 5xx%, capacity, incidenti attivi.
10 _ Services - RPS, p95/p99, errori, release (annotazioni).
20 _ Infra - K8s/nodi/store/rete, etcd, controller.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40 _ Edge/DNS/CDN/WAF - ingress, LB, regole WAF.
50 _ Synthetic - farmacia e script headless.
60_Cost/FinOps - stoccaggio, richieste, caldo/freddo, prognosi.

Ogni pannello descrive, unità, proprietario, link runbook, drilldown.

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Piste: TraceQL e trucchi

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Sintetica e farmacia

Blackbox-exporter: HTTP/TCP/TLS/DNS da regioni ≥3/ASN.
Headless: login/deposit script pianificato.
Quorum-alert: attivazione se le regioni ≥2 vedono un rifiuto.
Stato pagina - Update automatici + commenti manuali.

11) Conservazione e ritocco

Metriche: più caldo di 7-30 giorni (righe veloci), downsampling/recording rule, fredda di archiviazione oggetti (mesi).
Loghi: caldo 3-7 giorni, seguito da S3/GCS con indice (Loki chunk store/ELK ILM).
Piste: 3-7 giornì always _ on '+ conservazione prolungata per campionamenti (tail-sampled/scartoffie).

• Rollover per dimensioni e tempo; budget per le richieste (quote/limiti).
• Criteri separati per prod/stage e dati di protezione.

12) Multi-tenenza e accessibilità

Suddivide in tenant/namespace/space, indice-pattern e autorizzazioni.
Etichetta le risorse per il biling: «tenant», «service», «team».
Dashboard/alert importati - in spazi specifici comandi.

13) Sicurezza e compliance

TLS/mTLS da agenti a beckend, HMAC per health private.
RBAC per la lettura/scrittura, controllo di tutte le richieste e gli alert.
Redazione PII sul bordo; Vietare i segreti nei reparti; DSAR/Legal Hold.
Isolamento: singoli cluster/neimspace per domini sensibili.

14) FinOps: costo di osservazione

Riduciamo la cardinalità delle etichette e la logica in ingest (non nelle richieste).
Pista di sampling + bersaglio always-on per vie critiche.
Downsampling/recording rule per aggregazioni pesanti.
Archiviazione di un raro accesso a oggetti freddi.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD e test di osservabilità

Linting metriche/loghi in CI: divieto di «esplosione» della radicalità, controllo istogrammi/unità.
Test di osservabilità Contract: metriche/campi di logi obbligatori, 'trace _ id' in middleware.
Canary - Annotazioni di release su grafici, SLO-auto-rollback.

16) Casi: query rapide

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

Da logi a piste (Loki → Tempo): passa «trace _ id» come linfa a Tempo UI/dashboard.

17) Qualità della pila: foglio di assegno

• Diagrammi di metriche/fogli/piste e unità di misura coerenti.
• 'trace _ id', nei fogli e nelle metriche, drilldown dei pannelli.
• Multi-burn SLO-alert senza flapping (quorum/multi-window).
• Downsampling, quote di query, limiti per passo/intervallo.
• Le retenschn e le classi di conservazione sono documentate e applicate.
• RBAC/controllo/Revisione PII sono inclusi.
• Dashboard: proprietario, runbooks, ≤2 -3 schermate, risposta rapida.
• FinOps-dashboard (volumi, valore, top-board).

18) Piano di implementazione (3 iterazioni)

1. MVP (2 settimane): Prometheus→Mimir, Loki, Tempo; OTel Collector; dashboard di base e SLO-alert; blackbox-test.
2. Scale (3-4 settimane): tail-sampling, downsampling, multi-regione ingest, RBAC/Space, FinOps-dashboard.
3. Pro (4 + settimane): auto-rollback SLO, headless-sintetico percorsi chiave, Legale Hold, portafoglio SLO e reporting.

19) Anti-pattern

«Belli grafici senza SLO», niente azione.
Etichette ad alta radicalità («user _ id», «sollest _ id») - Esplosione di memoria e costo.
Nessuna correlazione tra i loghi senza JSON e senza «trace _ id».
Alert per risorse invece dei sintomi - rumore e bruciatura on-call.
L'assenza di politiche di restrizione è un aumento incontrollato dei costi.

20) Mini FAQ

Cosa scegliere tra Loki o ELK?
ELK per la ricerca/sfaccettatura complessa Loki è più economico e veloce per questi scenari grep. Usano spesso l'ibrido.

Tutti hanno bisogno delle piste?
Sì, almeno nei percorsi chiave (login, checkout, payments) con tail-sampling - questo accelera drasticamente RCA.

Come si ricomincia da zero?
OtTel Collector di Mimir/Loki/Tempo ha SLO di base e blackbox-provini, poi dashboard e burn-alert.

Totale

La pila di osservabilità non è un insieme di strumenti separati, ma un sistema coerente: standard di dati uniformi, correlazione M-L-T-SLO-alerting e sintetico, sicurezza e . Fissare gli schemi, la disciplina delle etichette e delle retensioni, collegare OTEL, aggiungere drilldown e auto-rollback - e ottenere affidabilità gestita con un costo comprensibile.