Centralizacja kłód

1) Dlaczego centralizacja dzienników

• przyspieszenie poszukiwania korzeni incydentów (korelacja przez id/trace-id żądania);
• pozwalają budować alerty sygnałowe na objawach (błędy, anomalie);
• podać ścieżkę audytu (kto/kiedy/co to zrobił);
• niższe koszty związane z ujednoliceniem zatrzymywania i składowania.

2) Podstawowe zasady

1. Tylko ustrukturyzowane dzienniki (JSON/RFC5424) - bez kluczy nie ma „wolnego tekstu”.
2. Jednolity schemat kluczy: „ts, level, service, na przykład, region, najemca, trace_id, span_id, request_id, user_id (maskowany), msg, kv...”.
3. Domyślna korelacja: flip trace_id od bramy do backendów i dzienników.
4. Minimalizacja hałasu: prawidłowe poziomy, pobieranie próbek, powtarzanie deduplikacji.
5. Bezpieczeństwo według projektu: maskowanie PII, RBAC/ABAC, odporność.
6. Gospodarka: gorąca/ciepła/zimna, kompresja, agregacja, TTL i nawadnianie.

3) Typowe architektury

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka - окo.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Uniwersalne wyszukiwanie i agregacja.
Loki-like (log indexing by labels): Promtail/Fluent Bit → Loki → Grafana. Tańsze dla dużych woluminów, potężny filtr etykiet + oglądanie liniowe.
Chmura: CloudWatch/Cloud Logging/Log Analytics + eksport do chłodni (S3/GCS/ADLS) i/lub SIEM.
Dane Jezioro podejście: spedytorzy → przechowywanie obiektów (parkiet/góra lodowa) → tanie zapytania analityczne (Atena/Zapytanie/Iskra) + warstwa online (OpenSearch/Loki) przez ostatnie dni N.

Zalecenie: utrzymać warstwę online (7-14 dni na gorąco) i archiwum (miesiące/lata) w jeziorze z możliwością nawodnienia.

4) Schemat i format dzienników (zalecenie)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Standardy: RFC3339 na czas, poziom z zestawu „TRACE/DEBUG/INFO/WARN/ERROR/FATAL”, klucze w snake_case.

5) Poziomy pozyskiwania drewna i pobieranie próbek

DEBUG - tylko w dev/etapie; w prod flagą i z TTL.
INFO - cykl życiowy wniosków/wydarzeń.
OSTRZEŻENIE - podejrzane sytuacje bez wpływu na SLO.
BŁĄD/ŚMIERTELNY - Wpływ na żądanie/użytkownika.

• limit szybkości dla powtarzających się błędów (na przykład 1/sek/klucz).
• pobieranie próbek śladowych (pozostawić pełne kłody/ślady tylko w przypadku „złych” wniosków).
• dynamiczny: w przypadku burzy błędów, zmniejszyć szczegóły, zapisać podsumowanie.

6) Dostawa kłód (agentów i spedytorów)

Na węźle: Fluent Bit/Filebeat/Promtail zbierać pliki stdout/juntrals, parsing, maskowanie, buforowanie.
Kolejki sieciowe: Kafka/NATS do wygładzania szczytowego, przekładania i zamawiania.
Niezawodność: backpressure, bufory dyskowe, potwierdzenia dostawy (co najmniej raz), indeksy idempotentne (hash-key).
Filtrowanie na krawędzi: wyrzucanie „pogawędki” i tajemnic przed uderzeniem w sieć.

7) Indeksowanie i przechowywanie

Podział czasu (dziennie/co tydzień) + przez ', „, region/lokator” (poprzez szablony indeksów lub etykiety).

• Hot (SSD, 3-14 dni): szybkie wyszukiwanie i wpisy.
• Ciepło (HDD/zamrażarka, 30-90 dni): czasami wyglądamy.
• Cold/Archive (obiekt, miesiące/lata): zgodność i rzadkie badania.
• Kompresja i rotacja: ILM/ISM (zasady cyklu życia), gzip/zstd, downsampling (tabele agregacji).
• Nawodnienie: tymczasowe załadowanie archiwalnych partii do „gorącego” klastra do badania.

8) Wyszukiwanie i analityka: Przykładowe zapytania

Incydent: filtr czasowy × 'service =...' × 'level> = ERROR' × 'trace _ id'/' request _ id'.
Dostawcy: kod: PSP _' i 'kv. dostawca: psp-a 'pogrupowany według regionu.
Anomalie: zwiększenie częstotliwości wiadomości lub zmiana rozkładu pola (detektory ML, reguły).
Audyt: „kategoria: audyt” + „podmiot ”/„ zasób” + wynik.

9) Korelacja z metrykami i śladami

