Możliwość obserwacji pobierania próbek śladowych

1) Dlaczego obserwowalność

• Metryka (kruszywa, reagować szybko);
• kłody (szczegóły i badania sądowe);
• Ślady (przekrojowe zależności przyczynowo-skutkowe);
• Profile (CPU/hałas/blokada w trybie prod).

Klucz: korelacja między sygnałami + ekonomika telemetrii (pobieranie próbek, zatrzymywanie, kompresja).

2) Mapa sygnału i zasady

2. 1 CZERWONY/ZASTOSOWANIE

RED (dla API): Szybkość (RPS), Błędy (% 5xx/4xx ważne), Czas trwania (p50/p95/p99).
USE (dla zasobów): Wykorzystanie, Nasycenie, Błędy (NIC, Procesor, dysk, kolejki).

2. 2 Produkty niezmienne

Zdefiniuj SLO (np. „p95 latency '/v1/payments” ≤ 300 ms, błędny budżet 0. 5% w ciągu 30 dni"). Wpisy powinny „krzyczeć” tylko wtedy, gdy SLO zostanie naruszone lub spalone.

2. 3 Kontekst

Wdrożenie W3C Trace Context („traceparent”, „tracestate”) i bagażu w celu bezpiecznego transferu tych/atrybutów biznesowych (np. „najemca”, „region”, brak PII).

3) Architektura obserwowalności

SDK/automatyczne oprzyrządowanie: OpenTelemetry (OTel) w usługach (HTTP/gRPC/DB/clients).
OTel Collector jako autobus: odbiór → wzbogacenie → pobieranie próbek → eksport (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Metryka: Prometheus/Mimir/VictoriaMetrics;
• Szlaki: Tempo/Jaeger/Zipkin;
• Dzienniki: Loki/ELK/Vector → S3 + deshevoye storage;
• Profile: Piroskop/Parca.
• Korelacja: wykresy serwisowe, przykłady, przejście od wykresu p99 do określonego śladu.

4) Śledzenie próbek: Strategie

4. 1 Pobieranie próbek w oparciu o głowę

Prosta i tania realizacja (w SDK/ingress).
Minusy: Może przegapić rzadkie błędy/powolne zapytania.

Kiedy: wysoki RPS, ścisłe budżety, wymagany jest przewidywalny udział (na przykład 1-5%).

4. 2 Pobieranie próbek na podstawie ogona

Decyzja jest podejmowana w Collector po zakończeniu rozpiętości.
Anomalie można zagwarantować, aby zostały wybrane: błędy, p99, konkretne routs/lokatorzy.
Minusy: buforowanie, trudniejsze i droższe.

Kiedy: „znaczące” szlaki są potrzebne za umiarkowaną cenę.

4. 3 Model połączony

Globalny głowica 1-5%, plus reguły ogona: „zawsze zapisać błędy/wolne przęsła”, „próbka 50% ruchu kanaryjskiego”, „zapisać wszystkie ślady ścieżek płatności w incydencie”.

5) Budżet na pobieranie próbek dynamicznych i telemetrii

Świadomość budżetowa: wielkość ładunku ≤ N trasy/min; w przypadku przekroczenia, podnieść progi (na przykład wybierz tylko p99. 5 +, tylko błąd).
Zasady według trasy/najemcy: ważne punkty końcowe/najemcy - z większym udziałem.
Okna adaptacyjne: wybuchy → tymczasowo zwiększyć błąd/wolny tempo.
Zmniejszenie kardynalności: normalizacja agenta użytkownika, IP/ASN, ślady stosu squasha, sekrety maski.

6) Konfiguracje (referencje)

6. 1 OpenTelemetry Collector - sampling ogona (yaml-fragment)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 Prometeusz - przykłady (fragment)

W aplikacji, rejestrując histogramy, dodaj przykłady z 'trace _ id'. W Grafanie kliknięcia na „igły” prowadzą do śladu.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki - zmniejszenie kosztów kłód

Etykiety są tylko stabilne ('service', 'na', 'region', 'route _ class').
Wysoka kardynalność (request_id, user_id) - w ładunku, ale z redakcją.
Przykładowe „udane” InfoLogs, zapisz błędy/ostrzeżenia.

6. 4 Jaeger/Tempo - retencja i wskaźnik

Szlaki surowe przechowywać przez 3-7 dni, kruszywa/symetrie dłużej.
Włącz parkiet/bloki w tanim magazynie (kompatybilne z S3), indeksy są kompaktowe.

7) Symulacja śledzenia

7. 1 Nazwy i atrybuty

"służba publiczna. nazwa „,” usługi. wersja „,” wdrożenie. środowisko ".
"http. metoda „,” http. trasa ',' http. cel „,” http. status_code', "net. peer. nazwa ".
Atrybuty biznesowe bez PII: "najemca", "region", "dostawca _ płatności", "game _ id'.

7. 2 Wydarzenia i połączenia

Zdarzenia przęsłowe: ważne punkty (początek transakcji DB, przekaźnik, otwarcie obwodu, brak pamięci podręcznej).
Linki: zaproszenia → vebkhuk/sobytiye komunikacji; przydatne do EDA i skrzynki odbiorczej/skrzynki odbiorczej.

7. 3 Instancje

Dodaj przykłady z 'trace _ id' do histogramów opóźnień/rozmiarów: nawigacja z → śladu do metryki śladu w jednym kliknięciu.

8) Metryki: co i jak

8. 1 Dane techniczne

CZERWONY na trasie/najemca/dostawca (PSP, KYC).
Мула: 'db _ connections _ in _ use', 'http _ client _ in _ flight', 'queue _ depth'.
Stabilizacja: ponowne próby, timeouts, circuit open/half-open, rate-limit hits.
Go/Java/Python czas trwania: GC wstrzymuje, hałas, punkty bezpieczeństwa, opóźnienia GIL.

