Observability i Monitoring Production Systems - Przewodnik 2025 | Wojciechowski.app

Koszt awarii: $5,600 na minutę

Według Gartner, średni koszt przestoju IT to $5,600 za minutę. Dla e-commerce podczas Black Friday? Nawet $300,000 na godzinę. Nie możesz pozwolić sobie na godziny debugowania.

Godzina 3 w nocy. Budzą cię alerty: "System nie działa".

Sprawdzasz status page - wszystko zielone. CPU i pamięć w normie. Logi pokazują tylko standardowe wpisy. Ale użytkownicy krzyczą, że nie mogą składać zamówień.

Gdzie jest problem? Bez odpowiedniego observability tracisz cenne minuty przeskakując między dashboardami, szukając igły w stogu siana.

To różnica między monitoringiem a observability. Monitoring mówi ci, że system ma problem. Observability mówi ci dlaczego - i prowadzi bezpośrednio do przyczyny. W świecie mikrousług, distributed systemów i cloudowych deploymentów, observability to nie luksus. To konieczność survivalowa.

01Observability vs Monitoring - Różnica, która ma znaczenie

Większość firm myśli, że monitoring to observability. To jak myślenie, że posiadanie termometru oznacza rozumienie medycyny.

Różnica jest fundamentalna - i może zaoszczędzić ci godzin nocnego debugowania.

Monitoring

Odpowiada na pytanie: "Co się dzieje?"

•Mierzysz znane metryki (CPU, RAM, request rate)
•Ustawiasz alerty na przekroczenie progów
•Patrzysz na dashboardy z metrykami
•Reagujesz na symptomy

Przykład: Alert "CPU >80%" wysyła powiadomienie. Ale nie wiesz który serwis powoduje problem ani dlaczego.

Observability

Odpowiada na pytanie: "Dlaczego to się dzieje?"

•Rozumiesz wewnętrzny stan systemu z zewnętrznych sygnałów
•Możesz zadawać dowolne pytania o system
•Śledzisz requesty przez cały system (distributed tracing)
•Znajdujesz przyczynę źródłową problemów

Przykład: Widzisz że checkout API jest wolne, śledzisz trace i odkrywasz że PaymentService czeka 5s na odpowiedź od payment gateway.

Kluczowa różnica

Monitoring odpowiada na pytania, które przewidziałeś. Observability pozwala odpowiedzieć na pytania, których nie przewidziałeś - a to właśnie te pytania pojawiają się o 3 w nocy podczas production incidentów.

To szczególnie krytyczne w architekturach mikrousług, gdzie pojedynczy request może przejść przez 10+ serwisów zanim zwróci błąd.

Honeycomb (pionierzy observability) definiuje to tak:

"Observability to zdolność do zrozumienia wewnętrznego stanu systemu poprzez analizę jego zewnętrznych outputów. System jest observable gdy możesz zadać dowolne pytanie o jego zachowanie bez konieczności przewidywania pytania z góry."

02Three Pillars of Observability

Observability opiera się na trzech filarach danych: metryki (metrics), logi (logs) i distributed tracing.

Każdy filar daje inny widok na system. Pojedynczo? Ograniczona wartość. Razem? Pełny obraz tego, co dzieje się w produkcji.

Metrics - Liczby pokazujące trend

Agregowane wartości numeryczne mierzone w czasie. Odpowiadają na pytanie: "Jak bardzo dobry/zły jest stan systemu?"

Przykładowe metryki:

• Request rate: 1,200 req/s (ile requestów przychodzi)
• Error rate: 0.5% (procent requestów kończących błędem)
• Latency P95: 150ms (95% requestów szybsze niż 150ms)
• CPU usage: 65% (wykorzystanie zasobów)
• Active connections: 450 (ile równoczesnych połączeń)

Zalety:

Małe rozmiary danych, szybkie zapytania, świetne do alertów i dashboardów. Możesz przechowywać metryki z wielu miesięcy bez dużych kosztów.

Wady:

