Dağıtık Sistemlerde Gözlemlenebilirlik ve İzleme

Gözlemlenebilirlik İzleme OpenTelemetry Mikroservisler

Bir istek beş servisten geçiyorsa ve kullanıcı “ödeme yavaş” diyorsa, sorunun hangi serviste olduğunu tahminle bulamazsınız. Gözlemlenebilirlik (observability), sistemin içinde ne olduğunu dışarıdan sorulan sorularla anlayabilmektir. Bu rehber, dağıtık bir sistemde bunu kurmanın pratik yolunu anlatıyor.

İzleme ile gözlemlenebilirlik arasındaki fark

İkisi sık karıştırılır ama farklı sorulara cevap verir.

İzleme (monitoring), bozulabileceğini önceden bildiğiniz şeyleri takip eder: işlemci kullanımı, bellek, istek gecikmesi için eşikler ve alarmlar.

Gözlemlenebilirlik, önceden tahmin etmediğiniz bir davranışın sebebini bulmanızı sağlar. “Neden bozuldu?” sorusunu, hata biçimini önceden kestirmeden cevaplayabilmektir.

Kısaca: izleme panoya bakmaktır; gözlemlenebilirlik sisteme istediğiniz soruyu sorup cevap alabilmektir.

Üç temel sinyal

Metrikler

Belirli aralıklarla toplanan sayısal ölçümler. Hafiftir, ucuzdur ve sistemin genel sağlığını bir bakışta gösterir:

İstek gecikmesi (p50, p95, p99); ortalama değil, yüzdelikler
Hata oranı ve hata türleri
Kaynak kullanımı (işlemci, bellek, disk)
İş metrikleri (saniyedeki işlem, başarılı ödeme oranı)

Kayıtlar

Tek tek olayların ayrıntılı kaydı. Metrikten farkı, bağlamı taşımasıdır: ne oldu, ne zaman, hangi istekte.

{"ts":"2026-01-15T10:23:45.123Z","level":"ERROR","service":"payment-service",
 "msg":"Sipariş işlenemedi","order_id":"12345","error_code":"INSUFFICIENT_FUNDS",
 "attempt":2,"duration_ms":234,"trace_id":"4bf92f3577b34da6a3ce929d0e0e4736"}

Yapılandırılmış (JSON) kayıt, dağıtık sistemde aramayı ve servisler arası ilişkilendirmeyi mümkün kılar. Düz metin kayıt büyük ölçekte okunamaz.

İzler

Bir isteğin sistem içindeki yolculuğu. Ödeme adımı şu yolu izleyebilir:

API geçidi isteği doğrular
Sipariş servisi siparişi oluşturur
Ödeme servisi tahsilatı yapar
Stok servisi ürünleri ayırır
Bildirim servisi onayı gönderir

İz, bu zincirin hangi halkasında ne kadar zaman harcandığını ve nerede hata çıktığını tek ekranda gösterir.

Uygulama: adım adım

1. Uygulamaları enstrümante edin

OpenTelemetry, metrik, kayıt ve iz için satıcıdan bağımsız açık standarttır. Toplanan veriyi istediğiniz arka uca gönderebilirsiniz:

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

provider = TracerProvider(resource=Resource.create({"service.name": "payment-service"}))
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317")))
trace.set_tracer_provider(provider)

FlaskInstrumentor().instrument()     # gelen HTTP istekleri
RequestsInstrumentor().instrument()  # giden HTTP çağrıları; iz bağlamı otomatik taşınır

tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("process_payment") as span:
    span.set_attribute("payment.amount_minor", 9999)
    span.set_attribute("payment.currency", "TRY")
    # ödeme mantığı

Kütüphane enstrümantasyonu iz bağlamını (W3C traceparent başlığı) servisler arasında kendisi taşır. Mesaj kuyruğu kullanıyorsanız bağlamı mesaj başlığına da eklemeyi unutmayın; yoksa iz kuyrukta kopar.

2. Kayıtları izle ilişkilendirin

Her kayıt satırına o anki iz kimliğini ekleyin. Bir hatayı kayıtta bulduğunuzda tek tıkla izine, izden de metriğe geçebilmek gözlemlenebilirliğin asıl kazancıdır:

