GH GambleHub

Monitorowanie infrastruktury

Monitorowanie infrastruktury

1) Cele i ramy

Monitoring infrastruktury to system sygnałów o zdrowiu, wydajności i dostępności platformy. Musi:
  • Ostrzeżenie przed awariami użytkownika (wczesne wykrycie).
  • Podać diagnozę przyczyny korzenia (od objawów do przyczyny).
  • Wsparcie SLO gating wersji i auto-rolki.
  • Nakarm analizę po incydencie (dowody jako dane).

Zasady pomocnicze: Obserwowalny z konstrukcji, mniejszy szum - więcej sygnałów, automatyzacja reakcji, pojedynczy panel prawdy.

2) Obserwowalność triady

Timeseries - wskaźnik/popyt/błąd/nasycenie (USE/RED)

Dzienniki: szczegóły zdarzeń z kontekstem; nie zawierają żadnych tajemnic/PII.
Ślady: rozproszone przypadki z związkami przyczynowymi.

Plus:
  • Profilowanie (CPU/hałas/blokada/io), eBPF dla poziomu systemu.
  • Zdarzenia/audyt (K8s zdarzenia, zmiany konfiguracji/tajemnic).

3) SLI/SLO/SLA - język jakości

SLI: 'dostępność', 'error _ rate', 'p95 _ latency', 'queue _ lag'.

SLO (cel): "udane wnioski ≥ 99. 9% w ciągu 30 dni"

Budżet błędu: tolerancja; używane do zwolnień automatycznych.

Przykład SLO (YAML):
yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Mapa warstw monitorujących

1. Hosts/VM/węzły: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Sieć/LB/DNS: RTT, pakiety/krople, zaległości, SYN/Timeout, sondy zdrowotne.
3. Kubernetes/Orchestrator: serwer API, itcd, kontrolery, harmonogram; strąki/węzły, oczekujące/eksmitowane, dławienie, kube-events.
4. Usługi/kontenery: RED (Wskaźnik/Błędy/Czas trwania), gotowość/los.
5. Bazy danych/bufory: QPS, blokada, opóźnienie replikacji, hit bufora, powolne zapytania.
6. Kolejki/autobusy: opóźnienie konsumenckie, prośba/martwe litery, przepustowość.
7. Przechowywanie/chmura: S3/Blob błędy i opóźnienia, 429/503 od dostawców.
8. Granice granic: WAF/Rate Limits, 4xx/5xx drogą, CDN.
9. Syntetyka: kontrole skryptów HTTP (depozyt/wyjście), certyfikaty TLS/.
10. Gospodarka/pojemność: koszt za usługę, wykorzystanie, zagłówek.

5) Whitebox do Blackbox

Whitebox: eksporterzy/SDK w ramach usług (Prometheus, OpenTelemetry).
Blackbox: zewnętrzne próbki z różnych regionów (dostępność, opóźnienie, wygaśnięcie TLS).
Połączyć: „znak na zewnątrz” + „diagnoza wewnątrz”.

Przykład 'blackbox _ exporter':
yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernety: kluczowe sygnały

Кластей: 'apiserver _ request _ total', 'etcd _ server _ has _ leader', etcd fsync.
Бла: 'container _ cpu _ cfs _ throttled _ seconds _ total', 'node _ pressure'.
Poduszki: Oczekujące/CrashLoopBackOff, OOMKilled, uruchamia się ponownie.
Plany/limity: Wnioski vs Limits, Budżet PodDis , HPA/VPA.
Sieć: krople do Polityki, wyczerpanie połączenia.

Маборна: „Zdrowie klastra”, „Workload saturate”, „Top erroring services”.

7) DB i kolejki

PostgreSQL/MySQL: opóźnienie replikacji, impasy, powolne zapytanie%, punkt kontrolny I/O.
Redis/Memcached: współczynnik trafienia, eksmisje, połączenia odrzucone.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, use disk.

8) Wskaźniki RED/USE i korelacje biznesowe

RED: „szybkość” (RPS), „błędy” (4xx/5xx), „czas trwania” (p95/p99).
WYKORZYSTANIE (dla zasobów): Wykorzystanie, Nasycenie, Błędy.
Kojarzy się z produktem: depozyty/płatności sukces, oszustwa flagi, konwersja - są to „strażnicy” do wydania kanarka.

9) Struktura ostrzegawcza

Tier-1 (strona): incydenty mające wpływ na SLO (dostępność, 5xx, opóźnienie, awaria komponentu krytycznego klastra).
Tier-2 (bilet): degradacja zdolności produkcyjnych, wzrost błędów bez wpływu na SLO.
Tier-3 (informacja): tendencje, zdolność prognostyczna, wygasające certyfikaty.

Zasady eskalacji: czas ciszy/duplikat kompresji, rotacje dyżurów, follow-the-sun.

Przykład tras Alertmanagera:
yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Przykłady reguł Prometeusza

10. 1 5xx Błędy z progiem SLO

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Błąd w budżecie palącym (oparzenie w wielu oknach)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Nasycenie systemu (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Kłody: kolekcja, normalizacja, retencja

Standaryzacja: dzienniki JSON: 'ts',' level ',' service ',' trace _ id', 'user/najemca'.
Rurociąg: agent (Fluent Bit/Vector) → bufor → indeks/przechowywanie.
Wersja: Maskowanie PII/secrets na krawędzi.
Zatrzymanie: szybka klasa przechowywania (7-14 dni), chłodne archiwum (30-180 dni).
Semantyka: budżety błędów/deprecacje - oddzielne kanały.

12) Trasy i OpenTelemetry