Brak kontekstu. Widzisz że error rate wzrósł, ale nie wiesz który użytkownik, który endpoint, jakie warunki spowodowały błąd.

Logs - Dyskretne wydarzenia z kontekstem

Tekstowe zapisy tego, co dzieje się w aplikacji. Każdy log to pojedyncze wydarzenie z timestamp i kontekstem.

Przykładowy structured log:

{
  "timestamp": "2025-11-22T14:23:45.123Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123xyz",
  "user_id": "user_456",
  "message": "Payment gateway timeout",
  "details": {
    "payment_method": "credit_card",
    "amount": 129.99,
    "gateway": "stripe",
    "timeout_ms": 5000
  }
}

Zalety:

Bogaty kontekst, możesz dołączyć dowolne dane, świetne do debugowania konkretnych przypadków. Structured logs (JSON) umożliwiają zaawansowane filtry.

Wady:

Duże rozmiary danych (GB dziennie w produkcji), kosztowne przechowywanie, trudno zobaczyć big picture. Nie mówią nic o relacjach między serwisami.

Traces - Podróż requestu przez system

Distributed trace pokazuje dokładną ścieżkę pojedynczego requestu przez wszystkie mikroserwisy, z czasami wykonania każdego kroku.

Przykładowy trace (checkout request):

|--API Gateway [5ms]

|--Order Service [350ms total]

|--Inventory Check [20ms]

|--Payment Service [300ms] ← BOTTLENECK

|--Stripe API call [280ms] ← SLOW!

|--Notification Service [15ms]

|--Response [5ms]

Zalety:

Pokazuje dokładnie gdzie request spędza czas, jakie serwisy się komunikują, gdzie są bottlenecki. Nieocenione w mikrousługach.

Wady:

Wymaga instrumentacji wszystkich serwisów, duże rozmiary danych (zazwyczaj samplujesz tylko 1-10% requestów). Skomplikowana konfiguracja.

Jak te trzy filary współpracują w praktyce

Scenario: Production incident. Dostałeś alert o wysokim latency API. Jak debugujesz?

1.Metrics mówią: "P95 latency wzrosło z 100ms do 2s o 14:30"
2.Traces pokazują: "Wolne requesty spędzają większość czasu w PaymentService"
3.Logs z PaymentService ujawniają: "Connection pool exhausted - 0 available connections"

Bez wszystkich trzech, debugging zajmuje godziny. Z wszystkimi trzema - minuty.

03OpenTelemetry - Standard Observability

Przez lata każdy vendor miał własny format. Prometheus - swój. Jaeger - inny. DataDog - kolejny.

Integracja? Koszmar. Zmiana vendora? Przepisywanie całej instrumentacji. Potem powstał OpenTelemetry - vendor-neutral standard wspierany przez Microsoft, Google, AWS i całą CNCF. To faktyczny standard przemysłowy dla observability w 2025.

Czym jest OpenTelemetry (OTel)?

OpenTelemetry to zbiór APIs, SDKs, bibliotek i narzędzi do automatycznej i manual instrumentacji aplikacji. Generuje, zbiera i eksportuje telemetry data: metrics, logs i traces.

Powstał z fuzji OpenTracing (distributed tracing) i OpenCensus (metrics) w 2019 roku. Projekt CNCF (Cloud Native Computing Foundation) na poziomie "graduated" - najwyższy poziom dojrzałości, obok Kubernetes, Prometheus czy Envoy.

Co daje OTel:

• Vendor-neutral - nie jesteś przywiązany do jednego vendora
• Single SDK dla wszystkich pillarów (metrics, logs, traces)
• Automatyczna instrumentacja dla popularnych frameworków
• Eksport do dowolnego backendu (Prometheus, Jaeger, DataDog, etc)

Kto używa OTel:

• Microsoft (Azure Monitor)
• Google (Cloud Trace)
• AWS (X-Ray)
• Uber, Netflix, Shopify

Dlaczego observability jest kluczowe dla systemów rozproszonych?

