Monitoring z Prometheus i Grafana - Kompletny przewodnik

W erze mikroserwisow, konteneryzacji i rozproszonych systemow monitoring przestal byc opcjonalnym dodatkiem -- stal sie fundamentalnym filarem niezawodnosci. Bez odpowiedniego wgladu w zachowanie systemu kazdy incydent staje sie gra w ciemno. Prometheus i Grafana to duet, ktory stal sie de facto standardem w swiecie obserwowalnosci open-source, obslugujacy systemy od malych startupow po korporacje klasy Fortune 500.

W tym artykule przejdziemy przez kompletny proces wdrozenia monitoringu -- od zrozumienia fundamentow obserwowalnosci, przez architekture Prometheus, konfiguracje eksporterow, po budowanie dashboardow w Grafanie i ustawianie alertow. Omowimy tez alternatywy komercyjne takie jak Datadog i New Relic, abys mogl podjac swiadoma decyzje.

Trzy filary obserwowalnosci#

Obserwowalnosc (observability) to zdolnosc systemu do ujawniania swojego stanu wewnetrznego na podstawie zewnetrznych sygnalow. Opiera sie na trzech filarach, z ktorych kazdy dostarcza innego rodzaju informacji diagnostycznych.

Metryki (Metrics)#

Metryki to dane liczbowe mierzone w czasie -- liczniki, histogramy, gauge'e. Odpowiadaja na pytanie "co sie dzieje?". Przyklady obejmuja liczbe zadan HTTP na sekunde, zuzycie CPU, czas odpowiedzi API czy liczbe aktywnych polaczen z baza danych. Metryki sa lekkie w przechowywaniu i idealne do wykrywania trendow oraz alertowania.

Logi (Logs)#

Logi to ustrukturyzowane lub nieustrukturyzowane rekordy zdarzen. Odpowiadaja na pytanie "dlaczego cos sie stalo?". Przyklady to stacktrace'y bledow, logi dostepu HTTP, komunikaty aplikacji. Logi sa nieocenione przy debugowaniu, ale ich przechowywanie i przeszukiwanie w duzej skali bywa kosztowne.

Slady (Traces)#

Slady rozproszone (distributed traces) sledza przeplyw zadania przez wiele serwisow. Odpowiadaja na pytanie "gdzie w lancuchu wywolan jest problem?". Narzedzia takie jak Jaeger czy Tempo wizualizuja slady jako waterfall diagram, pokazujac dokladnie ile czasu kazdy serwis potrzebowal na przetworzenie zadania.

Prometheus specjalizuje sie w metrykach -- i robi to wyjatkowo dobrze. Dla logow warto rozwazyc Loki (rowniez od Grafana Labs), a dla traces -- Tempo lub Jaeger. Wszystkie trzy integruja sie z Grafana, tworzac kompletny stos obserwowalnosci znany jako "Grafana Stack" (dawniej LGTM -- Loki, Grafana, Tempo, Mimir).

Architektura Prometheus#

Prometheus wyroznia sie architektura oparta na modelu pull. Zamiast przyjmowac dane od aplikacji (push), aktywnie pobiera metryki z endpointow HTTP w regularnych odstepach czasu. Ten model upraszcza konfiguracje i pozwala na latwe wykrywanie, czy dany target jest dostepny.

Kluczowe komponenty#

• Prometheus Server -- glowny serwer odpowiedzialny za scraping, przechowywanie danych w lokalnej bazie TSDB (Time Series Database) i odpytywanie za pomoca PromQL
• Exporters -- procesy udostepniajace metryki w formacie Prometheus (Node Exporter dla metryk systemowych, cAdvisor dla kontenerow, exportery bazodanowe dla PostgreSQL/MySQL/Redis)
• Pushgateway -- posrednik dla krotkotrwalych zadan (batch jobs), ktore nie moga byc odpytywane w modelu pull
• Alertmanager -- dedykowany serwis do obslugi alertow: routing, deduplication, silencing, wyslanie powiadomien na Slack, email, PagerDuty
• Service Discovery -- mechanizmy automatycznego wykrywania targetow (Kubernetes, Consul, DNS, pliki statyczne)

