Dystrybucja sygnałów i mierników

(Sekcja: Ekosystem i sieć)

1) Cel i obszar

• Jednolity język telemetrii i umowy o dane.
• Zarządzane kanały QoS: priorytet sygnałów krytycznych.
• Przejrzyste SLI/SLO i przewidywalne ostrzeganie.
• Prywatność, izolacja i wskaźniki oszczędności budżetowych.

2) Taksonomia sygnału

1. Wydarzenia biznesowe: wejście na pokład, wpłaty/płatności, imprezy gier, przypisanie.
2. Parametry techniczne: kod opóźnienia/przepustowości/błędu, kolejka, użycie procesora/pamięci RAM/IO.
3. Dzienniki: ustrukturyzowane wpisy dotyczące operacji i błędów.
4. Ślady: zakres zapytania/tematu, korelacja hop-to-hop.
5. Statusy zdrowotne: sondy syntetyczne, gotowość/pobudzenie, węzły bicia serca.
6. Sygnały o ryzyku/zgodności: KYC/KYB/AML, wydarzenia sanacyjne.

Każda klasa ma własny poziom krytyki i zasady przechowywania/dostarczania.

3) Architektura dystrybucji (odniesienie)

Kolektory krawędzi (SDK/agenci) → Ingress (HTTP/OTLP/gRPC/QUIC) → Autobus (Kafka/Pulsar) → Procesory (stream-jobs) → Przechowywanie (TSDB dla mierników, obiektów/kolumn - do logów/wydarzenia, znacznik) → Prezentacje/deski rozdzielcze/wpisy.
Wielopoziomowość: przestrzeń nazw/lokator-id w klawiszach, indywidualny kontyngent/limity/ACL.
Segmentacja QoS: krytyczna (P0), ważna (P1), tło (P2).
Egress: abonenci (Ops/BI/Third-party) poprzez subskrypcje tematów i zmaterializowane poglądy.

4) Umowy i programy (wydarzenia/mierniki/ścieżki)

4. 1 Wydarzenia (uproszczone, 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 mierniki (OpenMetrics/OTLP)

Skrajnia/licznik/histogram ze stabilnymi etykietami (ograniczona kardynalność).
Identyfikatory: 'metric _ name {service, region, najemca, wersja, route}'.
Histogramy dla opóźnień/wymiarów zamiast p99 w kodzie.

4. 3 Szlaki

Wymagane pola to 'trace _ id',' span _ id', 'parent _ id',' service ',' peer ',' route ',' qos '.
Powiązania między domenami (konsumenci/producenci) a chmielem sieciowym (przekaźnik/most).

5) QoS i ustalanie priorytetów

P0 (krytyczne): płatności/płatności SLI, statusy mostów/węzłów, prędkość spalania SLO → ścisła dostawa (akki, ponowne próby, idempotencja), minimalne czasy.
P1 (ważne): wydarzenia produktu/kluczowe wskaźniki → gwarantowana dostawa w ramach SLO.
P2 (tło): szczegółowe dzienniki, debugowanie → najlepszy wysiłek, można upuścić po przeciążeniu.

Politycy: różne kolejki, kwota dla producentów, ciśnienie zwrotne, limity stawek, dziadek przez „idempotency _ key”.

6) Kardynalność i budżet metryczny

Reguła 6 etykiet: nie więcej niż 6 klawiszy na metrykę, stałe słowniki wartości.
Kardynalność ≤ 10k seria czasowa/metryczna/najemca.
Pobieranie próbek: na podstawie głowy/ogona dla śladów; downsampling 10s → 1m → 5m → 1h metryki.
Kwoty: limity punktów/s i bajtów/s na namiot i na klasę QoS.
Schematy Lintera: odrzuca mierniki z „eksplodującymi” etykietami (id, e-mail, ip, itp.).

7) Zbieraj i dostarczaj: push vs pull

Push (OTLP/StatsD/HTTP): elastyczność, klienci mobilni/krawędzie, kanały P0.
Pull (Prometeusz): infrastruktura wewnętrzna, przewidywalne cele.
Hybryda: eksporterzy → brama → TSDB; sfederowane skrawki dla regionów.
Transport: QUIC/HTTP/2, kompresja, masowanie, TLS/mTLS, retrai z jitter.

8) SLI/SLO i ostrzeganie

8. 1 Podstawowe SLIs

Dostępność% Punkty końcowe/Bramy,

Latency p50/p95/p99 na trasach krytycznych,

Błąd (5xx/timeout/abort),

Opóźnienie dostawy autobusem, głębokość kolejki,

Świeżość okien sklepowych (spożycie → służyć opóźnienie).

8. 2 przykłady SLO

Rurociągi P0: Dostępność ≥ 99. 95%, p99 latency ≤ 400 м, Delivery lag p95 ≤ 2 μ.
P1: Dostępność ≥ 99. 9%, świeżość p95 ≤ 3 min.
P2: Świeżość p95 ≤ 15 мий, bez strony.

8. 3 Wpisy o szybkości spalania (przykład)

2-godzinne okno: 'error _ budget _ burn ≥ 2 ×' → strona.
6-godzinne okno: 'error _ budget _ burn ≥ 1 ×' → strona/eskalacja.
Połączyć z 'queue _ lag' i 'drop _ rate' P0.

9) Sklepienia i retencje

Metryka TSDB: wysoka częstotliwość - 7-14 dni; kruszywa - 6-12 miesięcy

