Observability — APM, Metrics, Traces

Giriş — Kara Kutudan Cam Kutuya

Bir doktor düşün. Hasta geldiğinde "karnım ağrıyor" diyor. Doktor ne yapıyor? Sadece ağrıyı dinlemiyor — kan tahlili yapıyor (metrikler), röntgen çekiyor (tracing), hastanın geçmişini inceliyor (loglar). Üç veri kaynağını birleştirip teşhis koyuyor.

Modern yazılım sistemleri de aynı. Bir kullanıcı "sayfa yavaş yükleniyor" dediğinde, sorunu bulmak için üç tür veriye ihtiyacın var:

• Logs — "Ne oldu?" (error mesajları, access logları)

• Metrics — "Sistem nasıl?" (CPU %95, memory %80, latency 2s)

• Traces — "İstek nereye gitti?" (frontend → API → DB → cache, hangi adım yavaş?)

Bu üçünü birleştirmek = Observability (gözlemlenebilirlik). Elastic Stack, bu üçünü tek platformda birleştiren en güçlü araçlardan biridir.

1. Elastic APM — Application Performance Monitoring

APM Nedir?

APM, uygulamanızın içine giren bir "ajan"dır. Her HTTP isteğini, her veritabanı sorgusunu, her dış servis çağrısını otomatik olarak izler ve ölçer.

Kullanıcı İsteği
     ↓
┌─────────────────────────────────────────────┐
│  Frontend (Browser)                          │
│  RUM Agent: page load 2.3s, FCP 0.8s        │
│  └── XHR: POST /api/checkout 1.5s           │
└──────────────────┬──────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│  API Gateway (Node.js)                        │
│  Transaction: POST /api/checkout 1.4s         │
│  └── Span: HTTP GET payment-service 0.8s      │
│  └── Span: HTTP POST inventory-service 0.3s   │
└──────────────────┬──────────────────────────┘
                   ↓
┌──────────────────────────────────────────────┐
│  Payment Service (Java)                       │
│  Transaction: POST /charge 0.7s               │
│  └── Span: DB query (PostgreSQL) 0.2s         │
│  └── Span: HTTP POST stripe.com 0.4s          │
└──────────────────────────────────────────────┘

APM Bileşenleri

APM Server Kurulumu

# APM Server kurulumu (standalone)
curl -L -O https://artifacts.elastic.co/downloads/apm-server/apm-server-8.12.0-linux-x86_64.tar.gz
tar xzvf apm-server-8.12.0-linux-x86_64.tar.gz

# apm-server.yml
# host: "0.0.0.0:8200"
# output.elasticsearch:
#   hosts: ["https://elasticsearch:9200"]
#   username: "apm_system"
#   password: "changeme"

# Başlat
./apm-server -e

Elastic Agent ile APM Server (önerilen yol):

Kibana → Fleet → Agent policies → Add integration → APM
Host: 0.0.0.0:8200
→ Save and deploy

Java APM Agent

Java agent, uygulamanın JVM'ine -javaagent parametresi ile eklenir:

# Java agent'ı indir
curl -L -O https://repo1.maven.org/maven2/co/elastic/apm/elastic-apm-agent/1.45.0/elastic-apm-agent-1.45.0.jar

# Uygulamayı agent ile başlat
java -javaagent:/path/to/elastic-apm-agent-1.45.0.jar \
  -Delastic.apm.service_name=payment-service \
  -Delastic.apm.server_urls=http://apm-server:8200 \
  -Delastic.apm.environment=production \
  -Delastic.apm.application_packages=com.mycompany \
  -jar my-application.jar

Spring Boot ile:

// build.gradle veya pom.xml'e agent dependency ekleye gerek yok
// -javaagent ile otomatik instrumentation yapılır

// Ama custom span/transaction eklemek istersen:
// pom.xml:
// <dependency>
//   <groupId>co.elastic.apm</groupId>
//   <artifactId>apm-agent-api</artifactId>
//   <version>1.45.0</version>
// </dependency>

import co.elastic.apm.api.ElasticApm;
import co.elastic.apm.api.Span;
import co.elastic.apm.api.Transaction;

@RestController
public class PaymentController {

