Distribuția semnalelor și a metricii

(Secțiunea: Ecosistem și rețea)

1) Scop și domeniu

• Limbaj de telemetrie unificat și contracte de date.
• Canale QoS gestionate: prioritatea semnalelor critice.
• SLI/SLO transparent și alertă previzibilă.
• Măsurători privind confidențialitatea, izolarea și economiile bugetare.

2) Taxonomia semnalului

1. Evenimente de afaceri: onboarding, depozite/plăți, evenimente de jocuri de noroc, atribuire.
2. Valori tehnice: latență/transfer/cod de eroare, coadă, utilizare CPU/RAM/IO.
3. Jurnale: intrări structurate despre operațiuni și erori.
4. Urme: intervale de interogare/subiect, corelație hop-to-hop.
5. Stări de sănătate: sonde sintetice, pregătire/viață, noduri ale bătăilor inimii.
6. Semnale de risc/conformitate: KYC/KYB/AML lovește, sancțiuni evenimente.

Fiecare clasă are propriul nivel de criticitate și politica de stocare/livrare.

3) Arhitectura de distribuție (de referință)

Colectoare de margini (SDK/agenți) → Ingress (HTTP/OTLP/gRPC/QUIC) → Bus (Kafka/Pulsar) → Procesoare (stream-jobs) → Storage (TSDB pentru metrică, obiect/coloană - pentru jurnale/evenimente, trasor) → Vitrine/tablouri de bord/alerte.
Multi-chirie: namespace/chiriaș-id în chei, cota individuală/limite/ACL.
Segmentarea QoS: critică (P0), importantă (P1), de fond (P2).
Ieșire: abonați (Ops/BI/Terță parte) prin abonamente la subiecte și vizualizări materializate.

4) Contracte și scheme (evenimente/metrici/trasee)

4. 1 Evenimente (simplificate, YAML)

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4. 2 Valori (OpenMetrics/OTLP)

Ecartament/contor/histogramă cu etichete stabile (cardinalitate limitată).
Identificatori: 'metric _ name {service, region, chiriaș, version, route}'.
Histograme pentru latență/dimensiuni în loc de p99 în cod.

4. 3 Trasee

Câmpurile obligatorii sunt 'trace _ id',' span _ id', 'parent _ id',' service ',' peer ',' route ',' qos '.
Legaturi intre domenii (consumator/producator) si reteaua de hamei (releu/punte).

5) QoS și prioritizarea

P0 (critic): plăți/plăți SLI, stări de punte/nod, SLO burn-rate → livrare strictă (acks, retries, idempotency), termene minime.
P1 (important): evenimente de produs/valori cheie → livrare garantată în cadrul SLO.
P2 (fundal): jurnale detaliate, depanare → cel mai bun efort, puteți scădea atunci când este supraîncărcat.

Politicieni: cozi diferite, cotă pentru producători, backpressure, rate-limite, bunicul prin „idempotency _ key”.

6) Bugetul cardinalității și al metricii

Regula 6 etichete: nu mai mult de 6 chei pe metrică, dicționare fixe de valori.
Cardinalitate ≤ 10k serii de timp/metric/chiriaș.
Prelevare de probe: cap/coadă pentru urme; downsampling 10s→1m→5m→1h metrics.
Cote: limite de puncte/sec și octeți/sec pe cort și pe clasă QoS.
Scheme linter: respinge valorile cu etichetele „explodează” (id, e-mail, ip etc.).

7) Colecta și livra: push vs trage

Push (OTLP/StatsD/HTTP): flexibilitate, clienți mobile/edge, canale P0.
Pull (Prometheus): infrastructură internă, obiective previzibile.
Hibrid: exporters→gateway→TSDB; zgârieturi federalizate pentru regiuni.
Transport: QUIC/HTTP/2, compresie, butching, TLS/mTLS, retrai cu jitter.

8) SLI/SLO și alertare

8. 1 SLI de bază

Disponibilitate% Puncte finale/Gateway-uri,

Latență p50/p95/p99 pe rute critice,

Rata de eroare (5xx/timeout/avort),

Întârzierea livrării cu autobuzul, adâncimea cozii,

Prospețimea vitrinelor (ingest→serve întârziere).

8. 2 exemple SLO

Conducte P0: Disponibilitate ≥ 99. 95%, p99 latență ≤ 400 мс, Lag de livrare p95 ≤ 2 с.
P1: Disponibilitate ≥ 99. 9%, prospeţime p95 ≤ 3 min.
P2: Prospețime p95 ≤ 15 мин, fără pagină.

8. 3 Alerte burn-rate (exemplu)

fereastră de 2 ore: 'error _ budget _ burn ≥ 2 ×' → pagină.
fereastră de 6 ore: 'error _ budget _ burn ≥ 1 ×' → pagină/escaladare.
Combinați cu 'queue _ lag' și 'drop _ rate' P0.

9) Bolți și retenții

Măsurători TSDB: frecvență înaltă - 7-14 zile; agregate - 6-12 luni

