Inteligentny monitoring z wykrywaniem anomalii: jak...

Inteligentny monitoring z wykrywaniem anomalii nie jest już domeną wyłącznie największych firm. Dzięki gotowym komponentom open source i kilku praktycznym wzorcom możesz w mniej niż godzinę wystartować z produkcyjnym proof‑of‑concept, który wykrywa nienormalne wzorce w metrykach, automatycznie ostrzega i pozwala szybciej diagnozować problemy.

Ten przewodnik to praktyczna odpowiedź na pytanie, jak skonfigurować monitoring z detekcją anomalii uczeniem w 60 minut. Skupiamy się na realnym wdrożeniu: od architektury i doboru algorytmów, przez komendy do uruchomienia, aż po ograniczanie false positive i integracje z Twoim ekosystemem DevOps.

Dlaczego inteligentny monitoring ma znaczenie

Klasyczne progi statyczne (np. CPU > 80%) działają, dopóki środowisko jest przewidywalne. W praktyce obciążenie zmienia się w cyklach dobowych, tygodniowych, pod wpływem kampanii czy wdrożeń. Detekcja anomalii oparta na uczeniu maszynowym potrafi wyłapać odchylenia od typowego wzorca, nawet gdy średnia wygląda „zdrowo”. Efekt: mniej szumu, szybsza reakcja i lepsza stabilność SLO.

Co rozumiemy przez „anomalię”

Anomalia to punkt lub sekwencja danych, która nie pasuje do wyuczonego rozkładu. Może to być skok latency, spadek throughputu, dryf pamięci, nietypowe wzorce I/O czy raptem większa liczba błędów 5xx. Systemy inteligentnego monitoringu wykorzystują:

Modele statystyczne (Z‑score, IQR, STL/seasonal decomposition) — lekkie, szybkie, świetne na start.
Modele ML nienadzorowane (Isolation Forest, LOF, One‑Class SVM, Autoencoders) — elastyczne, często lepsze przy złożonych wzorcach.
Prognozowanie (ARIMA, Prophet) — wykrywanie odchyleń od prognozy.

W tym przewodniku użyjemy Isolation Forest do wykrywania nietypowych wartości w krótkim oknie czasowym: prosto, lekko i skutecznie na POC.

Architektura referencyjna: prosto, rozsądnie i do uruchomienia w 1h

Żeby pokazać jak skonfigurować monitoring z detekcją anomalii uczeniem w 60 minut, zbudujemy lekki stos:

Prometheus — zbieranie metryk (scraping), query API.
Node Exporter — źródło metryk systemowych na start (CPU, RAM, dysk).
Grafana — wizualizacja, dashboardy, adnotacje.
Alertmanager — kanały powiadomień (Slack/Email/Webhook).
Anomaly Service (Python) — mikroserwis ML, który pobiera szereg czasowy, wykrywa anomalie i publikuje alerty.

To wystarcza do sensownego POC, łatwo rozbudowywalnego o OpenTelemetry, Loki/Tempo, APM czy strumienie (Kafka/Redpanda), jeśli będziesz potrzebować.

Wymagania wstępne

Host z Docker i Docker Compose (Linux/Mac/WSL).
Python 3.10+ do lokalnego rozwoju i budowy obrazu usługi ML.
Porty wolne: 3000 (Grafana), 9090 (Prometheus), 9093 (Alertmanager), 9100 (Node Exporter), 8000 (Anomaly Service).
Opcjonalnie: webhook Slack/Teams do powiadomień.

Plan 60‑minutowy: od zera do działającego POC

Poniżej dokładne kroki, by jak skonfigurować monitoring z detekcją anomalii uczeniem w ciągu jednej godziny. Każdy blok zawiera komendy i pliki konfiguracyjne.

Minuty 0–5: Inicjalizacja projektu

Utwórz katalog, repozytorium Git i strukturę plików.

mkdir smart-monitoring-ml && cd smart-monitoring-ml
mkdir -p prometheus grafana alertmanager anomaly-service
git init

Minuty 5–15: Docker Compose z Prometheusem, Grafaną i Node Exporterem

Stwórz plik docker-compose.yml.