    @PostMapping("/api/payment")
    public ResponseEntity<?> processPayment(@RequestBody PaymentRequest req) {
        // Transaction otomatik oluşturulur (agent tarafından)
        
        // Custom span ekle
        Span span = ElasticApm.currentSpan()
            .startSpan("app", "fraud-check", null);
        try {
            span.setName("Fraud Detection");
            boolean isFraud = fraudService.check(req);
            span.setLabel("fraud_result", isFraud ? "blocked" : "passed");
            span.setLabel("amount", req.getAmount());
            
            if (isFraud) {
                // Span outcome: failure
                span.setOutcome(Outcome.FAILURE);
                return ResponseEntity.status(403).body("Payment blocked");
            }
            span.setOutcome(Outcome.SUCCESS);
        } catch (Exception e) {
            span.captureException(e);
            throw e;
        } finally {
            span.end();
        }
        
        return ResponseEntity.ok("Payment processed");
    }
}

Java Agent Otomatik Instrumentation

Java agent, aşağıdaki framework'leri otomatik olarak izler:

RUM (Real User Monitoring) — Frontend APM

// Browser'da kullanıcı deneyimini izle
// npm install @elastic/apm-rum

import { init as initApm } from '@elastic/apm-rum';

const apm = initApm({
  serviceName: 'my-frontend-app',
  serverUrl: 'http://apm-server:8200',
  environment: 'production',
  
  // Distributed tracing — frontend'den backend'e trace bağlantısı
  distributedTracingOrigins: ['https://api.myapp.com'],
  
  // Custom page labels
  pageLoadTransactionName: window.location.pathname,
});

// Custom transaction
const transaction = apm.startTransaction('checkout', 'user-interaction');

// Custom span
const span = transaction.startSpan('validate-form', 'app');
validateForm();
span.end();

// Hata yakalama
try {
  riskyOperation();
} catch (error) {
  apm.captureError(error);
}

transaction.end();

RUM'un Topladığı Metrikler:

2. Distributed Tracing — İstek Takibi

Trace Kavramları

TRACE (tüm istek zinciri)
├── TRANSACTION: Frontend page load (2.3s)
│   ├── SPAN: XHR POST /api/checkout (1.5s)
│   └── SPAN: DOM render (0.3s)
├── TRANSACTION: API Gateway (1.4s)
│   ├── SPAN: Authentication middleware (0.05s)
│   ├── SPAN: HTTP GET payment-service (0.8s)
│   └── SPAN: HTTP POST inventory-service (0.3s)
├── TRANSACTION: Payment Service (0.7s)
│   ├── SPAN: DB SELECT users (0.05s)
│   ├── SPAN: DB INSERT transactions (0.1s)
│   └── SPAN: HTTP POST stripe.com (0.4s)
└── TRANSACTION: Inventory Service (0.25s)
    ├── SPAN: Redis GET stock:123 (0.01s)
    └── SPAN: DB UPDATE products (0.15s)

Kavram tanımları:

W3C Trace Context

Elastic APM, W3C Trace Context standardını destekler. Bu, farklı vendor'ların APM araçları arasında trace propagation yapılabilmesi demektir.

HTTP Header: traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
                           │  │                                │                │
                           │  trace-id (32 hex)                parent-id       flags
                           version                             (16 hex)

Service Map

Service Map, servisler arasındaki ilişkileri ve bağımlılıkları görselleştirir:

Kibana → Observability → APM → Service Map

                  ┌──────────────┐
                  │   Frontend   │
                  │   p99: 2.1s  │
                  │   err: 0.2%  │
                  └──────┬───────┘
                         │
                  ┌──────▼───────┐
                  │  API Gateway │
                  │   p99: 1.5s  │
                  │   err: 0.1%  │
                  └──┬────────┬──┘
                     │        │
           ┌─────────▼──┐  ┌─▼──────────┐
           │  Payment   │  │  Inventory │
           │  p99: 0.8s │  │  p99: 0.3s │
           │  err: 0.5% │  │  err: 0.0% │
           └──────┬─────┘  └──────┬─────┘
                  │               │
           ┌──────▼─────┐  ┌─────▼──────┐
           │ PostgreSQL │  │   Redis    │
           │   p99: 0.2s│  │  p99: 5ms  │
           └────────────┘  └────────────┘

