Stiva de observabilitate

1) De ce aveți nevoie de o stivă de observabilitate

RCA rapidă și MTTR redusă: de la simptom la cauză în câteva minute.
Managementul SLO: măsurarea erorilor/latenței, alertă prin buget eronat.
Controlul eliberării: calcule canare, auto-rollback după valori.
Securitate și audit: căi de acces, anomalii, deținere legală.
Transparența FinOps: costul de stocare/cereri, cost-per-SLO.

Metodologii: Semnale de aur (latență/trafic/erori/saturație), RED, UTILIZARE.

2) Arhitectura stivă de bază

Componente după strat

Colectare/agenți: Exportatori, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-sonde.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, distribuitori/ingeratori Loki, ingeratori Tempo/Jaeger.
Depozite: S3/GCS/MinIO obiect (lung la rece), SSD (rânduri fierbinți).
Interogări/vizualizare: Grafana (panouri, widget-uri SLO), Kibana (dacă ELK).
Management: Alertmanager/Graphana alerts, service catalog, RBAC, secret manager.

Modele de implementare

Gestionat (Grafana Cloud/servicii cloud) - rapid și mai scump pe volume.
Auto-găzduit în K8s - control complet, are nevoie de funcționare și FinOps.

3) Standardele de date: „schema unificată de observabilitate”

3. 1 Metrics (Prometheus/OpenMetrics)

Etichete obligatorii: 'env', 'region', 'cluster', 'namespace', 'service', 'version', 'chiriaş' (dacă sunt multi-chiriaşi), 'endpoint'.
Denumire: 'snake _ case', suffixes '_ total', '_ seconds',' _ bytes '.
Diagrame de bare: „găleți” fixe (orientate spre SLO).
Cardinalitate: nu includeți 'user _ id',' request _ id' în etichete.

3. 2 Busteni

Format: JSON; câmpurile necesare 'ts',' level ',' service ',' env ',' trace _ id', 'span _ id',' msg '.
PII: mascarea pe agent (PAN, jetoane, e-mail, etc.).
Loki labels: numai cardinalitate scăzută ('app', 'namespace', 'level', 'chiriaș').

3. 3 piese

Semantica OTel: "serviciu. nume „,” desfăşurare. mediu „,” db. sistem ',' http. '

Eșantionare: căile țintă p99 sunt „always _ on ”/coadă-eșantionare, restul este„ părinte/raport ”.
Embedding ID: flick 'trace _ id/span _ id' în jurnale și valori (etichete/câmpuri).

4) Corelarea M-L-T (Metrici/Busteni/Urme)

Din graficul de alertă (metric) → jurnalele filtrate de 'trace _ id' → o anumită urmă.
Din urma (lent span), se → o cerere de valori ale unui anumit backend pe intervalul de deschidere.
Butoanele Drilldown din panouri: „pentru jurnale” și „pentru urme” cu substituție variabilă ('$ env', '$ service', '$ trace _ id').

5) OpenTelemetry Colector: Conductă de referință

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) Alertă: SLO și multi-burn

Ideea: alertim nu este la nivelul „CPU> 80%”, ci la consumul de buget de eroare.

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) Tablouri de bord: structura dosarului

00_Overview - platforma: SLO, p95, 5xx%, capacitate, incidente active.
10_Services - prin servicii: SPR, p95/p99, erori, versiuni (adnotări).
20_Infra - K8s/nodes/story/network, etcd, controlere.
30_DB/Queues - PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - reguli de intrare, LB, WAF.
50_Synthetic - uptime și scripturi fără cap.
60_Cost/FinOps - Depozitare, Anchetă, Fierbinte/Rece, Prognoză.

Fiecare panou: descriere, unități, proprietar, link-ul runbook, drilldown.

8) Jurnale: atelier LogQL

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) Piese: TraceQL și trucuri

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

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

10) Sintetice și uptime

Blackbox-exportator: HTTP/TCP/TLS/DNS eșantioane din regiuni ≥3/ASN.
Fără cap: autentificare/depunere scripturi programate.
Alerte de cvorum: declanșate dacă ≥2 regionale văd un eșec.
Status page: actualizări automate + comentarii manuale.

11) Depozitare și păstrare

Metrica: fierbinte 7-30 zile (rânduri rapide), downsampling/înregistrare reguli, rece - depozit obiect (luni).
Jurnale: fierbinte timp de 3-7 zile, apoi S3/GCS cu un index (Loki chunk store/ELK ILM).
Urme: 3-7 zile 'always _ on' + stocare pe termen lung pentru eșantioane (eșantionate/respinse).

