Osservabilità: fogli, metriche, tracciabili

Osservabilità: fogli, metriche, tracciabili

1) Perché è necessario

• Le metriche sono unità compatte per SLI/SLO e alerting per sintomi.
• Traccia - Catene causali di query (end-to-end).
• I loghi sono eventi dettagliati per indagini e verifiche.

Obiettivo: RCA rapido, alert preventivi e affidabilità controllata all'interno di error budget.

2) Principi di architettura

Unico contesto: «trace _ id», «span _ id», «tenant _ id», «sollest _ id», «user _ agente», «client _ ip _ hash».
Standard: OpenTelemetry (OTel) per SDK/Agenti, formato JSON (canonico, con schema).
Sintomi> cause: alertim per sintomi personalizzati (latitanza/errore) anziché per CPU.
Collegamento dei segnali: dalla metrica di → in spans (exemplars) → in loghi specifici per «trace _ id».
Sicurezza e privacy: occultamento di PII nei logi, crittografia in transit/at rested, registri di controllo immutabili.
Multiforme: separa gli spazi dei nomi/chiavi/regole.

3) Tassonomia dei segnali e schemi

3. 1 Metriche

RED (Rate, Errors, Duration) per i servizi e USE (Utilization, Saturation, Errors) per l'infrastruttura.
Типы: counter, gauge, histogram/summary. Per la latitanza - istogram con bucket'ami fissi.
Excplars: riferimento à trace _ id "nei bin hot dell'istogramma.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Tracciati

Span = operazione con «name», «start/end», «attribute», «events», «status».
W3C Trace Text per la portabilità.
Samplace: base (head) + dinamica (tail) + regole «importanza» (errori, p95).

3. 3 Loghi

Solo JSON strutturato; livelli: DEBUG/INFO/WARN/ERRORE.
I campi obbligatori sono «ts _ utc», «level», «messaggistica», «trace _ id», «span _ id», «tenant _ id», «env», «service», «region», «host», «labels {}».
Proibito: segreti, token, PAN, password. PII - Solo tornizzato/mascherato.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) Raccolta e trasporto

Agenti/esportatori (daemonset/sidecar) il buffer sul nodo

Requisiti: back-pressure, retrai, deduplicazione, limitazione della radicalità (labels!), protezione contro «log storms».

Metriche: pull (Prometheus-compatibile) o push tramite OTLP.
Tracciabili: OTLP/HTTP (gRPC), sampler tail sul raccoglitore.
Loghi: raccolta locale (journald/docker/stdout) → Parser → Normalizzatore.

5) Conservazione e retenza (tiered)

Metriche: TSDB hot 7-30 giorni (con downsample), unità più lunghe (90-365 giorni).
Tracciati: 1-7 giorni pieni, poi agregati/span servizi «importanti»; memorizzare gli indici in «servizio», «status», «errore».
Logi: indice caldo 7-14 giorni, caldo 3-6 mes, archivio fino a 1-7 anni (compilation). Controllo - WORM.

Ottimizzazione dei costi: downsampling, filtraggio DEBUG in vendita, quote discografiche, sampling per le piste.

6) SLI/SLO, alerting e servizio

SLI: disponibilità (% delle richieste di successo), latitanza (p95/p99), quota 5xx, freschezza dei dati, percentuale di successo delle ecc.
SLO: obiettivo SLI (ad esempio 99. 9% di successo di 400 ms).
Error budget: 0. L' 1% di «diritto di errore» → le regole del phichfreese/esperimento.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silos-alert (CPU/Disk) - solo come ausiliari, senza paging.

7) Correlazione dei segnali

Metrika «rossa» clicca nell' ar «particolare» trace _ id « osservando» lento «span», aprendo i loghi con lo stesso «trace _ id».
Correlazione con le release: attributi «variante», «immagine _ sha», «feature _ flag».
Per i dati/ETL: «dataset _ urn», «run _ id», collegamento con lineage (vedere l'articolo corrispondente).

8) Semilibertà e cardinalità

Metriche: limitiamo le etichette (senza user _ id, sessione _ id); quote/validazione al momento dell'iscrizione.
Traccia: combiniamo head-sample (all'ingresso) e tail-sample (sul raccoglitore) con le regole: «Tutto ciò che è 5xx, p99, gli errori sono al 100%».
Fogli: livelli e drosselazione per errori ripetuti frequenti - Eventi di aggregazione (chiave dedupe).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Sicurezza e privacy

In Transit/At Rest: crittografia (TLS 1. 3, AEAD, KMS/HSM).
PII/segreti: igienizzatori prima dell'invio, tornizzazione, occultamento.
Accesso: ABAC/RBAC in lettura; Separazione dei ruoli producers/readers/admins.
Controllo: registro di accesso a login/piste invariato; esportazione - in una vista criptata.
Multiforme: namespades/tenant-labels con regole; isolamento delle chiavi di crittografia.

10) Profili di configurazione (sezioni)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Dati/ETL e streaming