Service Map'te:

• Düğümler: Servisler ve bağımlılıkları

• Kenarlar: Servisler arası çağrılar

• Renk: Hata oranına göre (yeşil → kırmızı)

• Kalınlık: Throughput'a göre (ince → kalın)

3. Error Tracking — Hata İzleme

Otomatik Hata Yakalama

APM agent'ları yakalanmamış exception'ları otomatik olarak toplar:

Kibana → Observability → APM → Services → payment-service → Errors

Hata listesi:
├── NullPointerException at PaymentService.java:42 (253 occurrences)
├── ConnectionTimeoutException at HttpClient.java:128 (87 occurrences)
├── InsufficientFundsException at Account.java:95 (45 occurrences)
└── ValidationException at PaymentValidator.java:23 (12 occurrences)

Error Grouping

Elastic APM, benzer hataları otomatik gruplar:

// APM'in sakladığı hata verisi
{
  "@timestamp": "2024-01-15T10:30:00Z",
  "error": {
    "exception": {
      "type": "NullPointerException",
      "message": "Cannot invoke method on null object",
      "stacktrace": [
        {
          "filename": "PaymentService.java",
          "lineno": 42,
          "function": "processPayment",
          "module": "com.myapp.payment"
        }
      ]
    },
    "grouping_key": "abc123...",
    "culprit": "PaymentService.processPayment"
  },
  "service": {
    "name": "payment-service",
    "environment": "production",
    "version": "2.3.1"
  },
  "trace": {
    "id": "0af7651916cd43dd8448eb211c80319c"
  },
  "transaction": {
    "id": "b7ad6b7169203331",
    "name": "POST /api/payment",
    "type": "request"
  }
}

Log-Trace Correlation

APM agent'ları, uygulama loglarına otomatik olarak trace ID ekleyebilir:

# application.properties (Spring Boot + Logback)
# APM agent log correlation özelliğini aç:
# -Delastic.apm.enable_log_correlation=true

# Logback pattern'ında trace bilgisi:
# %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} 
#   [trace.id=%X{trace.id} transaction.id=%X{transaction.id}] - %msg%n

Bu sayede hata logundaki trace ID'si ile APM trace'i eşleştirebilirsiniz:

2024-01-15 10:30:00 [http-nio-8080-exec-1] ERROR c.m.PaymentService 
  [trace.id=0af7651916cd43dd transaction.id=b7ad6b7169203331] 
  - Payment failed: Insufficient funds for user 12345

Kibana'da bu log satırına tıkladığınızda → doğrudan ilgili APM trace'e gidebilirsiniz.

4. Metrics — Sistem ve Uygulama Metrikleri

Metrik Tipleri

System Metrics (Elastic Agent ile)

System integration topladıkları:
├── system.cpu.total.pct                → Toplam CPU kullanımı
├── system.memory.actual.used.pct       → Gerçek memory kullanımı
├── system.filesystem.used.pct          → Disk kullanımı
├── system.network.in.bytes             → Gelen network trafiği
├── system.load.1                       → 1 dakikalık load average
├── system.process.cpu.total.pct        → Process bazında CPU
└── system.process.memory.rss.bytes     → Process bazında memory

JVM Runtime Metrics (APM Agent)

APM Java agent otomatik toplar:
├── jvm.memory.heap.used        → Heap kullanımı
├── jvm.memory.heap.max         → Max heap
├── jvm.memory.non_heap.used    → Non-heap (metaspace, code cache)
├── jvm.gc.count                → GC sayısı
├── jvm.gc.time                 → GC süresi
├── jvm.thread.count            → Thread sayısı
└── jvm.memory.heap.pool.*      → Eden, Survivor, Old Gen

Custom Metrics

// Java APM Agent ile custom metric
import co.elastic.apm.api.ElasticApm;

public class PaymentService {
    