Evenimente/jurnale: depozitare la cald 7-30 zile, rece (obiect) 6-24 luni.
Trasee: prelevare de probe 1-10%; salvarea intervalelor „lent/eronat” (pe bază de coadă).
Politicile de ștergere/revizuire a cererilor PII și ale persoanelor vizate.

10) Confidențialitate, securitate și izolare

Minimizarea PII: tokenizarea/pseudonimizarea câmpurilor, interzicerea identificatorilor „bruți” în metrică.
mTLS/semnături eveniment, producător cheie pinning.
ACL/ABAC pe subiecte/servicii/chiriași, chei separate pentru scriere/citire.
Chiriaș sandboxing: separare logică/fizică, limite și rate-limită per chiriaș.
Traseu de audit: jurnale neschimbătoare de acces/modificări la configurații.

11) Procesarea fluxurilor (flux de locuri de muncă)

Îmbogățire: normalizare, geo/versiune/clasă de trafic.
Agregat: ferestre 10s/1m/5m, histograme, cantitate schițe.
Detectați: anomalii (EWMA/ESD), derivă de distribuții, explozii de cozi.
Traseu: fan-out pentru partenerii de prezentare/alertă/webhooks.
Garda: „butonul roșu” - throttling/kill-switch de sursă/subiect.

12) Tablouri de bord (machete de referință)

Ops Core (oră/timp real): latență p95, rata de eroare, întârzierea livrării, adâncimea cozii, ingerarea ratei de succes.
Conducte Sănătate: prospețime pe conductă, drop-rate, backpressure, burn-rate SLO.
Chiriaș Utilizare: rânduri/sec, octeți/sec, cardinalitate, top-etichete.
Securitate/Conformitate: statusuri mTLS, chei de expirare, accesări, revizii PII.
Lentile de afaceri: SLI-uri de conversie/plăți/bridge lângă valorile tehnice.

13) Exemple de configurare

Clase și limite QoS (YAML)

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

Etichete metrice (politică)

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

Alerte arde-rata

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14) Scheme de date și interogări

Registru metric (director)

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

Cozi și lag

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

Cardinalitatea cortului

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15) Procese și roluri

Proprietarul telemetriei - scheme/politici/cote, controlul cardinalității.
SRE/Ops - SLO, alerte, incidente, scalare.
Securitate/Conformitate - chei, accesări, PII, audituri.
Produs/BI - vitrine KPI, analize, valori A/B.
Chiriași (parteneri) - integrarea corectă a SDK, respectarea contractului.

16) Incidente Playbook

A. Explozia cardinalității

1. Auto-bloc producător/metrica, 2) taie etichetele „rău”, 3) retro-agregare, 4) post-mortem și linter reguli.

B. Creșterea cozii de lag P0

1. Includeți prioritatea, 2) extinderea părților/consumatorilor, 3) reducerea temporară a eșantionării P2, 4) analiza blocajului.

C. Căderea de prospețime Storefronts

1. Comutați la conectorul de rezervă, 2) activați modul de degradare („ultimul finalizat”), 3) notificați proprietarii sursei.

D. Scurgeri PII în valori

1. Blocare imediată a debitului, 2) redactare pe strat fierbinte, 3) DPO/notificare de conformitate, 4) actualizare lenter/SDK.

E. Erori masive 5xx/urme

1. Page, 2) prelevarea de probe pe bază de coadă ↑ pentru erori, 3) diagnosticarea critică a urmelor de traseu, 4) eliberarea rollback/caracteristică de pavilion.

17) Lista de verificare a implementării

1. Aproba contractele de evenimente/metric/trace si o lista de etichete acceptabile.
2. Creați clase QoS, subiecte/cozi, cote și buget metrici.
3. Configurați ingerarea (push/pull), TLS/mTLS, retrai și idempotency.
4. Includeți directoare metrice/evenimente și lintere schema.
5. Definiți SLI/SLO, alerte și escaladări ale ratei de inscripționare.
6. Construiți tablouri de bord Ops/Conducte/Chiriaș/Securitate.
7. Executați teste haos telemetrie (pierdere/jitter/aderențe).
8. Revizuiți în mod regulat costurile cardinalității, retenției și depozitării.

18) Glosar

QoS - calitate de livrare/clasă prioritară.
Prospețime - întârzierea apariției datelor în vitrină.
Burn-rate - rata de consum a bugetului de eroare în raport cu SLO.
Cardinalitate - numărul de rânduri unice de metrici (combinații de etichete).
Prelevarea de probe pe bază de coadă - o selecție de urme „lente/eronate”.
Cheie Idempotency - cheie pentru deduplicarea repetării evenimentelor.

Concluzie: distribuția semnalelor și a metricii nu este doar „colectarea și afișarea graficelor”, ci disciplina contractelor, canalele QoS și bugetele. Urmând acest cadru, ecosistemul câștigă observabilitate previzibilă, rezistență la supratensiuni, date private și util pentru decizii atât în conturul operațional, cât și în cel de afaceri.