W monolicie: 1 proces, 1 database, 1 log file. Debug? Sprawdzasz logi, widzisz stack trace, znajdujesz bug.

W mikrousługach: Request przechodzi przez API Gateway → Auth Service → Order Service → Inventory Service → Payment Service → Notification Service. Każdy ma własne logi, własne metryki, własny database. Gdzie jest błąd? Bez distributed tracing - szczęścia.

Praktyczna implementacja - .NET API z OpenTelemetry

Jak dodać pełną observability do .NET 10 aplikacji - przykład z prawdziwego projektu produkcyjnego:

1. Instalacja packages:

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http
dotnet add package OpenTelemetry.Instrumentation.SqlClient
dotnet add package OpenTelemetry.Exporter.Prometheus
dotnet add package OpenTelemetry.Exporter.Jaeger

2. Konfiguracja w Program.cs:

using OpenTelemetry.Resources;
using OpenTelemetry.Trace;
using OpenTelemetry.Metrics;

var builder = WebApplication.CreateBuilder(args);

// Define service name and version
var serviceName = "order-api";
var serviceVersion = "1.0.0";

builder.Services.AddOpenTelemetry()
    .ConfigureResource(resource => resource
        .AddService(serviceName: serviceName, serviceVersion: serviceVersion))

    // Traces configuration
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation(options =>
        {
            options.RecordException = true;
            options.Filter = (httpContext) =>
            {
                // Don't trace health checks
                return !httpContext.Request.Path.StartsWithSegments("/health");
            };
        })
        .AddHttpClientInstrumentation()
        .AddSqlClientInstrumentation(options =>
        {
            options.RecordException = true;
            options.SetDbStatementForText = true;
        })
        .AddSource("OrderService.*") // Custom traces
        .AddJaegerExporter(options =>
        {
            options.AgentHost = "jaeger";
            options.AgentPort = 6831;
        }))

    // Metrics configuration
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddRuntimeInstrumentation()
        .AddMeter("OrderService.*") // Custom metrics
        .AddPrometheusExporter());

var app = builder.Build();

// Expose Prometheus metrics endpoint
app.MapPrometheusScrapingEndpoint("/metrics");

app.Run();

Custom traces i spans

Automatyczna instrumentacja to świetny start, ale dla krytycznych operacji warto dodać custom spans:

using System.Diagnostics;

public class OrderService
{
    private static readonly ActivitySource ActivitySource =
        new("OrderService.Processing");

    public async Task<Order> ProcessOrderAsync(CreateOrderRequest request)
    {
        using var activity = ActivitySource.StartActivity("ProcessOrder");
        activity?.SetTag("order.amount", request.TotalAmount);
        activity?.SetTag("order.items", request.Items.Count);
        activity?.SetTag("user.id", request.UserId);

        try
        {
            // Validate inventory
            using (var inventoryActivity = ActivitySource.StartActivity("CheckInventory"))
            {
                await _inventoryService.ValidateStockAsync(request.Items);
                inventoryActivity?.SetTag("inventory.valid", true);
            }

            // Process payment
            using (var paymentActivity = ActivitySource.StartActivity("ProcessPayment"))
            {
                var payment = await _paymentService.ChargeAsync(
                    request.UserId,
                    request.TotalAmount
                );
                paymentActivity?.SetTag("payment.id", payment.Id);
                paymentActivity?.SetTag("payment.method", payment.Method);
            }

            // Create order
            var order = await _repository.CreateOrderAsync(request);
            activity?.SetTag("order.id", order.Id);

            return order;
        }
        catch (Exception ex)
        {
            activity?.SetStatus(ActivityStatusCode.Error, ex.Message);
            activity?.RecordException(ex);
            throw;
        }
    }
}

Ten kod automatycznie tworzy distributed trace pokazujący czas trwania każdej operacji z kontekstem biznesowym (order ID, payment method, etc).

04Prometheus i Grafana - Metryki w Praktyce