    public void processPayment(Payment payment) {
        // Custom metric: ödeme tutarı
        ElasticApm.currentTransaction()
            .setLabel("payment_amount", payment.getAmount());
        
        // Custom counter metric (Micrometer ile)
        // meterRegistry.counter("payments.total", 
        //     "status", "success",
        //     "currency", payment.getCurrency()
        // ).increment();
    }
}

5. Elastic Synthetics — Uptime Monitoring

Synthetics Nedir?

Synthetics, uygulamanızı düzenli aralıklarla "dışarıdan" test eder. Gerçek kullanıcı olmadan, otomatik senaryolarla uptime ve performans izler.

Lightweight Monitors

# Basit HTTP check
- type: http
  name: "API Health Check"
  schedule: "@every 1m"
  urls:
    - "https://api.myapp.com/health"
  check.response:
    status: [200]
    body:
      positive: ["healthy"]
  timeout: 30s

# TCP check
- type: tcp
  name: "Database Connectivity"
  schedule: "@every 30s"
  hosts:
    - "db.myapp.com:5432"
  timeout: 10s

# ICMP check
- type: icmp
  name: "Server Ping"
  schedule: "@every 10s"
  hosts:
    - "web-server-1.myapp.com"
    - "web-server-2.myapp.com"

Browser Monitors (Synthetic Monitoring)

// Playwright-based browser test
// synthetics.config.ts

import { journey, step, monitor, expect } from '@elastic/synthetics';

journey('E-Commerce Checkout Flow', ({ page, params }) => {
  monitor.use({
    id: 'checkout-flow',
    schedule: 10,  // Her 10 dakikada bir
    locations: ['europe-west2', 'us-east1']
  });

  step('Ana sayfayı aç', async () => {
    await page.goto('https://shop.myapp.com');
    expect(await page.title()).toBe('My Shop');
  });

  step('Ürün ara', async () => {
    await page.fill('[data-testid=search]', 'laptop');
    await page.press('[data-testid=search]', 'Enter');
    await page.waitForSelector('[data-testid=product-card]');
  });

  step('Sepete ekle', async () => {
    await page.click('[data-testid=product-card] >> nth=0');
    await page.click('[data-testid=add-to-cart]');
    const cartCount = await page.textContent('[data-testid=cart-count]');
    expect(cartCount).toBe('1');
  });

  step('Checkout', async () => {
    await page.click('[data-testid=checkout-btn]');
    await page.waitForSelector('[data-testid=payment-form]');
    // Sayfa yüklendi, checkout akışı çalışıyor
  });
});

6. SLO/SLI Tracking

SLI ve SLO Nedir?

Kibana SLO Konfigürasyonu

Kibana → Observability → SLOs → Create SLO

1. SLI tanımı:
   - Indicator type: APM latency
   - Service: payment-service
   - Transaction type: request
   - Good response: < 500ms

2. SLO hedefi:
   - Target: 99.5%
   - Time window: Rolling 30 days
   - Budget policy: occurrences

3. Hesaplama:
   - İyi event: latency < 500ms olan request sayısı
   - Toplam event: tüm request sayısı
   - SLI = İyi / Toplam × 100
   - SLO: %99.5 = ayda ~3.6 saat hata bütçesi

Error Budget Hesaplama

SLO: %99.9 uptime (30 günlük rolling window)

Toplam dakika: 30 × 24 × 60 = 43,200 dakika
Hata bütçesi: 43,200 × (1 - 0.999) = 43.2 dakika

Kullanılan: 15 dakika downtime
Kalan bütçe: 43.2 - 15 = 28.2 dakika (%65.3 kalan)

Durum: ✅ SLO karşılanıyor
Hız: Bu hızla ayın %65'inde tüm bütçe tükenecek → Dikkat!

7. Log-Metrics-Traces Correlation

Üç Sütunun Birleşimi

Observability'nin gerçek gücü, log, metrik ve trace verilerini birleştirerek sorunları hızla teşhis etmektir:

Senaryo: "Checkout sayfası yavaş" şikayeti

ADIM 1: Metrics Dashboard (ilk bakış)
  → Payment service p99 latency: 2.5s (normali 0.3s)
  → CPU: %92 (normali %40)
  → Memory: %78 (normal)

