Logging, Monitoring & Observability

Bu bölümde prod ortamında sistemi sağlıklı tutmak için kullandığımız üç temel kavramı ele alıyoruz:

Logging: Olayları kaydeder
Monitoring: Sistemin sağlığını metriklerle izler
Observability: Metrik + log + trace ile sistemin “neden”ini açıklayabilmeyi sağlar

1) Logging

Logging Nedir?

Logging, sistemde gerçekleşen olayları, hataları ve kritik adımları kaydetme pratiğidir. Bir sorun çıktığında ilk baktığımız yer çoğu zaman loglardır.

Basit projelerde console.log yeterli görünebilir; ancak production sistemlerde logların:

seviyelendirilmesi
kategorize edilmesi
merkezi toplanması
aranabilir ve filtrelenebilir olması

gerekir.

Log Seviyeleri

INFO: Genel sistem olayları (server başladı, kullanıcı login oldu)
WARN: Kritik olmayan ama takip edilmesi gereken durumlar
ERROR: Acil müdahale gerektiren hatalar (DB bağlantısı koptu vb.)
DEBUG: Geliştirme aşamasında detaylı teşhis logları

Structured Logging

Production’da logları düz metin yerine JSON formatında tutmak gerekir. Çünkü bu format:

makineler tarafından kolay parse edilir
ELK gibi sistemlerde hızlıca aranır ve filtrelenir
correlation id gibi alanları standart şekilde taşır

Örnek (Winston):

const winston = require("winston");

const logger = winston.createLogger({
  level: "info",
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "app.log" })
  ]
});

logger.info("Server started on port 3000");
logger.error("Database connection failed");

Neden Logging Yapıyoruz?

Debugging Hata nerede oluştu sorusunun en hızlı cevabı loglardır.
Audit ve Güvenlik Kim, ne zaman, hangi IP ile ne yaptı gibi bilgileri geriye dönük doğrulamak gerekir.
Davranış Analizi Kullanıcı hangi endpointleri ne sıklıkla çağırıyor, sistem hangi akışlarda yoğunlaşıyor gibi ürün kararları için veridir.
Performans Takibi Request sürelerini loglayarak darboğazları yakalarsın.

Graceful Shutdown

Production’da süreç kapanırken loglar ve aktif istekler yarım kalabilir. Bunu yönetmek için graceful shutdown uygulanır.

Tipik akış:

SIGTERM geldiğinde yeni istek kabul edilmez
mevcut isteklerin bitmesi için süre tanınır
DB bağlantıları, Redis ve log altyapısı kapatılır
process sonlandırılır

Container (Docker/Kubernetes) dünyasında graceful shutdown yapılmazsa kullanıcı deneyimi bozulabilir ve veri tutarsızlığı riski doğar.

2) Monitoring

Monitoring Nedir?

Monitoring; CPU, RAM, response time, error rate gibi metrikleri izleyerek sistemin kararlı çalışmasını sağlamaktır.

Monitoring üç ana parçadan oluşur:

Metrics: Sayısal ölçümler (RPS, CPU, RAM, latency)
Health Checks: /health, /ready gibi endpointler
Alerting: Eşik aşılınca bildirim (Slack, SMS, email)

Health Check Neden Önemli?

Sunucu açık olabilir ama sistem sağlıklı olmayabilir. Örneğin:

DB bağlantısı yoksa
Redis çökmüşse
disk dolmuşsa

servis trafik almamalıdır.

İzlenen Temel Kaynaklar

CPU Sürekli yüksekse ağır iş yükü, sonsuz döngü veya GC baskısı olabilir.

RAM Heap sürekli artıyorsa memory leak ihtimali yüksektir.

GC Süresi Garbage collector uzun sürerse uygulama duraksar ve latency artar.

Araçlar: Prometheus & Grafana

Prometheus metrikleri toplar ve saklar. Grafana bu verileri dashboard’a çevirir.

Prometheus metrik toplamak için scraping endpointi ister (örn. /metrics). Node.js tarafında prom-client gibi araçlarla metrik üretilebilir.

const client = require("prom-client");

client.collectDefaultMetrics({ register: client.register });

const orderCounter = new client.Counter({
  name: "total_orders",
  help: "Toplam başarılı sipariş sayısı"
});

module.exports = { client, orderCounter };

Dört Altın Sinyal (Golden Signals)

Latency: Response süreleri
Traffic: İstek sayısı (RPS)
Errors: Hata oranı
Saturation: Kaynak doygunluğu (CPU/RAM/disk)

Percentile’lar kritik: P50 tek başına yeterli değildir, P95/P99 gerçek kullanıcı deneyimini gösterir.

3) Observability

Observability Nedir?

Observability, sistemin dışarı verdiği sinyallerden (metric, log, trace) içeride ne olduğunu ve neden olduğunu çıkarabilme yeteneğidir.

Monitoring: Sistem çalışıyor mu
Observability: Sistem neden böyle davranıyor

Observability üç sütuna dayanır:

Metrics Sorun var mı sorusunu hızlıca yanıtlar.
Logs Ne oldu sorusunu detaylandırır.
Traces Sorun nerede takıldı sorusunu netleştirir. Özellikle mikroservislerde kritik.

Tracing Temelleri

Trace ID: Bir request’e girişte verilir, tüm servislerde taşınır
Span: Request içindeki alt adımlar (DB sorgusu, external API çağrısı vb.)

Tracing, gecikmenin hangi servis ve adımda oluştuğunu gösterir.

Üretimde Hızlı Teşhis Akışı

Prod’da bir problem gördüğünde doğru sıralama şudur:

1) Metric (0–30 sn)

Sistemik bir problem var mı, ne zaman başladı, deploy ile ilişkili mi

2) Log (30 sn – 2 dk)

Hata nerede oluşuyor: stack trace, timeout, external API 429, OOM gibi sinyaller

3) Trace (2–4 dk)

En yavaş span nerede, hangi servis bekletiyor, downstream mi biz miyiz

4) Aksiyon (4–5 dk)

Rollback, feature flag kapatma, scale, timeout ayarı, cache açma gibi müdahaleler

Bu sıralama değişmez:

Metric → Log → Trace

Production’da refleks değil, metodoloji kazanır. Rastgele log aramak yerine sinyali daraltarak ilerlemek, dakikalar içinde kök sebebe ulaşmanı sağlar. Gerçek operasyonel olgunluk burada başlar.

Conclusion

Logging, Monitoring ve Observability genellikle araçlar üzerinden anlatılır. Ama production gerçekliği şunu gösterir: mesele araç değil, yaklaşım biçimidir.

Log tutmak tek başına görünürlük sağlamaz. Metrik toplamak tek başına güven vermez. Trace almak tek başına kök sebep buldurmaz.

Gerçek fark; bu üç sinyali birlikte, bilinçli ve sistematik şekilde kullanabilmektir.

Production problemleri rastgele debug edilmez. Daraltılır, ölçülür, iz sürülür ve netleştirilir.

Observability; “çalışıyor mu?” sorusundan “neden böyle davranıyor?” sorusuna geçiştir.

Ve bu geçiş, sistem büyüdükçe opsiyonel değil, zorunludur.

Key Takeaways

Logging bir kayıt mekanizmasıdır, teşhis stratejisi değildir
Monitoring alarm üretir, açıklama üretmez
Observability üç sinyalin birlikte tasarlanmasıdır
Metric → Log → Trace sırası bir alışkanlık değil, metodolojidir
Operasyonel olgunluk araç seçimiyle değil, sinyal okuma disipliniyle gelir