Prometheus to de facto standard dla metryk w ekosystemie Kubernetes i mikrousług. Używany przez Google, Uber, SoundCloud, DigitalOcean i tysiące innych firm.

Grafana to platforma wizualizacji, która zamienia surowe metryki w czytelne dashboardy. Razem tworzą potężny, open-source stack monitoringu używany na całym świecie.

Setup Prometheus + Grafana w Kubernetes

Jeśli używasz Kubernetes (zwłaszcza Azure AKS), najszybszy sposób to kube-prometheus-stack Helm chart - kompletny stack out-of-the-box:

# Add Prometheus Community Helm repo
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Install complete stack (Prometheus + Grafana + AlertManager + Node Exporter)
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi \
  --set grafana.adminPassword=admin123 \
  --set grafana.persistence.enabled=true \
  --set grafana.persistence.size=10Gi

# Port-forward Grafana (dev)
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

To instaluje kompletny stack w 2 minuty: Prometheus scraping metryk, Grafana z predefiniowanymi dashboardami, AlertManager dla alertów.

Kluczowe metryki do trackowania (Golden Signals)

Google SRE definiuje "Golden Signals" - 4 metryki, które mówią najwięcej o zdrowiu systemu:

1. Latency (Opóźnienie)

Jak długo trwa obsłużenie requestu

PromQL query:

# P95 latency ostatnich 5 minut
histogram_quantile(0.95,
  rate(http_request_duration_seconds_bucket[5m])
)

Alert: P95 > 500ms przez 5 minut

2. Traffic (Ruch)

Ile requestów przychodzi do systemu

PromQL query:

# Requests per second
rate(http_requests_total[5m])

Alert: Traffic wzrósł 3x powyżej baseline (możliwy atak DDoS)

3. Errors (Błędy)

Procent requestów kończących błędem

PromQL query:

# Error rate (5xx responses)
rate(http_requests_total{status=~"5.."}[5m])
/
rate(http_requests_total[5m]) * 100

Alert: Error rate > 1% przez 5 minut

4. Saturation (Nasycenie)

Jak bardzo system jest obciążony

PromQL query:

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

# Memory usage
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

Alert: CPU > 80% lub Memory > 85% przez 10 minut

Przykładowe Grafana dashboardy

Zamiast budować od zera, użyj gotowych dashboardów z Grafana Dashboards library:

•Dashboard 3662 - Prometheus 2.0 Overview
•Dashboard 1860 - Node Exporter Full
•Dashboard 7645 - Kubernetes Cluster Monitoring
•Dashboard 12708 - .NET Core / ASP.NET Core

05SLI, SLO, SLA - Mierzenie Niezawodności

Masz metryki. Masz dashboardy. Ale jak określić czy twój system jest "wystarczająco dobry"?

Tutaj wchodzi framework SLI/SLO/SLA - metodologia Google Site Reliability Engineering do obiektywnego mierzenia i zapewniania niezawodności systemów. To różnica między "czuję że system działa OK" a "wiem dokładnie jaki poziom usług gwarantuję".

SLI

Service Level Indicator

Definicja: Kwantyfikowalna miara poziomu usługi. To konkretna metryka mówiąca "jak dobrze działamy".

Przykładowe SLI:

• Availability: Procent requestów kończących sukcesem (200-299, 300-399 status)
• Latency: Procent requestów szybszych niż 300ms
• Throughput: Requests per second
• Correctness: Procent operacji dających poprawny wynik

SLO

Service Level Objective

Definicja: Cel dla SLI. To wartość mówiąca "chcemy być lepsi niż X przez Y czasu".

Przykładowe SLO (dla Order API):

→Availability: 99.9% requestów kończy sukcesem w 30-dniowym okresie
→Latency: 95% requestów szybszych niż 300ms w 30-dniowym okresie
→Durability: 99.999% zamówień zapisane poprawnie (zero data loss)

SLO określa internal target. To dla ciebie i twojego zespołu.

SLA

Service Level Agreement