ADIM 2: APM Traces (neyin yavaş olduğunu bul)
  → POST /api/payment: ortalama 2.1s
    → Span: DB query (PostgreSQL): 1.8s ← SORUNLU!
    → Span: Stripe API: 0.2s (normal)

ADIM 3: Logs (neden yavaş olduğunu bul)
  → PostgreSQL slow query log:
    "SELECT * FROM transactions WHERE user_id = 12345 
     AND created_at > '2024-01-01'
     Duration: 1.8s, Rows examined: 2,340,000"
  → EKSİK INDEX! user_id + created_at üzerinde index yok

ÇÖZÜM: CREATE INDEX idx_user_created ON transactions(user_id, created_at);

Sonuç: p99 latency: 2.5s → 0.25s 🎉

Kibana'da Correlation

Kibana → Observability → APM → Services → payment-service

1. Transactions tab: Yavaş transaction'ları gör
2. Transaction'a tıkla → Trace waterfall
3. Yavaş span'a tıkla → Span detayı
4. "View related logs" → Aynı trace ID'li loglar
5. "View in Infrastructure" → Node metrikleri
6. "View in Discover" → Ham veriyi keşfet

Ortak Alanlar (ECS)

Elastic Common Schema (ECS), tüm veri kaynaklarında ortak alan adları kullanarak correlation'ı mümkün kılar:

// Log event
{
  "@timestamp": "2024-01-15T10:30:00Z",
  "trace.id": "abc123",
  "service.name": "payment-service",
  "host.name": "server-42",
  "message": "Payment processed successfully"
}

// APM event
{
  "@timestamp": "2024-01-15T10:30:00Z",
  "trace.id": "abc123",
  "service.name": "payment-service",
  "host.name": "server-42",
  "transaction.duration.us": 250000
}

// Metric event  
{
  "@timestamp": "2024-01-15T10:30:00Z",
  "service.name": "payment-service",
  "host.name": "server-42",
  "system.cpu.total.pct": 0.45
}

trace.id, service.name, host.name gibi ortak alanlar sayesinde Kibana bu üç veriyi birleştirebilir.

8. Kibana Observability UI

Observability Menüsü

Kibana → Observability
├── Overview          → Genel sağlık durumu dashboard'u
├── Alerts            → Alertler ve kurallar
├── Cases             → Olay yönetimi
├── SLOs              → Service Level Objective izleme
│
├── APM
│   ├── Services      → Servis listesi ve sağlığı
│   ├── Traces        → Distributed trace arama
│   ├── Dependencies  → Servis bağımlılıkları
│   └── Service Map   → Görsel topoloji haritası
│
├── Infrastructure
│   ├── Inventory     → Host, container, pod listesi
│   ├── Metrics Explorer → Custom metrik sorguları
│   └── Host metrics  → Detaylı host metrikleri
│
├── Logs
│   ├── Stream        → Canlı log akışı
│   ├── Anomalies     → ML tabanlı log anomalileri
│   └── Categories    → Otomatik log kategorileri
│
└── Synthetics
    ├── Monitors      → Uptime monitor listesi
    └── Overview      → Uptime durumu

Alert Oluşturma

Kibana → Observability → Alerts → Create rule

Örnek: APM Latency Alert

Rule type: APM → Latency threshold
Service: payment-service
Transaction type: request
Environment: production

Condition:
  When: p99 latency
  Is above: 1000ms
  For the last: 5 minutes

Action:
  Connector: Slack
  Channel: #alerts-production
  Message: "🔴 Payment service p99 latency {{context.value}}ms (threshold: 1000ms)"

Örnek: Error Rate Alert

Rule type: APM → Error count threshold
Service: payment-service

Condition:
  When: error count
  Is above: 50
  For the last: 15 minutes
  Grouped by: error.exception.type

Action:
  Connector: PagerDuty
  Severity: Critical
  Summary: "High error rate: {{context.errorCount}} errors in payment-service"

9. Observability Best Practices

❌ Yapma

1. Her şeyi izlemeye çalışma — Önemli metriklere odaklan (USE/RED method)

2. Alert spam — Çok fazla alert = hiçbiri dikkate alınmaz

3. Sadece log'a güvenme — Logs + metrics + traces birlikte güçlü