Identyczne identyfikatory: 'trace _ id/span _ id' we wszystkich trzech sygnałach (mierniki, dzienniki, ślady).
Linki z wykresów: klikalne przejście z panelu p99 do dzienników przez 'trace _ id'.
Adnotacje wydania: wersje/kanary w metrykach i dziennikach do szybkiego wiązania.

10) Bezpieczeństwo, PII i zgodność

Klasyfikacja pola: PII/tajemnice/finanse - maska lub usunięcie przy wejściu (filtry Fluent Bit/Lua, Re2).
RBAC/ABAC: index/label access by role, row-/field-level-security.
Niezmienność (tylko WORM/dodatek) w zakresie wymogów audytu i regulacji.
Retencja i „prawo do zapomnienia”: TTL/deletion by keys, tokenization 'user _ id'.
Podpisy/hashes: integralność czasopism krytycznych (działania administratora, płatności).

11) mierniki SLO i logarytmu rurociągu

Dostawa: 99. 9% zdarzeń w warstwie gorącej ≤ 30-60 sekund.
Straty: <0. 01% w ciągu 24 godzin (zgodnie ze znakami referencyjnymi).
Dostępność wyszukiwania: ≥ 99. 9% w ciągu 28 dni.
Opóźnienie żądań: p95 ≤ 2-5 sekund na typowych filtrach.
Koszt: $/1M zdarzeń i $/storage/GB w warstwach.

12) Deski rozdzielcze (minimum)

Zdrowie rurociągu: wejście/wyjście spedytorów, przekładki, bufory napełniające, Kafka opóźnienie.
Błędy według usług/kodów: top N, trendy, percentyle 'latency _ ms'.
Aktywność audytu: działania administratora, błędy dostawcy, dostęp.
Ekonomia: wolumen/dzień, indeks-wzrost, wartość według warstwy, „drogie” zapytania.

13) Operacje i playbooks

Burza dziennika: włączyć agresywne próbkowanie/limit szybkości na agencie, podnieść bufory, tymczasowo przenieść część strumienia do ciepłego.
Schemat dryfu: alert dla pojawienia się nowych klawiszy/typów, rozpocząć negocjacje schemat-katalog.
Powolne wyszukiwanie: odbudowa indeksów, zwiększenie replik, analiza „ciężkich” zapytań, archiwizacja starych partii.
Incydent bezpieczeństwa: Natychmiastowa niezmienność włączona, artefakty wyładowane, dostęp ograniczony przez rolę, RCA.

14) FinOps: jak nie pęknąć na dziennikach

Usuń werbalność: zmień stacktrace multi-line w pole 'stack' i powtórki próbki.
Włącz TTL: różni się w odniesieniu do 'na '/' poziomie '/' kategorii'.
Użyj Loki/archive + rehydratate na żądanie dla rzadkiego dostępu.
Partie i kompresja: Większe partie są tańsze, ale miej oko na wyszukiwanie SLA.
Urzeczywistnić częste oceny (agregaty dzienne).

15) Przykłady instrumentalne

Płynny bit (maskowanie i wysyłanie do OpenSearch)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Dziennik dostępu Nginx (Nginx access log) - trace_id JSON

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

OpenSearch Zasady ILM (gorące → ciepłe → usunąć)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Lista kontrolna wdrażania

• Akceptowany układ pól i poziomy dziennika; jest włączona korelacja trace/request-id.
• Skonfigurowane agenty (Fluent Bit/Promtail) z maskowaniem i buforami.
• Wybrano warstwę online (OpenSearch/Loki/Cloud) i archiwum (S3/GCS + parkiet).
• Polityka ILM/ISM + polityka gorącej/ciepłej/chłodnej retencji, proces nawadniania.
• RBAC/ABAC, możliwość audytu, dziennik dostępu.
• Deski rozdzielcze rurociągu, bufory strat/opóźnienia/dysków.
• Playbooks: storm log, schemat drift, slow search, security incident.
• Limity finansowe: zdarzenia $/1M, kwoty na „drogie” wnioski.

17) Anty-wzory

Dzienniki tekstowe bez struktury → niemożność filtrowania i agregowania.
Gigantyczny stacktrace w INFO → eksplozja objętości.
Brak korelacji → „trzepotanie” dla wszystkich usług.
Przechowywanie „wszystko na zawsze” → rachunek za chmurę jak samolot.
Sekrety/PII w dziennikach → ryzyko zgodności.
Ręczna edycja indeksu w sprzedaży → drift i długie przestoje wyszukiwania.

18) Najważniejsze

Centralizacja dziennika to system, a nie tylko stos. Znormalizowany schemat, korelacja, bezpieczne spedytorów, warstwowe przechowywanie i ścisłe zasady dostępu przekształcić dzienniki w potężne narzędzie dla SRE, bezpieczeństwo, i produkt. Prawidłowe retencje i FinOps utrzymują budżet, a rurociągi SLO i playbooks sprawiają, że dochodzenia są szybkie i powtarzalne.