OpenTelemetry Collector ile Telemetri Filtreleme Katmanı

OpenTelemetry Collector kurulduktan sonra birçok ekip bir rahatlama yaşar: uygulamalar doğrudan backend’e bağlanmaz, veri akışı merkezî bir katmandan geçer. Fakat kısa süre içinde başka bir sorun görünür olur. Her şeyi toplamaya başlamak kolaydır; hangi sinyalin gerçekten gerekli olduğunu seçmek daha zordur. Filtreleme katmanı tam bu noktada devreye girer. Amaç veri kaybetmek değil, veri davranışını yönetmektir.

Filtreleme katmanı neden gerekli?

Collector’ı yalnızca iletim ajanı gibi kullanırsanız birkaç hafta içinde şu sonuçlar oluşur:

• Gürültülü log akışları maliyeti yükseltir
• Düşük değerli trace span’leri analizi zorlaştırır
• Debug metriği üretimde kalıcı hâle gelir
• Hassas alanlar yanlış backend’lere taşınabilir

Bu nedenle collector üzerinde karar verme sırası genelde şöyledir:

1. Tutulacak sinyali tanımla
2. Zenginleştirilecek alanları seç
3. Düşürülecek hacmi belirle
4. Hedef backend’leri ayır

Örnek mimari

Basit ama etkili bir yapı için tek collector pipeline’ını üç aşamada düşünebilirsiniz:

• Alım katmanı: OTLP, syslog veya agent çıkışları collector’a gelir
• Filtreleme katmanı: düşük değerli telemetry düşürülür, PII maskelenir
• Yönlendirme katmanı: sinyaller farklı backend’lere dağıtılır

Bu model özellikle merkezi observability kullanan kurumsal yapılarda çok işe yarar.

Örnek konfigürasyon

Aşağıdaki örnek, health-check span’lerini düşüren, belirli log alanlarını maskeleyen ve metric ile trace’i farklı hedeflere yönlendiren sade bir başlangıç verir:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  filter/drop_low_value_traces:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.route"] == "/healthz"'
        - 'attributes["http.route"] == "/readyz"'

  attributes/mask_sensitive:
    actions:
      - key: user.email
        action: delete
      - key: http.request.header.authorization
        action: delete

  resource/add_context:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert

exporters:
  otlphttp/traces:
    endpoint: https://traces.internal/v1/traces

  prometheusremotewrite/metrics:
    endpoint: https://metrics.internal/api/v1/write

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [filter/drop_low_value_traces, attributes/mask_sensitive, resource/add_context]
      exporters: [otlphttp/traces]
    metrics:
      receivers: [otlp]
      processors: [resource/add_context]
      exporters: [prometheusremotewrite/metrics]

Bu örnek her senaryoya uymaz; ama filtrenin backend tarafında değil collector katmanında uygulanmasının neden önemli olduğunu gösterir.

Hangi sinyaller filtrelenmeli?

Kural basit görünse de uygulaması zordur. Ben şu sıralamayı faydalı buluyorum:

• Yüksek hacimli health-check ve readiness çağrıları
• Analize değer katmayan debug log alanları
• Regülasyon riski taşıyan hassas kimlik alanları
• Aynı bilgiyi tekrar eden düşük değerli event’ler

Buna karşılık şu sinyalleri kolay kolay düşürmemek gerekir:

• Hata sınıfındaki span ve log’lar
• Kritik iş akışına ait transaction sinyalleri
• SLO hesabına giren metrikler
• Incident sonrası adli inceleme değeri taşıyan kayıtlar

Rollout nasıl yapılmalı?

Collector filtresini bir anda sertleştirmek risklidir. Güvenli sıralama şöyle olabilir:

1. Önce sadece sayaç üretin, düşürmeyin
2. Aday kuralları canary collector üzerinde deneyin
3. Bir backend’e tam akış, diğerine filtreli akış gönderin
4. Alarm ve dashboard kırılmalarını gözleyin
5. Sonra genel rollout yapın

Bu yaklaşım, “maliyeti düşürdük ama incident anında veri yok” senaryosunu önler.

Sonuç

OpenTelemetry Collector ile telemetri filtreleme katmanı kurmak, gözlemlenebilirlik maliyetini kısmak için aceleci bir kırpma işi değildir. Doğru yapıldığında veri kalitesini artırır, güvenlik riskini azaltır ve backend’lere giden trafiği niyetli hâle getirir. Collector’ı sadece boru hattı olarak değil karar yüzeyi olarak gördüğünüzde, observability platformu daha sürdürülebilir bir yapıya dönüşür.