Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Wzorce monitorowania

Twoje API koszyka zaczęło zwracać błędy 500 o 2 w nocy. Dashboard dyżurnego przez cały czas świecił na zielono, bo alertowałeś o CPU i pamięci, a nie o widocznym dla użytkownika współczynniku błędów. Zanim klient napisał o tym na Twitterze, straciłeś godzinę zamówień. Rozwiązaniem nie jest „więcej metryk” — to właściwe alerty, napisane szybko i przejrzane pod kątem trybów awarii, które budzą cię o 2 w nocy bez powodu.

Ten przepis jest o tym, jak użyć narzędzia AI do programowania, by zrobić dokładnie to: zamienić jednolinijkową specyfikację w reguły Prometheusa, przeprowadzić audyt istniejących alarmów CloudWatch pod kątem pułapek zmęczenia alertami oraz zbudować szkielet dashboardów i okablowania OpenTelemetry, dzięki któremu alert da się przekuć w działanie. Same koncepcje monitorowania (cztery złote sygnały, burn-rate dla SLO) to standardowa praktyka SRE — dźwignią jest to, jak szybko potrafisz je wygenerować i zweryfikować.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Wielokrotnego użytku prompt, który zamienia specyfikację złotych sygnałów w gotowy do wklejenia rules.yml dla Prometheusa
  • Prompt zamieniający cel SLO w alert wielookienkowy i wielospaleniowy (wzorzec, który budzi przy realnym spalaniu budżetu, a nie przy szumie)
  • Prompt rewizyjny, który znajduje antywzorce zmęczenia alertami w istniejących alarmach (brak for:, brak przejścia do stanu OK, histogram_quantile na metryce bez bucketów)
  • Podział na trzy narzędzia: kiedy użyć trybu agentowego Cursora, kiedy uruchomić Claude Code w trybie headless w CI, a kiedy pozwolić Codex Cloud otworzyć PR
  • Porównanie „przed i po” przy podłączeniu serwerów MCP Sentry i Grafany, by agent wnioskował na podstawie danych z bieżących incydentów, a nie zgadywał

Workflow: od specyfikacji do reguł alertów

Dział zatytułowany „Workflow: od specyfikacji do reguł alertów”

Nie pisz PromQL ręcznie z pamięci. Opisz sygnał zwykłym językiem i pozwól modelowi wygenerować regułę, a potem przeczytaj ją krytycznie. Cztery złote sygnały (opóźnienie, ruch, błędy, nasycenie) to właściwy domyślny zestaw startowy dla dowolnej usługi HTTP.

Dobra odpowiedź wygląda tak — zwróć uwagę na for: przy każdej regule oraz na wyrażenie błędów oparte na objawach, zamiast alertowania o surowych licznikach:

groups:
  - name: checkout-api-golden-signals
    rules:
      - alert: CheckoutHighLatencyP95
        expr: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket{service="checkout-api"}[5m])) by (le)
          ) > 0.5
        for: 5m
        labels: { severity: warning }
        annotations:
          summary: "p95 latency above 500ms for checkout-api"
          runbook_url: "https://runbooks.example.com/checkout-latency"


      - alert: CheckoutHighErrorRate
        expr: |
          sum(rate(http_requests_total{service="checkout-api",status=~"5.."}[5m]))
          / sum(rate(http_requests_total{service="checkout-api"}[5m])) > 0.05
        for: 5m
        labels: { severity: critical }
        annotations:
          summary: "5xx error ratio above 5% for checkout-api"
          runbook_url: "https://runbooks.example.com/checkout-errors"

Potem oceń wynik, zanim mu zaufasz. Dwa sprawdzenia wyłapują większość złych generacji: czy histogram_quantile działa na metryce _bucket z le w grupowaniu (w przeciwnym razie po cichu zwraca NaN) oraz czy każdy alert ma okno for:, tak by pojedyncze zakłócenie scrape’a nikogo nie obudziło.

Alerty burn-rate dla SLO

Dział zatytułowany „Alerty burn-rate dla SLO”

Progi CPU i opóźnienia mówią ci, że coś jest nie tak; alert burn-rate dla SLO mówi ci, że wydajesz budżet błędów szybciej, niż cię na to stać. Wzorzec wielookienkowy i wielospaleniowy (z workbooka SRE Google) odpala się tylko wtedy, gdy zgadzają się okno krótkie i długie — i to właśnie utrzymuje go w ciszy podczas przejściowych skoków.

Trzy narzędzia, trzy workflowy

Dział zatytułowany „Trzy narzędzia, trzy workflowy”

To, gdzie każde narzędzie sprawdza się najlepiej, znacząco różni się przy pracy z monitorowaniem, więc nie jest to „identycznie we wszystkich narzędziach”.

Użyj trybu agentowego do edytowania reguł alertów na miejscu. Otwórz monitoring/rules.yml, dodaj plik z regułami do kontekstu i poproś agenta o dopisanie bloku burn-rate dla SLO obok istniejących reguł dla złotych sygnałów — edytuje w miejscu, więc każdą zmianę możesz porównać z tym, co już tam jest. Checkpointy Cursora pozwalają zaakceptować regułę opóźnienia, ale wycofać hałaśliwą regułę ruchu bez utraty reszty.

