Stosy do obserwacji

1) Dlaczego potrzebujesz stosu obserwacji

Szybki RCA i zmniejszenie MTTR: od objawów do przyczyn w ciągu kilku minut.
Zarządzanie SLO: pomiar błędów/opóźnień, alert przez błędny budżet.
Kontrola uwolnienia: kalkulacje kanarkowe, auto-rollback według metryki.
Bezpieczeństwo i audyt: drogi dostępu, anomalie, blokada prawna.
Przejrzystość FinOps: koszt przechowywania/żądania, cost-per-SLO.

Metody: Złote sygnały (opóźnienie/ruch/błędy/nasycenie), RED, USE.

2) Podstawowa architektura stosu

Składniki według warstwy

Kolekcja/agenci: Eksporterzy, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-sondy.
Мина/ingest: Prometheus remote_write → Mimir/Thanos, Loki dystrybutorzy/ingestery, Tempo/Jaeger ingesters.
Zapisy: S3/GCS/MinIO obiektu (długie zimno), SSD (gorące wiersze).
Zapytania/wizualizacja: Grafana (panele, widżety SLO), Kibana (jeśli ELK).
Zarządzanie: Alertmanager/Graphana alerty, katalog usług, RBAC, secret manager.

Schematy wdrażania

Zarządzane (usługi Grafana Cloud/cloud) - szybkie i droższe na woluminach.
Hosted w K8s - pełna kontrola, obsługa potrzeb i FinOps.

3) Normy dotyczące danych: jednolity „system obserwacji”

3. 1 Metryka (Prometheus/OpenMetrics)

Wymagane etykiety: "," region "," klaster "," obszar nazw "," usługa "," wersja "," najemca "(jeżeli najemca wielozadaniowy)," punkt końcowy ".
Nazywanie: 'snake _ case', suffixes '_ total', '_ seconds', '_ bytes'.
Wykresy kreskowe: stałe „wiadra” (zorientowane na SLO).
Kardynalność: nie włączaj 'user _ id',' request _ id' w etykietach.

3. 2 Dzienniki

Format: JSON; wymagane pola 'ts',' level ',' service ',' na ',' trace _ id', 'span _ id',' msg '.
PII: maskowanie agenta (PAN, żetony, e-mail itp.).
Etykiety Loki: tylko niska kardynalność („aplikacja”, „przestrzeń nazw”, „poziom”, „najemca”).

3. 3 Tory

Semantyka OTel: "serwis. nazwa „,” rozmieszczenie. środowisko „,” db. system "," http ".
Pobieranie próbek: ścieżki docelowe p99 są 'always _ on '/tail-sampling, reszta to' parent/ratio '.
Identyfikator wbudowania: flick 'trace _ id/span _ id' do dzienników i mierników (etykiety/pola).

4) Korelacja M-L-T (mierniki/kłody/ślady)

Z wykresu alarmowego (metrycznego) → filtrowane dzienniki przez 'trace _ id' → konkretny ślad.
Z śladu (powolna rozpiętość), prośba o mierniki określonego oparcia na przedziale rozpiętości jest →.
Przyciski dryldown w panelach: „do dzienników” i „do śladów” z podmianą zmienną ('$,' $ service ',' $ trace _ id').

5) OpenTelemetry Collector: Reference Pipeline

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) Ostrzeganie: SLO i wielopalnikowe

Pomysł: alertim nie jest na poziomie „CPU> 80%”, ale na zużycie budżetu na błędy.

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) Deski rozdzielcze: struktura folderu

00_Overview - platforma: SLO, p95, 5xx%, pojemność, aktywne incydenty.
10_Services - według usług: RPS, p95/p99, błędy, wydania (adnotacje).
20_Infra - K8s/nodes/story/network, etcd, sterowniki.
30_DB/Queues - PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, zasady WAF.
50_Synthetic - skryptów uptime i bez głowy.
60_Cost/FinOps - Przechowywanie, Zapytanie, Hot/Cold, Prognoza.

Każdy panel: opis, jednostki, właściciel, runbook link, wiercenie.

8) Dzienniki: warsztat 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) Utwory: TraceQL i sztuczki

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

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

10) Syntetyka i czas pracy

Blackbox-exporter: próbki HTTP/TCP/TLS/DNS z ≥ 3 regionów/ASN.
Bez głowy: login/deposit zaplanowane skrypty.
Ostrzeżenia kworum: uruchomione, jeśli regionalne ≥ 2 widzą awarię.
Strona stanu: automatyczne aktualizacje + komentarze ręczne.

11) Przechowywanie i przechowywanie

Metryki: hot 7-30 dni (szybkie rzędy), zasady downsampling/recording, cold - obiekt storage (miesiące).
Dzienniki: gorące przez 3-7 dni, a następnie S3/GCS z indeksem (Loki chunk store/ELK ILM).
Ślady: 3-7 dni „always _ on” + długoterminowe przechowywanie próbek (próbki ogonowe/odrzucone).