import json, logging
from datetime import datetime, timezone
from opentelemetry import trace

def log_event(logger, level, message, **context):
    ctx = trace.get_current_span().get_span_context()
    entry = {
        "ts": datetime.now(timezone.utc).isoformat(),
        "level": level,
        "msg": message,
        "trace_id": format(ctx.trace_id, "032x") if ctx.is_valid else None,
        **context,
    }
    logger.log(getattr(logging, level), json.dumps(entry, ensure_ascii=False))

3. Toplayın ve görselleştirin

Yaygın açık kaynak yığın:

Prometheus metrik için
Tempo ya da Jaeger iz için
Loki ya da Elasticsearch kayıt için
Grafana panolar ve alarmlar için
Arada OpenTelemetry Collector: veriyi toplar, örnekler, filtreler ve arka uçlara dağıtır

İyi uygulamalar

Servis sınırında ölçün

Her servisin giriş ve çıkışı ölçülmeli. Servisler arası gecikme ve hata çoğu zaman tam bu noktalarda görünür.

İş bağlamı ekleyin, kişisel veriyi eklemeyin

Kayda sipariş kimliği, işlem türü, özellik bayrağı gibi iş bağlamı eklemek teknik ve iş ekiplerini aynı veride buluşturur. Ama e-posta, telefon, kart numarası, T.C. kimlik numarası gibi kişisel veriler kayda yazılmamalıdır. Kayıtlar genellikle uzun saklanır, geniş bir ekip tarafından okunur ve çoğu zaman yurt dışındaki bir hizmete gönderilir; bu da KVKK açısından ayrı bir işleme faaliyeti demektir. Bir kişiyi ayırt etmeniz gerekiyorsa iç kullanıcı kimliğini kullanın.

Kritik yolu derinlemesine ölçün

Fintech’te ödeme akışı, SaaS’ta kullanıcının ilk kurulumu kritik yoldur. Bu yollar diğerlerinden daha ayrıntılı enstrümante edilmelidir.

Alarm yorgunluğundan kaçının

Her alarm bir insanın işini bölmeli ve bir eylem gerektirmelidir. Bunun için:

Kullanıcının hissettiği belirtilere alarm kurun (hata oranı, gecikme), sebeplere değil (işlemci yüzde 80)
Hizmet düzeyi hedefi (SLO) tanımlayıp hata bütçesinin tükenme hızına göre alarm verin
Birden fazla sinyali birleştiren alarmlarla gürültüyü azaltın

Zorluklar

Veri hacmi. Dağıtık sistemler çok fazla telemetri üretir ve saklamak pahalıdır. Çözüm örneklemedir: hatalı ve yavaş izlerin tamamını, normal izlerin küçük bir kısmını saklamak. Bunun için kuyruk örneklemesi (tail sampling) gerekir, çünkü bir izin hatalı olup olmadığı ancak iz bittiğinde bilinir; bunu OpenTelemetry Collector yapar.

Ek yük. Enstrümantasyon performans maliyeti getirir. Veriyi toplu (batch) ve asenkron gönderin; sıcak döngülerin içinde span açmayın.

Karmaşıklık. Onlarca servisi tutarlı biçimde ölçmek zordur. OpenTelemetry’yi standart alın, kaynak öznitelikleri (service.name, deployment.environment) her serviste aynı adlarla olsun.

Kazanç

Daha kısa çözüm süresi: bağlamı zengin telemetri, sorunun yerini tahmin etmeyi gereksiz kılar
Daha erken tespit: sorunlar müşteriden önce görülür
Daha iyi deneyim: gecikmeye duyarlı işlemler ölçülür ve iyileştirilir
Veriye dayalı mimari kararları: servis bağımlılıkları ve darboğazlar görünür olur

Sonuç

Gözlemlenebilirlik sona eklenen bir özellik değil, güvenilir dağıtık sistemin temelidir. Metrik, kayıt ve izle başlayın, OpenTelemetry gibi açık standartları kullanın ve olgunluğu adım adım artırın.

Gözlemlenebilirlik yapınızı birlikte değerlendirmek isterseniz bize yazın.

ByteGurus

Yazar

Tüm yazılara dön