SLI per dati: freschezza (max lag), completezza (rows vs expectation), qualità (validatori/duplicati).
Alert, finestra saltata, squadra di consulenza, DLQ in crescita.
Correlazione: «run _ id», «dataset _ urn», eventi lineage; tracciati per pipline (span per batch/partition).
Kafka/NATS: metriche produttore/consulente, lega/rifiuto; tracciamento headers (ad esempio, 'traceparent').

12) Profilatura e eBPF (segnale avanzato)

Percorsi a caldo a basso livello CPU/alloc/IO; profili per l'incidente.
La telemetria eBPF (ritardi di rete, DNS, chiamate di sistema) collegata a «trace _ id »/PID.

13) Test di osservabilità

Contratto di segnale - Verifica dell'esportazione di metriche/etichette/istogrammi in CI.
Synthetic probes: RUM/client simulati per SLI esterni.
Chaos/Fire drills - Spegnere le dipendenze, degradare - vedere come reagiscono gli alert e gli agenti di servizio.
Smoke in vendita - Verifica post-deposito che i nuovi endpoint hanno metriche e ricalco.

14) Costo e controllo dei volumi

Budget per segnale/comando; «cost per le parole».
Cardinalità sotto budget (SLO per cardinality), limiti per le nuove etichette.
Downsampling, retenze per classe di dati, archivi freddi e WORM per il controllo.

15) Utilizzo e SLO della piattaforma di osservabilità

Piattaforma SLO 99. 9% degli ingesti di successo; 30 c di ritardo nell'indice delle metriche, 2 min di , 1 min di .
Gli alert della piattaforma sono la lega dell'iniezione, la crescita dei drop, l'errore di firma/crittografia, il sovraccarico dei buffer.
DR/HA: multifunzione, replica, backup di configurazioni/regole.

16) Assegno fogli

• Dappertutto «trace _ id »/« span _ id»; Logi JSON con schema.
• metriche RED/USE con istogrammi; Le piste sono → are.
• Tail-sampling abilitato Regole 5xx/p99 = 100%.
• Alert per sintomi + runibuki; orologi silenziosi/anti-flap.
• Igiene PII; crittografia at rest/in transit; WORM per il controllo.
• Retenze e budget per quantità/cardinalità.

• Panoramica mensile degli alert (rumore/precisione), soglie di tuning.
• Report di errore budget e misure adottate (phichfris, hardening).
• Controllare i rivestimenti di dashboard/logi/piste per percorsi critici.
• Incidenti di formazione e aggiornamento runbook '.

17) Runbook’и

RCA crescita p99/pay

1. Apri il dashboard RED per «checkout».
2. Camminare su una pista call`).
3. Apri i loghi dì trace _ id "per vedere i timeout/retrai.
4. Includi flag Fiech di ripristino/limite RPS e avvisa i proprietari della dipendenza.
5. Dopo la stabilizzazione - RCA, tickets per l'ottimizzazione, test di riproduzione.

1. La SLI «freschezza» della pista red jobs-failing passo.

2. Controlla la lega del broker/DLQ, errori del connettore.

3. Avvia reprocess, avvisa i consumatori (BI/prodotto) attraverso il canale di stato.

18) Errori frequenti

Fogli senza schema e senza «trace _ id». Le indagini durano di tanto in tanto.
Gli alert dell'infrastruttura invece dei sintomi. Paging va nel latte.
L'infinita cardinalità delle metriche. L'esplosione dei costi e l'instabilità.
Tutte le piste sono al 100%. Costoso e non necessario; accendete il seme intelligente.
PII/segreti nei reparti. Accendete i servizi igienici e le liste rosse.
Fichi muti. Nuovo codice senza metriche/piste/cassetti.

19) FAQ

C: È necessario conservare il testo grezzo dei cassetti?
Oh, sì, ma con la retinenza e gli archivi; Gli alert e gli SLO sono sufficienti. Controllo - WORM.

C: Cosa scegliere per le piste - head o tail sampling?
A: Combina: head-probabilistic per rivestimento base + tail-rule per errori e anomalie.

C: Come collegare metriche personalizzate e tecniche?
O: Attraverso il generico «trace _ id» e le etichette aziendali («route», «tenant», «plan») e attraverso gli eventi del prodotto (conversione) correlati alle piste.

Come non annegare negli alert?
Bada per sintomi, inserisci orologi silenziosi, deduplicazione, raggruppamento, priorità SLO e proprietario-predefinito per ogni alert.

• Controllo e registri invariati
• Crittografia In Transit/At Rest'
• «Gestione dei segreti»
• Origine dati
• «Privacy by Design (GDPR)»
• Garanzia di spedizione Web Hook