• Przewrócenie w rozmiarze i czasie; budżet na wnioski (kontyngenty/limity).
• Odrębne zasady dotyczące danych prod/etap i bezpieczeństwa.

12) Wielozadaniowość i dostęp

Oddzielne przez 'lokator '/' obszar nazw '/Spacje, wzory indeksów i rozdzielczości.
Tag resources for billing: 'najemca', 'service', 'team'.
Importowanie desek rozdzielczych/alarmów - w pomieszczeniach określonych zespołów.

13) Bezpieczeństwo i zgodność

TLS/mTLS od agentów do backendów, HMAC dla prywatnego zdrowia.
RBAC do odczytu/zapisu, audytu wszystkich żądań i wpisów.
Wydanie PII na krawędzi; zakaz tajemnic w dziennikach; DSAR/Legal Hold.
Izolacja: oddzielne klastry/nimfy dla wrażliwych domen.

14) FinOps: koszt obserwacji

Zmniejszamy kardynalność etykiet i logikę w połknięciu (a nie w żądaniach).
Pobieranie próbek ścieżki + zawsze włączanie celu dla ścieżek krytycznych.
Zasady obniżania/rejestrowania ciężkich agregacji.
Archiwizowanie rzadkiego dostępu do zimnego obiektu.
Метрика: 'storage _ cost _ gb _ day', 'query _ cost _ hour', 'cost _ per _ rps', 'cost _ per _ 9'.

15) testy CI/CD i obserwowalności

Metryka/kłody łączące w CI: zakaz „eksplozji” kardynalności, weryfikacja histogramów/jednostek.
Obserwowalność testów kontraktowych: wymagane pola metryki/dziennika, 'trace _ id' w oprogramowaniu pośredniczącym.
Canary: adnotacje wydań na wykresach, SLO-auto-rollback.

16) Przykłady: szybkie zapytania

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)

Od logów do utworów (Loki → Tempo): pass 'trace _ id' jako link do Tempo UI/deski rozdzielczej.

17) Jakość stosu: lista kontrolna

• Uzgodnione schematy i jednostki metryczne/dzienniki/śladowe.
• "trace _ id' w logach i miernikach, wiercenie z paneli.
• Wielopalnikowe wpisy SLO bez klapowania (kworum/multi-window).
• Downsampling, kwoty wniosków, limity etapu/zakresu.
• Klasy przechowywania i przechowywania są udokumentowane i stosowane.
• Przegląd RBAC/Audit/PII włącznie.
• Deski rozdzielcze: właściciel, zakładki, ≤ 2 -3 ekrany, szybka odpowiedź.
• Deska rozdzielcza FinOps (woluminy, koszty, czołowi rozmówcy).

18) Plan realizacji (3 iteracje)

1. MVP (2 tygodnie): Prometeusz → Mimir, Loki, Tempo; Kolektor OTel; podstawowe deski rozdzielcze i wpisy SLO; próbki blackbox.
2. Skala (3-4 tygodnie): pobieranie próbek ogonowych, obniżanie temperatury, spożywanie w wielu regionach, RBAC/spacje, deski rozdzielcze FinOps.
3. Pro (4 + tygodnie): auto-rollback na SLO, bezgłowa syntetyka kluczowych ścieżek, Legal Hold, Portfolio SLO i sprawozdawczości.

19) Anty-wzory

„Piękna grafika bez SLO” - brak działania → brak korzyści.
Etykiety o wysokiej kardynalności ('user _ id',' request _ id') - eksplozja pamięci i kosztów.
Dzienniki bez JSON i bez 'trace _ id' - brak korelacji.
Alerty zasobów zamiast objawów - hałas i dyżury wypalenia.
Brak polityki zatrzymywania - niekontrolowany wzrost kosztów.

20) Mini-FAQ

Co wybrać: Loki lub ELK?
ELK dla złożonych wyszukiwań/aspektów; Loki jest tańsze i szybsze dla scenariuszy grep-jak. Często stosuje się hybrydę.

Czy każdy potrzebuje śladów?
Tak, przynajmniej na ścieżkach kluczowych (logowanie, realizacja transakcji, płatności) z próbkowaniem ogona - to dramatycznie przyspiesza RCA.

Jak zacząć od zera?
OTel Collector → Mimir/Loki/Tempo → podstawowe próbki SLO i blackbox → następnie deski rozdzielcze i spalić wpisy.

Razem

Stos obserwowalności nie jest zbiorem rozbieżnych narzędzi, ale spójnym systemem: jednolite standardy danych → korelacja M-L-T → SLO alert i syntetyka → bezpieczeństwo i FinOp. Przechwytuj schematy, dyscyplinę i retencję etykiet, podłącz OTel, dodaj dryldown i auto-rollback - i uzyskasz niezawodność zarządzania za zrozumiały koszt.