Punkty wejściowe (brama), kliyent → wywołania serwera, DB/caches/kolejki.
Wiązanie mierników do śledzenia atrybutów (Przykłady) do szybkiej nawigacji.
Kolektor OTel jako centralna brama: filtrowanie, pobieranie próbek, eksport do wybranych backendów.

Przykład kolektora OTel (fragment):
yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Syntetyka i kontrole zewnętrzne

HTTP prowadzi scenariusze biznesowe (login, deposit, withdrawal, purchase).
TLS/Domain: nazwa certyfikatu/CAA/DNS health.
Regionalność: próbki z kluczowych krajów/dostawców (routing/listy blokowe).
Syntetyka powinna alarmować, jeśli nie jest dostępna dla użytkownika, nawet za pomocą zielonej telemetrii wewnętrznej.

14) Profilowanie i eBPF

Ciągłe profilowanie: identyfikacja gorących funkcji, blokad.
eBPF: zdarzenia systemowe (syscalls, TCP retransmitts), na produkcie z minimalnym napowietrznym.
Alerty profilowe bez napięcia (bilety), a dla regresji po zwolnieniu - jako sygnał wsteczny.

15) Deski rozdzielcze i „panel prawdy”

Minimalny zestaw:

1. Przegląd platformy: SLI/SLO według kluczowych usług, błąd-budżet, wpisy.

2. API RED: RPS/BŁĘDY/CZAS TRWANIA na trasie.

3. K8s Klaster: płaszczyzna sterowania, мла, głowica pojemnościowa.

4. DB/Cache: lag/locks/slow query%, hit ratio.

5. Kolejki: backlog/lag, fail/retry.

6. Na zwolnienie: porównanie przed/po metryki (okna kanaryjskie).

7. FinOps: koszt per namespace/service, idle/oversized рескрса.

16) Incydenty, hałas alarmowy i eskalacja

Deduplication - Service/Cause Grouping, Cascade Suppression

Milczenie/utrzymanie: zwolnienia/migracje nie powinny „malować” wszystkiego na czerwono.
Runbooks: każdy alert krytyczny z krokami diagnostycznymi i „przyciskiem”.
Postmortem: linia czasu, czego się dowiedzieli, co sygnały dodawane/czyszczone.

17) Bezpieczeństwo w monitorowaniu

RBAC do odczytu/edycji reguł/danych.
Tajemnice: Tokeny eksportera/agenta - za pośrednictwem Secret Manager.
Izolacja: mierniki klienta/najemcy - w oddzielne przestrzenie/zakładki.
Integralność: podpis agentów/budowli, konfiguracje za pośrednictwem GitOps (przegląd połączenia).

18) Finanse i moce produkcyjne (FinOps)

Kwoty i budżety; alerty do nieprawidłowego wzrostu.
Prawy rozmiar: analiza żądań/limitów, wykorzystanie procesora/pamięci RAM, instancje punktowe dla zadań innych niż krytyczne.
„Koszt na żądanie/najemca” jako KPI wydajności.

19) Anty-wzory

Mierniki infrastruktury tylko bez niestandardowych SLIs.
100 + wpisy „o wszystkim” → ślepota dyżurna.
Dzienniki jako jedyne źródło (bez mierników i śledzenia).
Mutable deski rozdzielcze bez wersioning/przegląd.
Brak syntetyki: „wszystko jest zielone”, ale przód nie jest dostępny.
Nie ma związku z wydaniami: nie można odpowiedzieć „co się zmieniło w tej chwili X”.

20) Lista kontrolna realizacji (0-60 dni)

0-15 dni

Zdefiniuj SLI/SLO dla 3-5 kluczowych usług.
Włącz podstawowych eksporterów/agentów, standaryzuj dzienniki JSON.
Skonfiguruj wpisy Tier-1 (dostępność, 5xx, p95).

16-30 dni

Dodaj syntetykę do scenariuszy krytycznych.
Włącz OTel w usługach wejściowych/krytycznych.
Tablice rozdzielcze „Per-release” i zasady oparzenia budżetu błędu.

31-60 dni

Pokrywa DB/kolejki/pamięci podręcznej z zaawansowanymi sygnałami.
Wdrożenie eBPF/profilowania dla usług wysokiej CPU.
GitOps dla reguł/desek rozdzielczych/alarmów, regularne czyszczenie hałasu.

21) Wskaźniki zapadalności

Pokrycie SLO kluczowych usług ≥ 95%.
MTTA/MTTR (cel: min/dziesiątki minut).
Odsetek wpisów w Tier-1 zamknięty przez automatyczne działanie lub szybki zwrot.
Stosunek „użytecznych „do” hałaśliwych „wpisów wynosi> 3:1.
Syntetyczne pokrycie wszystkich ścieżek „pieniądze” = 100%.

22) Aplikacje: mini-szablony

Prometeusz - Dostępność według klasy statusu

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - wskazówka dla kanarków


expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - obowiązek i cisza

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Wniosek

Monitoring nie jest zbiorem wykresów, ale systemem operacyjnym SRE: SLI/SLO jako kontrakt jakości, metryki/ścieżki/dzienniki jako źródła prawdy, wpisy jako sygnał kontrolowany, syntetyka jako „głos użytkownika”, GitOps jako dyscyplina zmian. Zbuduj pojedynczą pętlę od hosta do interfejsu API, powiązaj ją z wersjami i rolkami - a platforma jest przewidywalna, szybka i ekonomiczna.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.