version: "3.9"
services:
  prometheus:
    image: prom/prometheus:latest
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports:
      - "9093:9093"

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"

  grafana:
    image: grafana/grafana-oss:latest
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

  anomaly-service:
    build: ./anomaly-service
    environment:
      - PROM_URL=http://prometheus:9090
      - ALERTMANAGER_URL=http://alertmanager:9093
      - POLL_INTERVAL=60
      - METRIC_EXPR=100 - (avg by(instance)(irate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)
      - WINDOW_MINUTES=60
      - CONTAMINATION=0.03
      - SEVERITY=warning
    ports:
      - "8000:8000"
    depends_on:
      - prometheus
      - alertmanager

Prometheus – minimalna konfiguracja do scrapingu Node Exportera (prometheus/prometheus.yml):

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["node-exporter:9100"]

Alertmanager – domyślne reguły, na początek wyślemy alerty na konsolę (alertmanager/alertmanager.yml):

route:
  receiver: "dev-null"
receivers:
  - name: "dev-null"

Uruchom stos:

docker compose up -d --build

Wejdź na http://localhost:9090 (Prometheus) i http://localhost:3000 (Grafana; login admin/admin).

Minuty 15–25: Usługa ML do detekcji anomalii

Stworzymy prostą usługę w Pythonie (FastAPI) z Isolation Forest. Będzie co minutę pobierać okno danych z Prometheusa, wyliczać anomalię i – jeśli wystąpi – wysyłać alert do Alertmanagera.

Plik anomaly-service/Dockerfile:

FROM python:3.11-slim
WORKDIR /app
RUN pip install --no-cache-dir fastapi uvicorn[standard] requests numpy scikit-learn
COPY app.py ./
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

Plik anomaly-service/app.py:

import os, time, threading, datetime as dt
import requests
import numpy as np
from fastapi import FastAPI
from sklearn.ensemble import IsolationForest

PROM_URL = os.getenv("PROM_URL", "http://localhost:9090")
ALERTMANAGER_URL = os.getenv("ALERTMANAGER_URL", "http://localhost:9093")
POLL_INTERVAL = int(os.getenv("POLL_INTERVAL", "60"))
METRIC_EXPR = os.getenv("METRIC_EXPR", "100 - (avg by(instance)(irate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)")
WINDOW_MINUTES = int(os.getenv("WINDOW_MINUTES", "60"))
CONTAMINATION = float(os.getenv("CONTAMINATION", "0.03"))
SEVERITY = os.getenv("SEVERITY", "warning")

app = FastAPI()


def query_range(expr, minutes):
    end = int(time.time())
    start = end - minutes * 60
    step = 30
    r = requests.get(f"{PROM_URL}/api/v1/query_range", params={"query": expr, "start": start, "end": end, "step": step}, timeout=15)
    r.raise_for_status()
    data = r.json()["data"]["result"]
    series = []
    for s in data:
        vals = [float(v[1]) for v in s["values"]]
        ts = [int(v[0]) for v in s["values"]]
        series.append({"metric": s["metric"], "ts": ts, "values": vals})
    return series


def send_alert(instance, value, score):
    now = dt.datetime.utcnow().isoformat() + "Z"
    labels = {
        "alertname": "AnomalyDetected",
        "severity": SEVERITY,
        "instance": instance
    }
    annotations = {
        "summary": f"Anomalia CPU dla {instance}",
        "description": f"Wykryto odstępstwo od wzorca. Wartość={value:.2f}%, score={score:.3f}"
    }
    payload = [{
        "labels": labels,
        "annotations": annotations,
        "startsAt": now
    }]
    try:
        requests.post(f"{ALERTMANAGER_URL}/api/v2/alerts", json=payload, timeout=10)
    except Exception as e:
        print("alert post failed", e)


def detector_loop():
    while True:
        try:
            series = query_range(METRIC_EXPR, WINDOW_MINUTES)
            for s in series:
                X = np.array(s["values"]).reshape(-1, 1)
                if len(X) < 10:
                    continue
                model = IsolationForest(contamination=CONTAMINATION, random_state=42)
                model.fit(X)
                preds = model.predict(X)
                scores = -model.score_samples(X)
                last_pred = preds[-1]
                last_score = float(scores[-1])
                last_val = float(X[-1][0])
                # Warunek alarmu: punkt uznany za anomalię oraz istotna wielkość odchylenia
                if last_pred == -1 and last_score > np.percentile(scores, 80):
                    instance = s["metric"].get("instance", "unknown")
                    send_alert(instance, last_val, last_score)
        except Exception as e:
            print("detector error:", e)
        time.sleep(POLL_INTERVAL)


@app.on_event("startup")
async def startup_event():
    th = threading.Thread(target=detector_loop, daemon=True)
    th.start()

@app.get("/health")
def health():
    return {"status": "ok"}

Przebuduj i uruchom stos ponownie:

docker compose up -d --build

Sprawdź zdrowie usługi: http://localhost:8000/health

Minuty 25–35: Zapytanie metryki i test algorytmu

W Prometheusie wykonaj zapytanie w zakładce „Graph” dla CPU:

100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Upewnij się, że zwraca wartości dla node-exporter:9100. Usługa ML co minutę pobierze te dane, wytrenuje lekki model na ostatnich 60 minutach i oceni bieżący punkt.

Minuty 35–45: Konfiguracja Alertmanagera dla Slack (opcjonalnie)

Jeśli masz adres webhook Slack, uzupełnij alertmanager/alertmanager.yml:

global:
  resolve_timeout: 2m
route:
  receiver: "slack"
receivers:
  - name: "slack"
    slack_configs:
      - api_url: "https://hooks.slack.com/services/<TWÓJ_WEBHOOK>"
        channel: "#alerts"
        send_resolved: true
        title: "{{ .CommonLabels.alertname }} ({{ .Status }})"
        text: "{{ range .Alerts }}<{{ .Annotations.summary }}>{{ .Annotations.description }}Labels: {{ .Labels }}{{ end }}"

Przeładuj Alertmanager:

docker compose restart alertmanager

Minuty 45–55: Dashboard Grafana i adnotacje

W Grafanie dodaj źródło danych „Prometheus” (URL: http://prometheus:9090). Utwórz prosty dashboard z panelem typu Time series i zapytaniem CPU jak wyżej. Aby dodać adnotacje o anomaliach, możesz użyć API Grafany:

curl -X POST http://admin:admin@localhost:3000/api/annotations \
  -H "Content-Type: application/json" \
  -d '{"text":"Anomalia CPU", "tags":["anomaly","ml"]}'

Adnotacje możesz wystawiać też bezpośrednio z usługi ML po wykryciu anomalii (dodatkowa funkcja POST do /api/annotations, gdy chcesz mieć ślad wizualny).

Minuty 55–60: Wygeneruj anomalię i sprawdź alert

Na hoście uruchom krótkie obciążenie CPU (Linux):

sudo apt-get update && sudo apt-get install -y stress
stress --cpu 2 --timeout 60

Obserwuj panel w Grafanie – CPU powinno skoczyć, a po chwili usługa ML wyśle alert do Alertmanagera i (opcjonalnie) na Slack.

Jak to działa: od surowych metryk do decyzji

Powyższy POC odpyta Prometheusa o okno 60 minut dla metryki CPU. Isolation Forest uczy się rozkładu wartości i wskazuje punkty izolujące się od większości. Używamy prostej heurystyki: alert generujemy, gdy ostatni punkt jest oznaczony jako anomalny oraz jego „anomaly score” przekracza 80 percentylu w oknie — to stabilizuje system i ogranicza szum.

Na produkcji warto uwzględnić sezonowość (np. STL) i cechy dodatkowe (dzień tygodnia, godzina, percentyle p50/p95/p99 latency, throughput, error rate). Ale już ta konfiguracja dobrze ilustruje, jak skonfigurować monitoring z detekcją anomalii uczeniem w praktyce.

Dobór algorytmów i kiedy które stosować

Z‑score/IQR: Gdy rozkład stabilny, mało sezonowości. Szybkie i tanie.
Isolation Forest: Gdy wzorzec jest nieliniowy, występują rzadkie odchylenia. Dobre domyślne ustawienie POC.
LOF/One‑Class SVM: Kiedy dane mają lokalne gęstości, ale mogą być wrażliwe na skalowanie i parametry.
Forecasting (Prophet/ARIMA): Gdy masz silną sezonowość dobową/tygodniową i chcesz wychwytywać odchylenia od prognozy.
Autoencodery/LSTM: Dla złożonych sekwencji i korelacji wielowymiarowych; większy koszt obliczeń.

Strategia hybrydowa działa najlepiej: reguły statyczne dla krytycznych SLO, szybkie statystyki dla „dymy bez ognia”, a ML dla subtelnych patternów.

Okna czasowe, featury i normalizacja

Długość okna: 30–120 min na krótkoterminowe anomalie operacyjne; 24–72 h dla trendów.
Krok: 15–30 s w metrykach infrastruktury; zbyt drobny krok zwiększa szum i koszt.
Featury: wartości surowe + ruchoma średnia, odchylenie standardowe, gradient, rolling min/max, percentyle.
Normalizacja: standaryzacja (z‑score) lub min‑max per seria; szczególnie istotna przy LOF/SVM.

Ograniczanie false positives i false negatives

Histereza: wymagaj kilku kolejnych punktów anomalnych zanim podniesiesz alarm.
Supresja/okna ciszy: tłum alerty w czasie znanych zdarzeń (deploy okna).
Łączenie sygnałów: anomalia CPU + wzrost latency + spadek QPS = silniejszy dowód.
Kalibracja CONTAMINATION: w Isolation Forest to procent oczekiwanych outlierów; zacznij od 0.01–0.05.
Agregacja: najpierw oceniaj anomaly per instancja, potem koreluj na poziomie usługi.

Integracje i rozszerzenia

Kubernetes: zamień Node Exporter na kube-state-metrics + cAdvisor; scrapuj ServiceMonitory (Prometheus Operator).
OpenTelemetry: łącz metryki z trace’ami; korelacja anomalii latency z konkretnymi spanami.
Loki/ELK: wzbogacaj o logi; anomalia w metrykach + cluster błędów w logach = szybsza diagnoza.
Kafka/Redpanda: dla skalowalnego streamingu metryk i wykrywania online (Flink/Spark Structured Streaming).
Webhooks/ITSM: integracja Alertmanagera z PagerDuty, ServiceNow, Jira.

MLOps w pigułce: wersjonowanie i drifty

Wersjonowanie modelu i cech: MLflow/DVC; zapisuj parametry i wyniki walidacji.
Drift danych: monitoruj rozkłady cech; jeśli się zmieniają, przeucz model.
Canary modelu: równoległe uruchomienie nowej wersji detektora na ułamku strumienia.
Obserwowalność ML: metryki dla samej usługi ML (czas inferencji, błędy, odsetek anomalii).

Bezpieczeństwo i zgodność

TLS i autoryzacja dla Prometheusa, Grafany i webhooks.
Ochrona sekretów: Docker secrets, HashiCorp Vault, Kubernetes Secrets + RBAC.
Dane wrażliwe: metryki aplikacyjne mogą zawierać PII w labelach — sanitizacja i polityka retencji.

Wydajność i koszty

Kardynalność labeli: ogranicz liczbę unikalnych kombinacji; to główny koszt Prometheusa.
Scrape interval: 15 s to dobry kompromis; zbyt gęsto = więcej danych i kosztów.
Retention: trzymaj surowe dane krócej, agregaty dłużej (recording rules).
Skalowanie detektora: rozdziel modele per ważne metryki; batchuj zapytania do Prometheus API.

Najczęstsze błędy przy wdrożeniu

Brak walidacji na danych historycznych: przetestuj detektor na tygodniu danych, zanim zaufasz produkcji.
Zbyt agresywne progi: contamination ustawione wysoko wywoła lawinę alertów.
Ignorowanie sezonowości: dobowo‑tygodniowe rytmy potrafią „oszukiwać” detektor.
Monolityczny alert: rozbij na poziom instancji, regionu, usługi; unikniesz „alert storms”.
Brak kanałów eskalacji: integruj z inżynierią on‑call, ustal reguły ciszy i harmonogramy.

Jak dodać kolejne metryki i usługi

Chcesz wykrywać anomalie w latency HTTP? Dodaj Service, który eksponuje metryki w formacie Prometheus (np. /metrics z histogramem). Następnie:

Dodaj nowy job w prometheus.yml wskazujący usługę.
Zaktualizuj zmienną środowiskową METRIC_EXPR w anomaly-service, np.:

histogram_quantile(0.95, sum by (le, instance) (rate(http_request_duration_seconds_bucket[5m])))

To wystarczy, aby ten sam detektor zaczął oceniać nową metrykę. W miarę rozwoju możesz prowadzić wiele instancji detektora, każdą z inną ekspresją, oknem i parametrami modelu.

Walidacja i tuning: krótki przewodnik

Zbierz dane historyczne (np. 7–14 dni) i odtwórz wykrywanie offline.
Etykietuj zdarzenia (deploymenty, incydenty) — będziesz wiedzieć, czy detektor działa.
Przetestuj różne CONTAMINATION i progi score — narysuj krzywe precision/recall.
Dodaj histerezę (np. 2–3 kolejne punkty anomalii wymagane dla alertu).
Połącz sygnały (CPU + latency) dla krytycznych alertów produkcyjnych.

Automatyzacja: CI/CD i infrastruktura jako kod

Przechowuj docker-compose.yml i konfiguracje w repozytorium; użyj GitHub Actions do buildów obrazów.
W Terraform/Helm opisz Prometheusa, Grafanę i Alertmanagera dla środowisk wyższych.
Testy integracyjne: uruchamiaj środowisko ephemeral i generator anomalii w pipeline.

FAQ: najczęstsze pytania

Czy muszę używać Isolation Forest? Nie. Możesz zacząć od prostych z‑score na rolling window — czasem da to lepszy stosunek sygnału do szumu.

Czy to działa bez etykiet? Tak — podejście nienadzorowane nie wymaga etykiet. Etykiety pomagają w walidacji i strojen iu.

Czy nadaje się do produkcji? Tak, jako POC i fundament. Do pełnej produkcji dodaj: HA, storage TSDB (Thanos/Cortex/Mimir), wersjonowanie modeli, polityki bezpieczeństwa i SLO alerting.

Jakie są koszty? Zależne od kardynalności metryk i retencji. Na start koszty są niewielkie; główny koszt to utrzymanie i rozsądna konfiguracja.

Checklist wdrożeniowy

Dane: poprawny scraping i stabilne etykiety.
Model: rozsądne okno, contamination i próg score.
Alerty: kanały, eskalacje, supresja, histereza.
Obserwowalność: metryki dla detektora ML (czas, błędy, odsetek anomalii).
Bezpieczeństwo: TLS, autoryzacja, tajemnice.
Dokumentacja: dashboardy, playbooki, runbooki.

Co dalej: ścieżka rozwoju po POC

Dodaj kolejne klasy metryk: latency, błędy, a nawet koszty chmury.
Wprowadź forecasting dla sezonowości (Prophet) i łączenie z detektorem outlierów.
Przenieś do Kubernetesa, użyj Prometheus Operator i sidecarów do HA.
Wprowadź explainability: dlaczego punkt jest anomalią (SHAP/cechy wyjaśniające).

Podsumowanie

W 60 minut uruchomiłeś fundament inteligentnego monitoringu z wykrywaniem anomalii: Prometheus, Grafana, Alertmanager i lekka usługa ML. Wiesz już, jak skonfigurować monitoring z detekcją anomalii uczeniem w praktyce, jak dobrać okna i progi, ograniczać false positive oraz jak integrować system z narzędziami DevOps. Od tego punktu rozwijasz rozwiązanie: dodajesz metryki, wprowadzasz sezonowość i MLOps, a następnie skalujesz w kierunku produkcyjnych wymagań SLO.

Najważniejsze: zacznij prosto, iteruj szybko, mierz skuteczność i dokumentuj decyzje. Z takim podejściem inteligentny monitoring nie tylko ostrzega, ale realnie wspiera stabilność i szybkość działania Twoich usług.