Model danych#

Prometheus przechowuje dane jako time series -- sekwencje wartosci oznaczonych timestampem. Kazda seria jest identyfikowana przez nazwe metryki i zestaw etykiet (labels):

http_requests_total{method="GET", endpoint="/api/users", status="200"} 1547

Typy metryk w Prometheus:

• Counter -- wartosc monotonicznie rosnaca (np. http_requests_total). Nigdy nie maleje, resetuje sie tylko przy restarcie procesu
• Gauge -- wartosc, ktora moze rosnac i malec (np. temperature_celsius, active_connections)
• Histogram -- obserwacje bucketed z suma i licznikiem (np. http_request_duration_seconds). Idealny do mierzenia percentyli
• Summary -- podobne do histogramu, ale z kwantylami obliczanymi po stronie klienta. Rzadziej uzywany ze wzgledu na brak mozliwosci agregacji

Konfiguracja Prometheus#

Glowny plik konfiguracyjny Prometheus to prometheus.yml. Definiuje on globalne ustawienia, cele scrapingu i reguly alertow:

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  scrape_timeout: 10s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "alertmanager:9093"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"]

  - job_name: "dotnet-app"
    metrics_path: /metrics
    static_configs:
      - targets: ["dotnet-api:5000"]

  - job_name: "nodejs-app"
    static_configs:
      - targets: ["nodejs-api:3000"]

Kazdy job_name definiuje grupe targetow. Prometheus regularnie odpytuje kazdy target pod sciezka /metrics (domyslnie) i zapisuje otrzymane metryki w swojej bazie danych.

PromQL -- jezyk zapytan Prometheus#

PromQL (Prometheus Query Language) to potezny, funkcyjny jezyk zapytan do analizy danych metrycznych. Jest sercem Prometheus i kluczem do efektywnego monitoringu.

Podstawowe zapytania#

# Biezaca wartosc metryki
up

# Filtrowanie po etykietach
http_requests_total{method="GET", status="200"}

# Regex matching
http_requests_total{status=~"5.."}

# Wykluczenie etykiet
http_requests_total{method!="OPTIONS"}

Funkcje zakresu i rate#

# Tempo wzrostu requestow na sekunde (ostatnie 5 minut)
rate(http_requests_total[5m])

# Wzrost bezwzgledny w ciagu godziny
increase(http_requests_total[1h])

# Rate dla poszczegolnych endpointow
sum by (endpoint) (rate(http_requests_total[5m]))

Zaawansowane zapytania#

# 95. percentyl czasu odpowiedzi (histogram)
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

# Procent bledow (error rate)
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
* 100

# Dostepnosc serwisow (uptime)
avg_over_time(up[24h]) * 100

# Top 5 endpointow pod wzgledem ruchu
topk(5, sum by (endpoint) (rate(http_requests_total[5m])))

# Predykcja -- za ile godzin dysk bedzie pelny
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600)

PromQL pozwala rowniez na operacje binarne miedzy metrykami, grupowanie wynikow (by, without) oraz stosowanie funkcji agregujacych (sum, avg, min, max, count).

Node Exporter -- metryki systemowe#

Node Exporter to oficjalny exporter Prometheus dla metryk systemowych Linux/Unix. Dostarcza dane o CPU, pamieci, dysku, sieci i wielu innych zasobach.

Kluczowe metryki#

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