Definicja: Kontrakt z klientem określający gwarancje poziomu usługi i konsekwencje ich niespełnienia.

Przykładowy SLA (dla SaaS platformy):

Uptime Commitment:

• 99.9% uptime w miesięcznym okresie rozliczeniowym
• Maksymalnie 43.2 minuty downtime/miesiąc dozwolone

Konsekwencje naruszenia:

• 99.0-99.9% uptime: 10% zwrot kosztów miesięcznych
• 95.0-99.0% uptime: 25% zwrot kosztów miesięcznych
• <95.0% uptime: 50% zwrot kosztów miesięcznych

SLA to external commitment. Ma konsekwencje prawne i finansowe.

Relacja między SLI/SLO/SLA

Kluczowa zasada: SLO powinno być bardziej restrykcyjne niż SLA. Potrzebujesz bufora.

Przykład hierarchii:

SLA:99.9% uptime (customer commitment)

↓ SLO:99.95% uptime (internal target - masz bufor 0.05%)

↓ SLI:99.97% uptime (current measurement - jesteś powyżej SLO)

Jeśli SLI spada poniżej SLO, wiesz że musisz działać zanim złamiesz SLA. To daje ci czas na reakcję.

Error Budget - Ile awarii możesz sobie pozwolić

Error budget to dopuszczalny procent błędów wynikający z SLO. To narzędzie do balansowania między niezawodnością a velocity.

Obliczanie error budget:

Jeśli masz SLO = 99.9% availability:

• Dozwolone błędy: 100% - 99.9% = 0.1%
• W 30-dniowym miesiącu (43,200 minut): 43.2 minuty downtime OK
• Przy 1M requestów/miesiąc: 1,000 błędów dozwolone

Jeśli masz error budget:

Możesz ryzykować nowe features, agresywne deploymenty, eksperymenty. Innovation > stability.

Jeśli zużyłeś error budget:

Freeze nowych features, focus na stability, code reviews bardziej rygorystyczne, więcej testów. Stability > innovation.

06Best Practices w Produkcji

1. Structured Logging - Logi jako dane, nie jako tekst

Zapomnij o plain text logach w stylu "ERROR: something failed". W 2025 każdy log to structured JSON z pełnym kontekstem - możesz agregować, filtrować i analizować logi jak database queries.

Źle - Plain text:

ERROR: Payment failed for user 123

Trudno szukać, filtrować, analizować trendy

Dobrze - Structured JSON:

{
  "level": "ERROR",
  "timestamp": "2025-11-22T14:30:00Z",
  "message": "Payment failed",
  "user_id": "123",
  "payment_method": "credit_card",
  "amount": 99.99,
  "error_code": "insufficient_funds",
  "trace_id": "abc123xyz"
}

Łatwo query, aggregate, korelować z traces

W .NET używaj Serilog z JSON sink. W Node.js - Winston lub Pino. Zawsze dodawaj trace_id do korelacji z traces.

2. Correlation IDs - Śledź requesty przez system

W systemach rozproszonych jeden request użytkownika wywołuje 10+ serwisów. Jak połączyć te wszystkie logi?

Implementacja w API Gateway:

// Generate correlation ID at entry point (API Gateway)
app.Use(async (context, next) =>
{
    var correlationId = context.Request.Headers["X-Correlation-ID"].FirstOrDefault()
        ?? Guid.NewGuid().ToString();

    context.Response.Headers.Add("X-Correlation-ID", correlationId);

    // Add to all logs in this request
    using (LogContext.PushProperty("CorrelationId", correlationId))
    {
        await next();
    }
});

// Propagate to downstream services
httpClient.DefaultRequestHeaders.Add("X-Correlation-ID", correlationId);

Teraz każdy log z tego requestu ma ten sam correlation_id. Możesz wyszukać wszystkie logi związane z konkretnym requestem użytkownika.

3. Sampling - Nie trace każdego requestu

Tracing każdego requestu to gigantyczne koszty storage i performance overhead. W produkcji sample 1-10% requestów.

