Baza pytań rekrutacyjnych i wiedzy. Filtruj, szukaj i sprawdzaj swoją wiedzę.
Logi pokazują pojedyncze zdarzenia i kontekst, metryki pokazują trendy w czasie, a trace śledzą żądanie end-to-end między usługami. Logi są do detali, metryki do zdrowia i alertów, a trace do latencji i zależności.
SLI (Service Level Indicator) to mierzalny sygnał zdrowia usługi, np. latencja, error rate lub dostępność. Definiuje się go w oparciu o doświadczenie użytkownika, z jasnym oknem pomiaru i progami.
Alertuj na symptomy widoczne dla użytkownika powiązane z SLO, używaj multi-window burn-rate, a każdy alert musi mieć właściciela i runbook. Deduplikuj i kieruj alerty do właściwego zespołu.
Distributed tracing śledzi żądanie między usługami za pomocą trace/span ID. Kontekst propaguje się w nagłówkach (np. W3C traceparent) lub metadanych wiadomości, aby każda usługa dopinała span do tego samego trace.
Wysoka kardynalność etykiet (np. userId) mnoży serie metryk. Unikaj ich w metrykach, agreguj/bucketuj, a detale per encja przenieś do logów lub trace.
Sampling zachowuje tylko część trace’ów, aby kontrolować koszt. Zmniejsza storage i narzut, ale może ukrywać rzadkie błędy, więc strategia ma znaczenie.
Zacznij od metryk, by potwierdzić zakres (p95/p99, endpointy, regiony), potem użyj trace do znalezienia wolnych spanów i logów do szczegółów błędów lub zapytań. Porównaj ostatnie deploye i zmiany konfiguracji.
Minimum to RED (rate, errors, duration), saturation (CPU/pamięć), zdrowie zależności i burn-rate SLO. Dodaj przekroje po trasach, regionach i wersjach.
MTTR (Mean Time To Recovery) mierzy, jak szybko przywracasz usługę po incydencie. Poprawa to lepsza detekcja, runbooki, szybkie rollbacki i wyćwiczony incident response.
RED (Rate, Errors, Duration) jest najlepsze dla usług requestowych. USE (Utilization, Saturation, Errors) pasuje do zasobów jak CPU, dysk czy kolejki. Razem pokazują zdrowie usługi i bottlenecki zasobów.