Observability projelerinde en hızlı “kazanım” genelde en hızlı “borç” da üretir: Her yere bir agent kur, her şeyi tek bir hedefe akıt, sonra maliyet ve gürültü patlayınca toparlamaya çalış. OpenTelemetry Collector ise bunu tersine çevirmek için iyi bir fırsat: Collector’ı “agent” değil, telemetri omurgası gibi tasarladığınızda; maliyeti, güvenliği ve operasyonu yönetilebilir hale getirirsiniz.
Bu yazı; Collector’ı production’da kullanırken benimsediğim tasarım prensiplerini ve pratik konfigürasyon zihniyetini anlatır (ürün bağımsız).
Hedef: “Tek bir vendor” değil “tek bir pipeline”
Collector’ın asıl gücü şu cümlede:
Telemetri üretimi ile telemetri tüketimini birbirinden ayır.
Böylece:
- Uygulamalar vendor SDK’larına gömülmez
- Yeni bir backend’e geçiş “kod refactor” değil “pipeline değişikliği” olur
- Sampling, redaction, enrichment merkezi yönetilir
Dağıtım modeli: Agent mı, Gateway mi?
Collector için iki temel model var:
1) Agent (node/host başına)
- Artı: Kaynağa yakın; network bağımlılığı az.
- Eksi: Konfig dağıtımı zor; güvenlik ve governance dağılıyor.
2) Gateway (merkezi / cluster içi servis)
- Artı: Policy, routing, sampling merkezi yönetilir.
- Eksi: Gateway bir “kritik servis” olur; kapasite ve HA şart.
Pratikte en sağlıklı model genelde hibrit:
- Node başına lightweight agent: log/metric ingest, basic enrichment
- Merkezi gateway: tail sampling, redaction, multi-destination routing
Pipeline tasarım prensipleri
Collector konfigürasyonunu “bir dosya” değil; bir mimari kararlar seti olarak düşünün:
1) Veri sınıfları: Log/Metric/Trace ayrı hayat yaşar
- Log: hacim büyük, maliyet yüksek, arama/retention kritik
- Metric: SLO/alert için temel, kardinalite riski var
- Trace: debugging için değerli ama sampling şart
Bu üç veri türüne aynı politika uygulanmaz.
2) Enrichment: “context” eklemek pahalı ama değerlidir
Örn. service.name, deployment.environment, k8s.namespace.name, cloud.region.
Ama enrichment, cardinality patlatabilir. Etiket eklerken iki soru:
- Alert/SLO’da kullanacak mıyım?
- Boyutu (unique value sayısı) kontrol edilebilir mi?
3) Redaction: Gizli veri sızdırmayın
Trace attribute’larında token, e-posta, TCKN gibi veriler çok kolay sızar.
Redaction için:
- Regex tabanlı mask (kaba ama hızlı)
- Allowlist attribute stratejisi (daha güvenli)
4) Sampling: “her şeyi topla” değil, “değerli olanı topla”
Sampling’i ikiye ayırın:
- Head sampling: istemci tarafında (basit ama kör)
- Tail sampling: gateway’de (kural bazlı: error, latency, route)
Production’da hata/latency odaklı tail sampling çok işe yarar.
Örnek akış: Çoklu hedef (prod + güvenlik + arşiv)
Gerçek dünyada telemetri tek hedefe gitmez:
- Operasyon ekibi: APM/metrics backend
- Güvenlik: SIEM (özellikle audit log)
- Maliyet: soğuk arşiv / kısa retention
Collector ile bunu “routing” olarak modelleyin:
- Audit log’ları ayrı pipeline
- PII içeren alanlar redacted
- Trace’lerde error odaklı sampling
Operasyon: Collector’ı da gözlemleyin
Collector; üretim için kritik bir servis haline gelince onu izlemek şart:
- Queue dolulukları, retry sayıları
- Dropped spans/logs/metrics
- Exporter latency ve error rate
- CPU/mem ve GC basıncı
Kural: “telemetri boru hattı” bozulduğunda, sistem görünmez olur. Bu yüzden Collector alarmları; uygulama alarmları kadar önemlidir.
Versiyonlama ve değişiklik yönetimi
Konfig drift’i ve “kural karmaşası” Collector projelerini bitirir. Benim pratik yaklaşımım:
- Konfigleri IaC gibi yönet (PR + review)
- Ortam ayrımı: dev/stage/prod
- Her değişiklikte “beklenen etki” notu (hangi veri, hangi hedef, hangi maliyet)
- Geri dönüş planı (rollback)
Kapanış: Collector’ı bir “platform” olarak sahiplenin
OpenTelemetry Collector, doğru tasarlanırsa observability’yi “ürünlerden” bağımsızlaştırır ve maliyet/güvenlik kararlarını merkezileştirir.
Başlamak için küçük bir hedef öneririm:
- Gateway ile trace tail sampling’i devreye alın (error + latency)
- Audit log’ları ayrı pipeline’a ayırın
- Redaction politikasını baştan koyun
- Collector’ın kendi metrikleri için dashboard + alarm açın