8. 2 Metryka biznesowa

Rejestracja/loginy/depozyty/wnioski, konwersja, 3DS/KYC awarii, współczynnik obciążenia zwrotnego.
Ważne cechy: czas do portfela, sukces-stopa wypłaty.

8. 3 Kardynalność i przechowywanie

Histogramy z wyraźnymi wiadrami (np. „[50,100,200,300,500,1000,2000] ms”).
Unikaj znaków o wysokiej kardynalności (surowe user_id, request_id) - zabierz je do kłód/szlaków.

9) Dzienniki: normy i korelacja

Format: JSON + wymagane klucze („timestamp”, „level”, „message”, „trace _ id”, „span _ id”, „service”, „ر”).
Edycja: maska PAN, żetony, PII.

Pobieranie próbek: 100% dla 'błędu/ostrzeżenia', 5-20% dla 'informacji' na 'hałaśliwych' ścieżkach

Powiązanie ze śladami - poprzez 'trace _ id'. Łańcuchy dziennika → „pivot” do śledzenia i odwrotnie.

10) Profilowanie w sprzedaży

Włącz ciągłe profilowanie (Pyroskop/Parca) dla CPU/hałdy/alloc/blokad.
Korelacja pików p99 z gorącymi stosami; przechowywać przez 7-14 dni.

11) Informowanie o SLO/wadliwym budżecie

Wpisy SLO: „błędny budżet wydawany jest szybciej niż X %/godzinę” (ostrzeżenia prognozujące).
Objawy, nie powodują: alert do poziomu klienta (RUM/krawędź lub na trasie), a nie do procesora.
Multi-window, multi-burn rate: 2% w 1 godzinę i 5% w 6 godzin - dwa warunki.
Cisza podczas planowanej degradacji: przesunięcie progowe podczas flagi/kanarka.

12) Koszt i zatrzymanie

Kwoty objętościowe: szlaki ≤ N TB/miesiąc, kłody - gorące 3-7 dni, zimne S3 30-90 dni, mierniki - downsampling (1 min → 5 min → 1 h).
Reguły ogonowe zmniejszają objętość × 10- × 100, zachowując błędność/powolność.
Najtańsze sygnały kosztowe - mierniki; o najwyższej wartości - „poprawne” szlaki i profile.

13) Antypattery

„100% szlaki zawsze” → eksplozja kosztów, hałas i hamulce.
Logowania w darmowym formacie bez klawiszy/maskowania.
Nieskończone wskaźniki etykiet (user_id/ip/full UA).
Brak „traceparent ”/„ bagaż” - nie może być skorelowany.
Wpisy na procesorze/stercie zamiast SLO - czat „oparzenia” bez korzyści.
Pobieranie próbek „losowo 1%” bez priorytetu błędu/powolny - stracić cenne przypadki.

14) Przykłady desek rozdzielczych (szkielety)

Przegląd API: RPS, wskaźnik błędów według klasy, opóźnienie p95/p99 (przykłady są klikalne), górne trasy.
Release/Canary: porównanie starych/nowych mierników wersji, obwodów zewnętrznych, otwartych, ponownych prób.
PSP/KYC: wskaźnik sukcesu przez dostawców, opóźnienie i awaria, korelacja z błędami wypłat.
Infra: WYKORZYSTANIE według zasobów, nasycenie kolejki, krople do sieci.

15) Szczegóły dotyczące iGaming/Finance

Ścieżki krytyczne (depozyty/wnioski): 100% śledzenie tylko w przypadku incydentów lub ograniczonych okien; w trybie normalnym - ogon „wszystkie z błędem/długim opóźnieniem”.
Region/najemca: dodać „najemcę”, „jurysdykcję”, „markę” do bagażu; budować SLO według jurysdykcji.
Filtr przeciwdrgawkowy/botowy: metryka i ślady rozwiązań API ryzyka (pozwalają/zaprzeczają/wyzwanie), szybkość przechodzenia, prędkość trafień.
Audyt/zgodność: zachować minimum niezbędne, bez PII; dzienniki stałe - w oddzielnym obwodzie.

16) Lista kontrolna gotowości Prod

• Propagacja końcowa („traceparent”, „bagaż”), korelacja logarytmiczna/metryczna/śladowa.
• Kolektor OTel z próbkowaniem ogonowym (błędy/powolne/ważne przebiegi) + domyślny probabilistyczny.
• Wskaźniki RED/USE, wiadra, przykłady → przejście do śladu.
• SLO i błędny alarm budżetowy (dwie linie czasowe).
• Przepisy telemetryczne i budżet; metryki redukcyjne; chłodnia do przechowywania kłód.
• Znormalizowany dziennik JSON, redakcja PII/tajemnice.
• Profilowanie w sprzedaży włączone; deski rozdzielcze „gorących” stosów do incydentu.
• Kanarkowe deski rozdzielcze i porównanie wersji; zwolnić bez „ślepych plam”.
• Runbook: Jak tymczasowo zwiększyć udział próbkowania w incydencie.
• Dokumentacja nazw atrybutów/etykiet i hamowanie wysokiej kardynalności.

17) TL; DR

Budowanie obserwowalności wokół korelacji: RED/USE → exemplars metrics → trails → logs/profiles. Zarządzanie kosztami poprzez połączone pobieranie próbek: mała głowa% + reguły ogona (błędy, powolne, ważne trasy/najemcy). Wpisy - na temat SLO i budżetu błędów. Przechowywać retencje i kardynalność pod kontrolą, używać OTel Collector jako "centralnego układu nerwowego. "Dla dróg płatniczych/jurysdykcyjnych - priorytetowa telemetria i ścisła higiena danych.