Zdarzenia/dzienniki: hot storage 7-30 dni, zimno (obiekt) 6-24 miesięcy.
Ślady: pobieranie próbek 1-10%; zapisywanie „wolnych/błędnych” przęseł (oparty na ogonie).
Polityka usuwania/rewizji PII i wniosków osób, których dane dotyczą.

10) Prywatność, bezpieczeństwo i izolacja

Minimalizacja PII: tokenizacja/pseudonimizacja pól, zakaz „surowych” identyfikatorów w metrykach.
Podpisy mTLS/event, spinanie klucza producenta.
ACL/ABAC na tematy/usługi/najemcy, oddzielne klucze do pisania/czytania.
Piaskowanie najemcy: logiczne/fizyczne rozdzielenie, limity i ograniczenie stawki na najemcę.
Ścieżka audytu: niezmienne dzienniki dostępu/zmiany konfiguracji.

11) Przetwarzanie strumieni (praca strumieniowa)

Wzbogacenie: normalizacja, klasa geo/wersja/ruch.
Kruszywo: okna 10s/1m/5m, histogramy, szkice ilościowe.
Wykryć: anomalie (EWMA/ESD), dryf dystrybucji, wybuchy kolejek.
Trasa: fan-out do zaprezentowania/alert/webhooks partners.
Guard: „czerwony przycisk” - throttling/kill-switch według źródła/tematu.

12) Deski rozdzielcze (układ odniesienia)

Ops Core (godzina/czas rzeczywisty): opóźnienie p95, szybkość błędów, opóźnienie dostawy, głębokość kolejki, szybkość przyjmowania sukcesu.
Rurociągi Zdrowie: świeżość na rurociągu, szybkość spadku, ciśnienie wsteczne, szybkość spalania SLO.
Najemca Użycie: wiersze/sec, bajty/sec, kardynalność, top-labels.
Bezpieczeństwo/Zgodność: statusy mTLS, klucze wygaśnięcia, dostęp, wersje PII.
Obiektywy biznesowe: konwersja/wypłaty/mostek SLIs obok mierników technicznych.

13) Przykłady konfiguracji

Klasy i limity 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

Etykiety metryczne (polityka)

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

Wskaźnik spalania wpisów

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) Schematy danych i zapytania

Rejestr metryczny (katalog)

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

Kolejki i opóźnienia

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;

Kardynalność namiotu

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) Procesy i role

Właściciel telemetrii - programy/polityki/kwoty, kontrola kardynalności.
SRE/Ops - SLO, wpisy, incydenty, skalowanie.
Bezpieczeństwo/Zgodność - klucze, dostęp, PII, audyty.
Produkt/BI - prezentacje KPI, analityka, mierniki A/B.
Najemcy (partnerzy) - poprawna integracja SDK, zgodność z umową.

16) Incydenty Playbook

A. Wybuch kardynalności

1. Auto-blok producent/mierniki, 2) odciąć „złe” etykiety, 3) retro-agregacja, 4) pośmiertne i linter zasady.

B. Wzrost opóźnienia kolejki P0

1. Uwzględnienie priorytetu, 2) rozszerzenie partii/konsumentów, 3) tymczasowe ograniczenie pobierania próbek P2, 4) analiza wąskich gardeł.

C. Upadek świeżości sklepów

1. Przełączyć do złącza zapasowego, 2) włączyć tryb degradacji („ostatni finalizowany”), 3) powiadomić właścicieli źródła.

D. Wyciek PII w metrykach

1. Natychmiastowe blokowanie przepływu, 2) redakcja na gorącej warstwie, 3) zgłoszenie DPO/zgodność, 4) aktualizacja transmisji/SDK.

E. Ogromne błędy 5xx/śladowe

1. Strona, 2) pobieranie próbek na podstawie ogona na błędy, 3) krytyczna diagnostyka śladu trasy, 4) zwolnienie flagi rollback/feature.

17) Lista kontrolna wdrażania

1. Zatwierdzenie umów dotyczących zdarzeń/metrycznych/śladowych oraz wykaz dopuszczalnych etykiet.
2. Tworzenie klas QoS, tematów/kolejek, kwot i budżetu metrycznego.
3. Skonfiguruj połknięcie (push/pull), TLS/mTLS, retrai i idempotencja.
4. Zawiera katalogi mierników/zdarzeń i linterów schematów.
5. Zdefiniuj SLI/SLO, alerty spalania i eskalacje.
6. Budowa desek rozdzielczych Operacje/Rurociągi/Najemca/Bezpieczeństwo.
7. Uruchom testy chaosu telemetrycznego (utrata/jitter/przyczepność).
8. Regularnie zmieniaj koszty kardynalności, zatrzymywania i przechowywania.

18) Słownik

QoS - jakość dostawy/klasa priorytetowa.
Świeżość - opóźnienie w pojawieniu się danych w prezentacji.
Wskaźnik spalania - wskaźnik zużycia w budżecie błędu w stosunku do SLO.
Kardynalność - liczba unikalnych rzędów metryk (kombinacje etykiet).
Pobieranie próbek na podstawie ogona - wybór „powolnych/błędnych” śladów.
Klucz idempotencji - klucz do deduplikacji powtarzania zdarzeń.

Bottom line: dystrybucja sygnałów i metryk to nie tylko „zbieranie i pokazywanie wykresów”, ale dyscyplina kontraktów, kanałów QoS i budżetów. Stosując się do tych ram, ekosystem zyskuje przewidywalną obserwowalność, odporność na gwałtowne zmiany, dane prywatne i przydatne do podejmowania decyzji zarówno w kontekście operacyjnym, jak i biznesowym.