Trzymaj promtool w pętli: po tym, jak agent zapisze reguły, uruchom promtool check rules monitoring/rules.yml w terminalu Cursora i wklej z powrotem błędy. Model poprawia składnię PromQL oraz kształt for:/labels: znacznie szybciej na podstawie dokładnego błędu z walidatora niż na podstawie mglistego „to wygląda źle”.

Podłączanie alertu do realnych danych: MCP i Skille

Dział zatytułowany „Podłączanie alertu do realnych danych: MCP i Skille”

Reguła jest tylko tak dobra, jak runbook za nią stojący. Dwie ścieżki rozszerzania sprawiają, że agent wnioskuje na podstawie bieżących danych o incydentach, zamiast wymyślać prawdopodobnie wyglądające progi.

Serwery MCP dają agentowi trwałe, bieżące połączenie. Z podłączonym Sentry MCP (zdalny, hostowany) możesz poprosić „draft an alert for the error spike Sentry saw on checkout-api this week”, a model pobierze faktyczny problem, jego częstotliwość i powiązany release — tak że próg odpowiada rzeczywistości. Grafana MCP pozwala mu odczytać twoje istniejące dashboardy i źródła danych przed zaproponowaniem nowych paneli, zamiast duplikować te, które już masz.

Dodaj zdalny Sentry MCP — komenda jest identyczna we wszystkich trzech narzędziach, różni się tylko miejscem, w którym ją uruchamiasz:

Dodaj do .cursor/mcp.json:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Agent Skills to lżejsza opcja, gdy nie potrzebujesz bieżącego połączenia — tylko wielokrotnego użytku wiedzy o tym, jak pisać dobrą konfigurację monitorowania. Skille instaluje się przez jedno uniwersalne CLI, które działa w Cursorze, Claude Code i Codexie:

Okno terminala
npx skills add wshobson/agents

To repozytorium dostarcza skille prometheus-configuration i grafana-dashboards (przejrzyj je na skills.sh). Kompromis jest prosty: skill to jednofunkcyjne wzmocnienie, które uczy agenta wzorca (świetne do „write idiomatic PromQL”); serwer MCP to trwałe połączenie z bieżącymi danymi (niezbędne do „what is actually firing right now”). Do tworzenia reguł od zera wystarczy skill. Do strojenia progów względem produkcji potrzebujesz MCP.

Modernizacja starszego kodu monitorowania

Dział zatytułowany „Modernizacja starszego kodu monitorowania”

Sporo kodu monitorowania w prawdziwych repozytoriach ma kilka lat i nie zadziała na aktualnych SDK. Narzędzia AI doskonale radzą sobie z mechaniczną migracją — wskaż im martwy idiom i pozwól go przepisać.

Dwie migracje pojawiają się bez przerwy. AWS SDK v2 osiągnął koniec wsparcia 8 września 2025 — globalna przestrzeń nazw AWS, new AWS.CloudWatch() oraz .promise() są wycofane i nie powinny trafiać na produkcję. A SDK metryk OpenTelemetry JS się przeniosło: @opentelemetry/metrics został porzucony na wersji 0.24.0, zastąpiony przez @opentelemetry/sdk-metrics (2.x), a MeterProvider.addMetricReader() usunięto w SDK 2.0 na rzecz przekazywania readerów przez konstruktor.

Tak powinien wyglądać zmigrowany kod — klient CloudWatch v3 oraz reader OTel przekazany przez konstruktor:

const {
  CloudWatchClient,
  PutMetricAlarmCommand,
} = require('@aws-sdk/client-cloudwatch');
const { MeterProvider, PeriodicExportingMetricReader } =
  require('@opentelemetry/sdk-metrics');
const { PrometheusExporter } =
  require('@opentelemetry/exporter-prometheus');


const cw = new CloudWatchClient({});
await cw.send(new PutMetricAlarmCommand({
  AlarmName: 'checkout-api-high-errors',
  Namespace: 'AWS/ApplicationELB',
  MetricName: 'HTTPCode_Target_5XX_Count',
  Statistic: 'Sum',
  Period: 300,
  EvaluationPeriods: 1,
  Threshold: 10,
  ComparisonOperator: 'GreaterThanThreshold',
  // OK transition matters — without it the alarm never resets
  AlarmActions: [process.env.SNS_TOPIC_ARN],
  OKActions: [process.env.SNS_TOPIC_ARN],
}));


// PrometheusExporter is a MetricReader — pass it via `readers`, not addMetricReader()
const meterProvider = new MeterProvider({
  readers: [new PrometheusExporter({ port: 9090 })],
});
const meter = meterProvider.getMeter('checkout-api');

Po każdej migracji wygenerowanej przez AI uruchom zasugerowane komendy instalacji i pozwól odpalić sprawdzaniu typów. Model od czasu do czasu zostawi nazwę opcji dostępną tylko w v2; kompilator wyłapuje je natychmiast, a podanie błędu z powrotem daje poprawkę w jednej rundzie.

Kiedy to się psuje

Dział zatytułowany „Kiedy to się psuje”

Co dalej

Dział zatytułowany „Co dalej”

Zobacz co nowego na platformie.

Polityka prywatności Regulamin