Observability vs Monitoring – Kluczowe różnice w monitorowaniu systemów

Czym jest Monitoring?

Monitoring to praktyka systematycznego zbierania, analizowania i alarmowania o predefiniowanych metrykach systemowych. To reaktywne podejście – reagujemy na znane problemy gdy już wystąpią.

Klasyczny monitoring sprawdza:
– **Wykorzystanie zasobów** – CPU, RAM, dysk
– **Dostępność serwisów** – czy endpoint odpowiada
– **Podstawowe metryki biznesowe** – liczba użytkowników, transakcji
– **Logi błędów** – известные pattern błędów

Czym jest Observability?

Observability to właściwość systemu, która określa jak dobrze można zrozumieć jego wewnętrzny stan na podstawie zewnętrznych sygnałów. To proaktywne podejście – pozwala odkrywać nieznane problemy.

Observability opiera się na trzech filarach:
1. **Metrics** – numeryczne pomiary w czasie
2. **Logs** – zdarzenia z kontekstem czasowym
3. **Traces** – śledzenie żądań przez cały system

Dlaczego to ważne w 2020?

W erze mikrousług i systemów rozproszonych tradycyjny monitoring staje się niewystarczający. Aplikacje składają się z dziesiątek serwisów, kontenerów i zewnętrznych zależności.

**Kluczowe trendy 2020:**
– **Kubernetes** staje się standardem – zwiększa złożoność
– **Service mesh** (Istio, Linkerd) wymaga nowych podejść
– **Cloud-native** aplikacje generują ogromne ilości danych
– **DevOps teams** potrzebują szybszego debugowania

Co się nauczysz?

Wymagania wstępne

Kluczowe różnice – porównanie

Praktyczny przykład – E-commerce system

Wyobraź sobie sklep internetowy z mikrousługami: User Service, Product Service, Order Service, Payment Service.

Scenariusz: Spadek konwersji o 15%

**Podejście Monitoring:**
„`bash
# Sprawdzamy podstawowe metryki
CPU usage: 45% ✓
Memory usage: 60% ✓
Response time: 200ms ✓
Error rate: 0.1% ✓

# Wszystko wygląda normalnie, ale konwersja spada!
„`

**Podejście Observability:**

// Trace analysis pokazuje:
{
  "traceId": "abc123",
  "spans": [
    {
      "service": "payment-service",
      "operation": "process-payment",
      "duration": "8.2s",  // Normalnie 200ms!
      "tags": {
        "payment.provider": "stripe",
        "user.country": "PL"
      }
    }
  ]
}

**Odkrycie:** Payment Service ma 8-sekundowe opóźnienia dla polskich użytkowników z powodu konfiguracji Stripe dla regionu EU.

Implementacja Observability – Three Pillars

1. Metrics – Prometheus + Grafana

// Spring Boot z Micrometer (2020)
@RestController
public class OrderController {
    
    private final Counter orderCounter = Counter.builder("orders.created")
        .description("Number of orders created")
        .tag("service", "order-service")
        .register(Metrics.globalRegistry);
    
    private final Timer orderProcessingTime = Timer.builder("orders.processing.time")
        .description("Order processing duration")
        .register(Metrics.globalRegistry);
    
    @PostMapping("/orders")
    public ResponseEntity createOrder(@RequestBody CreateOrderRequest request) {
        return Timer.Sample.start(Metrics.globalRegistry)
            .stop(orderProcessingTime, () -> {
                Order order = orderService.createOrder(request);
                orderCounter.increment();
                return ResponseEntity.ok(order);
            });
    }
}

2. Logs – Structured Logging

// Logback configuration dla structured logs
{
  "timestamp": "2020-03-25T10:30:45Z",
  "level": "INFO",
  "service": "order-service",
  "traceId": "abc123",
  "spanId": "def456",
  "userId": "user-789",
  "orderId": "order-101",
  "message": "Order created successfully",
  "duration": 250,
  "paymentMethod": "stripe"
}

3. Traces – Distributed Tracing

// Spring Cloud Sleuth configuration (2020)
@Configuration
public class TracingConfiguration {
    
    @Bean
    public Sender sender() {
        return OkHttpSender.create("http://jaeger-collector:14268/api/traces");
    }
    
    @Bean
    public AsyncReporter spanReporter() {
        return AsyncReporter.create(sender());
    }
    
    @Bean
    public Tracer tracer() {
        return BraveTracer.create(
            Tracing.newBuilder()
                .localServiceName("order-service")
                .spanReporter(spanReporter())
                .build()
        );
    }
}

Narzędzia dostępne w 2020

Monitoring Tools

Observability Platforms

**Kompletny stack 2020:**
– **Metrics:** Prometheus + Grafana
– **Logs:** ELK Stack (Elasticsearch + Logstash + Kibana)
– **Traces:** Jaeger lub Zipkin
– **Orchestration:** Kubernetes + Helm

Kiedy używać którego podejścia?

Wybierz Monitoring gdy:

– **Prosty monolityczny system** z przewidywalnymi failure modes
– **Ograniczony budżet** na narzędzia i infrastructure
– **Stabilne systemy** gdzie znasz wszystkie potencjalne problemy
– **Compliance requirements** wymagają podstawowego monitoringu

Wybierz Observability gdy:

– **Mikrousługi i systemy rozproszone** z kompleksowymi interakcjami
– **Częste deployments** z nowymi feature’ami
– **Unknown unknowns** – nie wiesz co może pójść źle
– **High-traffic applications** gdzie performance ma kluczowe znaczenie

Implementacja step-by-step

Krok 1: Zacznij od Metrics

# docker-compose.yml - Prometheus setup
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.17.0  # Latest w 2020
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      
  grafana:
    image: grafana/grafana:6.7.0  # Latest w 2020
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

Krok 2: Dodaj Structured Logging

Krok 3: Włącz Distributed Tracing

# application.yml - Spring Cloud Sleuth
spring:
  sleuth:
    sampler:
      probability: 0.1  # Sample 10% requests w production
    zipkin:
      base-url: http://jaeger-collector:9411
  application:
    name: order-service

Koszty i performance impact

Najlepsze praktyki 2020

1. Stopniowe wprowadzanie

– Zacznij od kluczowych serwisów
– Dodawaj instrumentację iteracyjnie
– Monitoruj koszty na bieżąco

2. Sampling strategies

// Intelligent sampling w Jaeger
@Configuration
public class TracingConfig {
    
    @Bean
    public ProbabilisticSampler probabilisticSampler() {
        // Sample więcej w development, mniej w production
        return new ProbabilisticSampler(
            "production".equals(environment) ? 0.01f : 0.1f
        );
    }
}

3. Alert fatigue prevention

**Zasada:** Alert tylko na business-impacting events:
– **SLI violations** (Service Level Indicators)
– **Error budget** przekroczenia
– **Critical user journeys** problemy

Przyszłość – trendy na 2020+

Następne kroki

Przydatne zasoby

• Prometheus Documentation
• Jaeger Tracing Documentation
• Google SRE Book – Monitoring Distributed Systems
• Spring Cloud Sleuth Reference
• ELK Stack 7.6 Documentation

Używasz już observability w swoich projektach? Jakie największe wyzwania napotkałeś przy implementacji? Podziel się doświadczeniami w komentarzach – inne zespoły mogą skorzystać z Twoich lekcji!