Strategie samplingu:

•Random sampling: 5% losowo wybranych requestów
•Error-based: Zawsze trace requesty kończące błędem
•Latency-based: Zawsze trace wolne requesty (> 1s)
•Adaptive: Zwiększ sampling gdy error rate rośnie

4. Alert Fatigue - Nie alertuj na wszystko

Widziałem zespoły z 200+ alertami dziennie. Wynik? Ignorują wszystkie, włącznie z krytycznymi.

Dobre praktyki alertingu:

✓Alert tylko na symptomy widoczne dla użytkownika (latency, errors, downtime)
✓Każdy alert wymaga akcji - jeśli nie, to nie alert ale notification
✓Używaj severity: P1 (budzisz ludzi o 3 w nocy), P2 (handle w godzinach pracy), P3 (info)
✓Dodaj playbook do każdego alertu: "Co robić gdy dostaniesz ten alert?"

Anty-praktyki:

✗Alertowanie na transient issues (CPU spike na 10s - to może być OK)
✗Alerty bez kontekstu ("CPU high" - ale który serwis? który węzeł?)
✗Identical alerts z 10 serwisów (agreguj je w jeden)

5. Koszt Observability - To może być drogie

Full observability to 10-20% kosztów infrastruktury. Musisz balansować między widocznością a kosztami.

Przykładowe koszty (średni klaster 5 węzłów):

Prometheus (storage 30d retention, 50GB)$50/miesiąc

Grafana (persistence, 10GB)$20/miesiąc

Jaeger (traces storage, sampling 5%)$40/miesiąc

Loki (logs, 7d retention, 100GB ingestion)$80/miesiąc

Total observability stack~$190/miesiąc

Managed services (DataDog, New Relic) mogą kosztować 2-3x więcej, ale oszczędzasz czas setup i maintenance.

07Często zadawane pytania (FAQ)

Najczęściej zadawane pytania o observability i monitoring systemów produkcyjnych:

Czy mogę użyć tylko monitoringu bez full observability?

Tak, jeśli masz prosty monolit z niewielkim ruchem. Podstawowy monitoring (CPU, RAM, request count, error rate) wystarczy dla małych aplikacji. Ale jak tylko przechodzisz na mikrousługi lub masz > 50k requestów/dzień, podstawowy monitoring przestaje wystarczać - tracisz zbyt dużo czasu na debugging.

OpenTelemetry vs vendor-specific solutions (DataDog, New Relic)?

OpenTelemetry daje vendor neutrality - możesz zmienić backend bez zmiany instrumentacji. Ale wymaga więcej setup i maintenance. Vendor solutions (DataDog, New Relic) są plug-and-play, ale drogie i lock-in.

Rekomendacja: Startuj z OTel + self-hosted stack (Prometheus/Grafana/Jaeger) żeby uniknąć vendor lock-in. Jak budżet rośnie, rozważ managed service dla convenience.

Czy distributed tracing spowalnia aplikację?

Tak, ale minimalnie. OpenTelemetry dodaje <1ms overhead na request (przy sampling 100%). Z sampling 5% overhead jest praktycznie niezauważalny (<0.05ms). To akceptowalny koszt za visibility którą dostajesz. Bez tracingu, jeden incident kosztuje cię godziny debugowania.

Jak długo przechowywać metryki, logi i traces?

Standardowa strategia retention:

•Metrics: 30-90 dni high-resolution, potem downsample do niższej rozdzielczości na rok
•Logs: 7-14 dni hot storage (szybkie query), 30-90 dni cold storage (archiwum)
•Traces: 7-14 dni (duże rozmiary danych, rzadko potrzebujesz starszych)

Jakie narzędzia dla małego zespołu/startupu?

Dla zespołu <10 osób, budżet do $500/miesiąc:

Option 1: Self-hosted (najtańsze)

• Prometheus + Grafana (metrics)
• Loki (logs)
• Jaeger (traces)
• Koszt: ~$100-150/miesiąc (tylko infrastruktura)