# Zuzycie RAM (procent)
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Zuzycie dysku (procent)
(1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100

# Ruch sieciowy (bajty/s)
rate(node_network_receive_bytes_total{device="eth0"}[5m])

# Load average
node_load1
node_load5
node_load15

Inne przydatne eksportery to cAdvisor (metryki kontenerow Docker), blackbox_exporter (probing HTTP/TCP/ICMP), postgres_exporter, redis_exporter oraz mysqld_exporter.

Metryki aplikacji#

.NET -- prometheus-net#

Dla aplikacji .NET (ASP.NET Core) stosujemy biblioteke prometheus-net:

// Program.cs
using Prometheus;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Middleware do zbierania metryk HTTP
app.UseHttpMetrics(options =>
{
    options.AddCustomLabel("host", context => context.Request.Host.Host);
});

app.MapControllers();

// Endpoint /metrics
app.MapMetrics();

app.Run();

// Metryki niestandardowe w serwisie
using Prometheus;

public class OrderService
{
    private static readonly Counter OrdersCreated = Metrics
        .CreateCounter("orders_created_total", "Total orders created",
            new CounterConfiguration
            {
                LabelNames = new[] { "payment_method", "status" }
            });

    private static readonly Histogram OrderProcessingDuration = Metrics
        .CreateHistogram("order_processing_duration_seconds",
            "Time spent processing an order",
            new HistogramConfiguration
            {
                Buckets = Histogram.ExponentialBuckets(0.01, 2, 10)
            });

    private static readonly Gauge ActiveOrders = Metrics
        .CreateGauge("active_orders", "Number of currently active orders");

    public async Task<Order> CreateOrder(OrderRequest request)
    {
        ActiveOrders.Inc();
        using (OrderProcessingDuration.NewTimer())
        {
            try
            {
                var order = await ProcessOrder(request);
                OrdersCreated.WithLabels(request.PaymentMethod, "success").Inc();
                return order;
            }
            catch (Exception)
            {
                OrdersCreated.WithLabels(request.PaymentMethod, "failed").Inc();
                throw;
            }
            finally
            {
                ActiveOrders.Dec();
            }
        }
    }
}

Node.js -- prom-client#

Dla aplikacji Node.js (Express) uzywamy prom-client:

// metrics.js
const client = require('prom-client');

// Domyslne metryki (CPU, pamiec, event loop, GC)
client.collectDefaultMetrics({ prefix: 'nodejs_' });

// Metryki HTTP
const httpRequestDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
});

const httpRequestsTotal = new client.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'status_code'],
});

const activeConnections = new client.Gauge({
  name: 'active_connections',
  help: 'Number of active connections',
});

// Middleware Express
function metricsMiddleware(req, res, next) {
  const end = httpRequestDuration.startTimer();
  activeConnections.inc();

  res.on('finish', () => {
    const route = req.route?.path || req.path;
    const labels = {
      method: req.method,
      route: route,
      status_code: res.statusCode,
    };
    end(labels);
    httpRequestsTotal.inc(labels);
    activeConnections.dec();
  });

  next();
}

module.exports = { metricsMiddleware, client };

// app.js
const express = require('express');
const { metricsMiddleware, client } = require('./metrics');

const app = express();

app.use(metricsMiddleware);

app.get('/metrics', async (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(await client.register.metrics());
});