4. Sampling'i kapatma — Yüksek trafikte %100 trace toplanması ES'i boğar

5. SLO'suz çalışma — Hedef yoksa iyileştirme de yok

✅ Yap

1. RED Method uygula — Rate (req/s), Errors (error%), Duration (latency)

2. USE Method uygula — Utilization (CPU%), Saturation (queue), Errors

3. Sampling kullan — Production'da %10-50 trace sampling yeterli

4. SLO tanımla — Her kritik servis için p99 latency ve error rate hedefi koy

5. Runbook bağla — Alert'e "ne yapılacağı" linkini ekle

6. ECS kullan — Tüm veri kaynaklarında ortak alan adları

Sampling Stratejisi

// APM Agent sampling ayarları
// -Delastic.apm.transaction_sample_rate=0.2  → %20 sampling

// Head-based sampling (basit)
// Her transaction başında karar verilir
// Avantaj: Basit, tahmin edilebilir
// Dezavantaj: Nadir hataları kaçırabilir

// Tail-based sampling (APM Server'da, 8.x+)
// Transaction tamamlandıktan SONRA karar verilir
// Avantaj: Hatalı ve yavaş trace'ler her zaman toplanır
// Dezavantaj: Daha fazla bellek kullanır

// apm-server.yml tail-based sampling:
// sampling:
//   tail:
//     enabled: true
//     interval: 1m
//     policies:
//       - sample_rate: 0.1    # Varsayılan %10
//       - sample_rate: 1.0    # Hatalı trace'lerin %100'ü
//         condition:
//           "or":
//             - "trace.outcome": "failure"
//             - "trace.root_transaction.duration.us":
//                 "gte": 1000000  # 1 saniyeden uzun

10. Observability Mimarisi

Tam Stack Mimari

┌─────────────────────────────────────────────────────────────┐
│                        KİBANA                               │
│  APM UI │ Infrastructure │ Logs │ Synthetics │ SLOs │ Alerts│
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│                    ELASTICSEARCH                             │
│  apm-*  │  metrics-*  │  logs-*  │  synthetics-*  │  .slo-* │
└─────────────────────────▲───────────────────────────────────┘
                          │
          ┌───────────────┼───────────────┐
          │               │               │
    ┌─────▼─────┐   ┌────▼────┐   ┌─────▼─────┐
    │ APM Server│   │  Fleet  │   │ Synthetics │
    │           │   │ Server  │   │  Agent     │
    └─────▲─────┘   └────▲────┘   └───────────┘
          │              │
    ┌─────┴─────┐   ┌────┴────────────────┐
    │ APM Agents│   │   Elastic Agents    │
    │ (app'te)  │   │ (sunucularda)       │
    │ Java,Node │   │ logs+metrics        │
    │ Python,Go │   │                     │
    └───────────┘   └─────────────────────┘

Özet

Bu derste öğrendiklerimizi toplayalım:

1. Elastic APM, uygulamanızın içine giren agent'lar aracılığıyla her HTTP isteğini, DB sorgusunu ve dış çağrıyı otomatik izler. Java agent -javaagent parametresiyle, RUM agent JavaScript ile eklenir.

2. Distributed tracing, bir kullanıcı isteğinin tüm servisler arasındaki yolculuğunu trace ID ile takip eder. Service Map bu ilişkileri görselleştirir.

3. Log-Metrics-Traces correlation, Elastic Common Schema (ECS) ortak alanları sayesinde üç veri tipini birleştirir. trace.id ile log'dan trace'e, host.name ile trace'den metriğe geçiş yapılabilir.

4. Elastic Synthetics, uygulamanızı dışarıdan düzenli olarak test eder. Lightweight (HTTP/TCP/ICMP) ve browser-based (Playwright) monitörler mevcuttur.

5. SLO/SLI tracking, servis kalitesini ölçer ve error budget hesaplar. %99.9 SLO = ayda 43 dakika hata bütçesi demektir.

6. Observability = Logs + Metrics + Traces. Üçünü birleştirmek, "karnım ağrıyor" şikayetinden "çözüm: DB index ekle" teşhisine 10 dakikada ulaşmanızı sağlar.