• Rollover în dimensiune și timp; buget pentru cereri (cote/limite).
• Politici separate pentru prod/etapa și date de securitate.

12) Multi-chirie și accesele

Separat prin „chiriaș ”/„ namespace ”/Spații, modele de index și rezoluții.
Tag resurse pentru facturare: 'chiriaş', 'serviciu', 'echipă'.
Importați tablouri de bord/alerte - în spațiile unor echipe specifice.

13) Siguranță și conformitate

TLS/mTLS de la agenți la backend, HMAC pentru sănătate privată.
RBAC pentru a citi/scrie, audit toate cererile și alerte.
ediție PII la margine; interzicerea secretelor în jurnalele; DSAR/Legal Hold.
Izolare: clustere separate/nymspaces pentru domenii sensibile.

14) FinOps: costul observabilității

Reducem cardinalitatea etichetelor și logica în ingerarea (și nu în cereri).
Urmăriți eșantionarea + țintă întotdeauna pentru căi critice.
Downsampling/reguli de înregistrare pentru agregări grele.
Arhivarea accesului rar la obiecte reci.
Метрики: 'storage _ cost _ gb _ day', 'query _ cost _ hour', 'cost _ per _ rps', 'cost _ per _ 9'.

15) CI/CD și teste de observabilitate

Linting metrics/busteni in CI: interzicerea „exploziei” cardinalitatii, verificarea histogramelor/unitatilor.
Teste de contract de observabilitate: măsurători/câmpuri de jurnal necesare, 'trace _ id' în middleware.
Canare: adnotări ale versiunilor pe grafice, SLO-auto-rollback.

16) Exemple: interogări 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)

De la jurnale la piste (Loki → Tempo): pass' trace _ id' ca o legătură către Tempo UI/tabloul de bord.

17) Stiva de calitate: lista de verificare

• Scheme și unități metrice/log/trace convenite.
• 'trace _ id' în bușteni și metrici, de la panouri.
• Multi-burn SLO alerte fără clapare (cvorum/multi-fereastră).
• Downsampling, solicita cote, limite pas/interval.
• Clasele de păstrare și stocare sunt documentate și aplicate.
• Revizuirea RBAC/Audit/PII inclusă.
• Tablouri de bord: proprietar, runbooks, ≤2 -3 ecrane, răspuns rapid.
• Tabloul de bord FinOps (volume, costuri, talkeri de top).

18) Planul de implementare (3 iterații)

1. MVP (2 săptămâni): Prometheus→Mimir, Loki, Tempo; Colector OTel; tablouri de bord de bază și alerte SLO; mostre blackbox.
2. Scala (3-4 săptămâni): prelevarea de probe, sub-eşantionare, multi-regiune ingera, RBAC/Spaces, FinOps-tablouri de bord.
3. Pro (4 + săptămâni): auto-rollback pe SLO, sintetice fără cap ale căilor cheie, Legal Hold, portofoliu SLO și raportare.

19) Anti-modele

„Grafică frumoasă fără SLO” - nici o acțiune → nici un beneficiu.
Etichete de înaltă cardinalitate ('user _ id',' request _ id') - o explozie de memorie și costuri.
Jurnalele fără JSON și fără 'trace _ id' - nici o corelație.
Alerte de resurse în loc de simptome - zgomot și de gardă.
Lipsa politicilor de retenție - creșterea necontrolată a costurilor.

20) Mini-Întrebări frecvente

Ce să alegeți: Loki sau ELK?
ELK pentru căutare complexă/fațete; Loki este mai ieftin și mai rapid pentru scenarii ca grep. Un hibrid este adesea folosit.

Toată lumea are nevoie de urme?
Da, cel puțin pe căile cheie (conectare, checkout, plăți) cu eșantionare - acest lucru accelerează dramatic RCA.

Cum să începeți de la zero?
OTel colector → Mimir/Loki/Tempo → mostre de bază SLO și blackbox → apoi tablouri de bord și arde alerte.

Total

Stiva de observabilitate nu este un set de instrumente disparate, ci un sistem consistent: standarde de date uniforme → corelație M-L-T → alertă SLO și sintetice → siguranță și FinOps. Scheme de captare, disciplina de etichetare și retenție, conectați OTel, adăugați drilldown și auto-rollback - și veți obține fiabilitate ușor de gestionat la un cost ușor de înțeles.