Option 2: Managed, free tiers

• Azure Monitor / Application Insights (jeśli na Azure)
• Grafana Cloud (free tier: 10k series, 50GB logs)
• Sentry (errors tracking, free tier: 5k events/month)

Kluczowe wnioski - Observability w 2025

→
Monitoring vs Observability - nie są tym samym. Monitoring pokazuje "co", observability wyjaśnia "dlaczego". W systemach rozproszonych i mikrousługach observability to nie opcja - to konieczność.
→
Trzy filary: metryki, logi, traces - każdy daje inny widok. Metryki pokazują trendy, logi dają kontekst, distributed tracing śledzi requesty przez cały system. Wszystkie trzy razem = pełna visibility.
→
OpenTelemetry = standard przemysłowy - vendor-neutral, wspierany przez największych (Microsoft, Google, AWS). Zainwestuj w OTel teraz, oszczędzisz sobie przepisywania instrumentacji przy zmianie vendora.
→
SLI/SLO/SLA framework - obiektywny sposób mierzenia niezawodności. Error budget balansuje innovation vs stability - jak zużyjesz budget, freeze features i fixuj problemy.
→
Alert fatigue jest prawdziwy - 200 alertów dziennie = ignorujesz wszystkie. Alert tylko na to co wymaga natychmiastowej akcji i wpływa na użytkowników.
→
ROI observability jest oczywisty - koszt: 10-20% budżetu infra. Zysk: debugowanie w minutach zamiast godzinach, mniej downtime, mniejsze straty biznesowe. Jeden prevented incident zwraca miesięczny koszt stacka.

Wdrażam observability w systemach produkcyjnych

Pomagam zespołom wdrożyć kompleksowy observability stack: OpenTelemetry instrumentation dla .NET/Node.js, setup Prometheus/Grafana/Jaeger w Kubernetes, definiowanie SLI/SLO aligned z business goals, i strategię alertingu która eliminuje alert fatigue.

Od initial setup przez tuning do production-ready monitoring - skończysz z systemem gdzie debugowanie incidentów zajmuje minuty, nie godziny.

Skontaktuj się Więcej o konsultacjach

Observability i Monitoring Production Systems: Przewodnik 2025

01Observability vs Monitoring - Różnica, która ma znaczenie

Monitoring

Observability

Kluczowa różnica

02Three Pillars of Observability

Metrics - Liczby pokazujące trend

Logs - Dyskretne wydarzenia z kontekstem

Traces - Podróż requestu przez system

Jak te trzy filary współpracują w praktyce

03OpenTelemetry - Standard Observability

Czym jest OpenTelemetry (OTel)?

Dlaczego observability jest kluczowe dla systemów rozproszonych?

Praktyczna implementacja - .NET API z OpenTelemetry

Custom traces i spans

04Prometheus i Grafana - Metryki w Praktyce

Setup Prometheus + Grafana w Kubernetes

Kluczowe metryki do trackowania (Golden Signals)

Przykładowe Grafana dashboardy

05SLI, SLO, SLA - Mierzenie Niezawodności

Service Level Indicator

Service Level Objective

Service Level Agreement

Relacja między SLI/SLO/SLA

Error Budget - Ile awarii możesz sobie pozwolić

06Best Practices w Produkcji

1. Structured Logging - Logi jako dane, nie jako tekst

2. Correlation IDs - Śledź requesty przez system

3. Sampling - Nie trace każdego requestu

4. Alert Fatigue - Nie alertuj na wszystko

5. Koszt Observability - To może być drogie

07Często zadawane pytania (FAQ)

Czy mogę użyć tylko monitoringu bez full observability?

OpenTelemetry vs vendor-specific solutions (DataDog, New Relic)?

Czy distributed tracing spowalnia aplikację?

Jak długo przechowywać metryki, logi i traces?

Jakie narzędzia dla małego zespołu/startupu?

Kluczowe wnioski - Observability w 2025

Wdrażam observability w systemach produkcyjnych

Źródła