app.get('/api/health', (req, res) => {
  res.json({ status: 'healthy', uptime: process.uptime() });
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Grafana -- wizualizacja i dashboardy#

Grafana to platforma wizualizacji, ktora zamienia surowe metryki w czytelne, interaktywne dashboardy. Wspiera dziesiatki zrodel danych -- Prometheus, InfluxDB, Elasticsearch, PostgreSQL, Loki i wiele innych.

Konfiguracja data source#

Po zainstalowaniu Grafany pierwszym krokiem jest dodanie Prometheus jako zrodla danych. Mozna to zrobic przez interfejs graficzny lub automatycznie za pomoca provisioning:

# grafana/provisioning/datasources/prometheus.yml
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false
    jsonData:
      timeInterval: "15s"
      httpMethod: POST

Typy paneli w Grafanie#

Grafana oferuje roznorodne typy wizualizacji:

• Time series -- klasyczny wykres liniowy, idealny do metryk zmieniajacych sie w czasie
• Stat -- pojedyncza wartosc z opcjonalnym sparkline (np. aktualny error rate)
• Gauge -- wizualizacja w formie wskaznika (np. zuzycie CPU w procentach)
• Table -- dane tabelaryczne z mozliwoscia sortowania i filtrowania
• Heatmap -- idealna do wizualizacji rozkladu histogramow
• Bar chart -- porownania miedzy kategoriami
• Logs -- integracja z Loki do wyswietlania logow obok metryk

Cztery zlote sygnaly (Golden Signals)#

Google SRE definiuje cztery kluczowe sygnaly, ktore nalezy monitorowac dla kazdego serwisu:

1. Latency (opoznienie) -- czas odpowiedzi na zadania:

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

2. Traffic (ruch) -- wolumen zadan:

sum(rate(http_requests_total[5m]))

3. Errors (bledy) -- wskaznik bledow:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

4. Saturation (nasycenie) -- stopien obciazenia zasobow:

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Dashboard provisioning#

Dashboardy mozna definiowac jako kod (JSON) i ladowac automatycznie:

# grafana/provisioning/dashboards/dashboards.yml
apiVersion: 1

providers:
  - name: 'default'
    orgId: 1
    folder: 'Infrastructure'
    type: file
    disableDeletion: false
    editable: true
    options:
      path: /var/lib/grafana/dashboards
      foldersFromFilesStructure: true

Alerting z Alertmanager#

Alertmanager obsluguje alerty wygenerowane przez Prometheus -- grupuje je, deduplikuje, wycisza i kieruje do odpowiednich kanalow notyfikacji.

Reguly alertow w Prometheus#

# alerts/application.yml
groups:
  - name: application
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))
          > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Wysoki wskaznik bledow (> 5%)"
          description: "Error rate wynosi {{ $value | humanizePercentage }} dla {{ $labels.job }}"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
          > 1.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Wysokie opoznienie P95 (> 1s)"
          description: "P95 latency wynosi {{ $value }}s"

      - alert: HighMemoryUsage
        expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Wysokie zuzycie pamieci (> 85%)"

      - alert: DiskSpaceRunningLow
        expr: |
          (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 > 80
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Niski poziom wolnego miejsca na dysku (> 80%)"

      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Serwis {{ $labels.job }} jest niedostepny"

Konfiguracja Alertmanager#

# alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_from: "alerts@example.com"
  smtp_smarthost: "smtp.example.com:587"
  smtp_auth_username: "alerts@example.com"
  smtp_auth_password: "secret"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      repeat_interval: 1h
    - match:
        severity: warning
      receiver: 'warning-alerts'

receivers:
  - name: 'default'
    email_configs:
      - to: "team@example.com"

  - name: 'critical-alerts'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/xxx/yyy/zzz"
        channel: "#alerts-critical"
        title: '{{ .CommonAnnotations.summary }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
    pagerduty_configs:
      - service_key: "your-pagerduty-key"

  - name: 'warning-alerts'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/xxx/yyy/zzz"
        channel: "#alerts-warning"

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Alertmanager wspiera rowniez integracje z Microsoft Teams, OpsGenie, VictorOps i webhookami, co pozwala na dopasowanie do istniejacych procesow incydentowych.

Docker Compose -- kompletny stos monitoringu#

Ponizej pelna konfiguracja Docker Compose, gotowa do uruchomienia w kilka minut:

# docker-compose.monitoring.yml
version: "3.8"

services:
  prometheus:
    image: prom/prometheus:v2.48.0
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/alerts:/etc/prometheus/alerts
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'
      - '--web.enable-admin-api'
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:10.2.0
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=SecurePassword123
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://grafana.example.com
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    depends_on:
      - prometheus
    networks:
      - monitoring

  alertmanager:
    image: prom/alertmanager:v0.26.0
    container_name: alertmanager
    restart: unless-stopped
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - alertmanager_data:/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
    networks:
      - monitoring

  node-exporter:
    image: prom/node-exporter:v1.7.0
    container_name: node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    networks:
      - monitoring

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.47.0
    container_name: cadvisor
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    privileged: true
    devices:
      - /dev/kmsg:/dev/kmsg
    networks:
      - monitoring

volumes:
  prometheus_data:
  grafana_data:
  alertmanager_data:

networks:
  monitoring:
    driver: bridge

Uruchomienie stosu:

docker compose -f docker-compose.monitoring.yml up -d

Po uruchomieniu dostepne beda:

• Prometheus: http://localhost:9090
• Grafana: http://localhost:3001
• Alertmanager: http://localhost:9093
• Node Exporter: http://localhost:9100/metrics
• cAdvisor: http://localhost:8080

Monitoring w Kubernetes#

W srodowisku Kubernetes najwygodniejszym rozwiazaniem jest kube-prometheus-stack (dawniej prometheus-operator), instalowany przez Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword="SecurePassword123" \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

ServiceMonitor -- automatyczny discovery#

W Kubernetes monitorowanie serwisow odbywa sie przez ServiceMonitor CRD:

# servicemonitor.yml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-api-monitor
  namespace: monitoring
  labels:
    release: kube-prometheus
spec:
  namespaceSelector:
    matchNames:
      - production
  selector:
    matchLabels:
      app: my-api
  endpoints:
    - port: http
      path: /metrics
      interval: 15s
      scrapeTimeout: 10s

Metryki niestandardowe -- najlepsze praktyki#

Przy definiowaniu wlasnych metryk przestrzegaj kilku zasad:

1. Konwencja nazewnictwa -- uzywaj formatu namespace_subsystem_name_unit. Przyklad: myapp_orders_processing_duration_seconds
2. Uzywaj odpowiednich typow -- Counter dla zdarzen (requesty, bledy), Gauge dla stanow (polaczenia, temperatura), Histogram dla rozkladow (latency)
3. Nie naduzywaj etykiet -- kazda unikalna kombinacja etykiet tworzy osobna serie czasowa. Unikaj etykiet o wysokiej kardynalnosci (np. user_id, request_id)
4. Bazowe jednostki SI -- sekundy zamiast milisekund, bajty zamiast megabajtow
5. Metryki RED i USE:
   • RED (Rate, Errors, Duration) -- dla serwisow
   • USE (Utilization, Saturation, Errors) -- dla zasobow infrastruktury
6. Dokumentuj metryki -- kazda metryka powinna miec opisowy help text wyjasniajacy co mierzy

Porownanie z rozwiazaniami komercyjnymi#

| Aspekt | Prometheus + Grafana | Datadog | New Relic | |--------|---------------------|---------|-----------| | Koszt | Bezplatne (open-source) | Od $15/host/mies. | Od $25/host/mies. | | Hosting | Self-hosted | SaaS | SaaS | | Skalowalnosc | Wymaga Thanos/Cortex/Mimir | Wbudowana | Wbudowana | | Krzywa uczenia | Stroma (PromQL, YAML) | Umiarkowana | Lagodna | | Integracje | Setki eksporterow | 700+ natywnych | 500+ natywnych | | Retencja danych | Konfigurowalna (lokalnie) | 15 mies. (plan Pro) | 8 dni (Free) | | Alerty | Alertmanager | Wbudowane | Wbudowane | | APM / Traces | Wymagane dodatkowe narzedzia | Wbudowane | Wbudowane | | Logi | Loki (osobne wdrozenie) | Wbudowane | Wbudowane |

Kiedy wybrac Prometheus + Grafana:

• Kontrola kosztow jest priorytetem -- brak oplat za hosta czy wolumen metryk
• Potrzebujesz pelnej kontroli nad danymi i infrastruktura
• Masz doswiadczenie z Kubernetes i DevOps
• Chcesz uniknac vendor lock-in
• Masz zespol zdolny utrzymac infrastrukture monitoringu

Kiedy rozwazyc Datadog lub New Relic:

• Brak zespolu DevOps do utrzymania infrastruktury monitoringu
• Potrzebujesz "all-in-one" z APM, logami i traces w jednym miejscu
• Szybkie wdrozenie jest wazniejsze od kosztow
• Potrzebujesz zaawansowanego APM z automatycznym instrumentowaniem

Inne alternatywy warte uwagi to Elastic Stack (ELK) dla logow i metryk, Zabbix dla tradycyjnego monitoringu infrastruktury oraz VictoriaMetrics jako drop-in replacement dla Prometheus z lepsza wydajnoscia i kompresja.

Najlepsze praktyki monitoringu#

1. Monitoruj to, co wazne dla uzytkownika#

Zacznij od metryk biznesowych i doswiadczenia uzytkownika (latency, availability), a dopiero potem schodz na poziom infrastruktury. Jesli uzytkownik nie odczuwa problemu, alert nie powinien budzic nikogo w nocy.

2. Ustawiaj alerty na symptomy, nie przyczyny#

Alertuj na "error rate > 5%" zamiast "CPU > 90%". Wysoki CPU nie zawsze oznacza problem -- wysoki error rate zawsze go oznacza.

3. Stosuj wielopoziomowe dashboardy#

• Executive -- SLA, uptime, key business metrics
• Service -- Golden Signals per serwis
• Infrastructure -- CPU, pamiec, dysk, siec
• Debug -- szczegolowe metryki do diagnostyki

4. Retencja i kompresja#

Przechowuj dane high-resolution (15s) przez 2 tygodnie, downsamplowane (5min) przez 6 miesiecy, i heavily aggregated (1h) na dluzej. Thanos, Cortex lub Mimir pomagaja z dlugoterminowym przechowywaniem.

5. Regularnie testuj alerty#

Alerty, ktore nigdy nie strzelily, moga nie dzialac gdy beda potrzebne. Regularnie przeprowadzaj "fire drills" -- symulowane incydenty testujace caly pipeline alertowy.

6. Stosuj Infrastructure as Code#

Trzymaj konfiguracje Prometheus, reguly alertow i dashboardy Grafany w repozytorium Git. Uzywaj provisioningu zamiast recznej konfiguracji przez UI.

Podsumowanie#

Prometheus i Grafana tworza potezny, dojrzaly i sprawdzony w boju ekosystem monitoringu. Model pull, jezyk PromQL, bogaty ekosystem eksporterow i natywna integracja z Kubernetes sprawiaja, ze jest to naturalny wybor dla zespolow DevOps i SRE.

Kluczowe wnioski:

• Zacznij od trzech filarow obserwowalnosci i czterech zlotych sygnalow
• Instrumentuj aplikacje od pierwszego dnia -- dodanie metryk pozniej jest trudniejsze
• Ustaw alerty na symptomy widoczne dla uzytkownika
• Buduj wielopoziomowe dashboardy -- od ogolnego obrazu po szczegoly
• Planuj retencje i skalowalnosc od poczatku
• Trzymaj konfiguracje w Git jako Infrastructure as Code

---

Potrzebujesz profesjonalnego monitoringu?#

MDS Software Solutions Group specjalizuje sie we wdrazaniu kompletnych rozwiazan obserwowalnosci. Od konfiguracji Prometheus i Grafana, przez projektowanie alertow, po integracje z pipeline CI/CD -- pomozemy Ci zbudowac monitoring, ktory naprawde chroni Twoje systemy.

Nasz zespol posiada doswiadczenie w monitoringu aplikacji .NET, Node.js, Java i Python, zarowno w srodowiskach Docker Compose, jak i Kubernetes. Projektujemy dashboardy, ktore dostarczaja wartosciowych informacji, a nie szumu.

Skontaktuj sie z nami -- porozmawiajmy o monitoringu Twojej infrastruktury.