Takım Bazlı Telemetri Maliyet Panosu

Selamlar, bu yazımda biraz farklı bir yere bakacağız. Genelde gözlemlenebilirlik (observability) yazılarında 'şu metriği nasıl topladık', 'şu trace'i nasıl bağladık' anlatılır. Ben bu sefer faturanın geldiği tarafa bakmak istiyorum: telemetri verisi büyüdükçe gelen aylık maliyetin takım ve servis bazında nasıl görünür hale getirileceği. Çünkü görünmeyen masraf yönetilmiyor, biliyorsunuz.

Önce attribute disiplini#

Her şey, OpenTelemetry tarafında düzgün attribute koymakla başlıyor. Maliyeti takıma göre kırmak istiyorsan, span'lerin, log'ların ve metric'lerin üstünde team.name ve service.name mutlaka olmalı. Bunu kod tarafında elle yazmaya çalışmak ileride başınızı ağrıtır; bence en temizi resource attribute'larını deployment manifesto'sundan otomatik enjekte etmek. Kubernetes kullanıyorsanız Operator'ın resource attribute'larıyla halledebilirsiniz.

Buradaki kritik nokta şu: team.name değeri stabil ve kısıtlı olmalı. Bir takımın adı bugün 'payments', yarın 'odeme-takimi' olursa pano kırılır. Şahsi tavsiyem, takım kimliklerini bir yerde merkezi tutup CI'da doğrulamak.

Volume metric'lerini Collector'da üretmek#

OpenTelemetry Collector'ın count connector'ı tam olarak bu iş için var. Gateway katmanına gelen span, log ve metric data point'lerini takım/servis attribute'larına göre saydırıyoruz, sonra bunları Prometheus'a yazdırıyoruz. Aşağıda kabaca böyle bir yapılandırma:

connectors:
  count:
    spans:
      spans.total:
        description: 'Toplam span sayisi'
        attributes:
          - key: team.name
          - key: service.name
    logs:
      logs.total:
        attributes:
          - key: team.name
          - key: service.name

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
    resource_to_telemetry_conversion:
      enabled: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/backend, count]
    metrics/volume:
      receivers: [count]
      exporters: [prometheus]

Burada gözden kaçmaması gereken şey, count connector'ın hem traces pipeline'ının exporter'ı, hem de metrics/volume pipeline'ının receiver'ı olması. Yani span akışını kesmiyor, kopyasını sayıp ayrı bir metric serisi üretiyor.

Maliyeti Prometheus tarafında hesaplamak#

Volume metric'leri elimize geçtikten sonra dolar/lira hesabı recording rule'larla yapılır. Vendor'a göre birim fiyatlar değişir; benim yaptığım, fiyatları tek bir yerde sabit tutup orada güncellemek:

groups:
  - name: telemetri-maliyet
    interval: 5m
    rules:
      - record: telemetry:cost:spans:hour
        expr: |
          sum by (team_name, service_name) (
            increase(spans_total[1h])
          ) * 0.0000005

      - record: telemetry:cost:total:hour
        expr: |
          sum by (team_name) (
            telemetry:cost:spans:hour
            + telemetry:cost:logs:hour
          )

      - record: telemetry:cost:projected:monthly
        expr: telemetry:cost:total:hour * 24 * 30

Saatlik maliyeti aylığa çevirirken * 24 * 30 yapmak kabaca doğru ama trafik gün içi değişkenliği yüksek bir servis için yanıltıcı olabilir. İleri seviye için 7 günlük ortalama üzerinden projection almak daha sağlıklı.

Grafana panelleri#

Pano tarafında dört temel panelden başlamanızı öneririm: toplam aylık projeksiyon (stat), takıma göre dağılım (pie chart), günlük trend (timeseries) ve top 10 pahalı servis (bargauge). Buradaki amaç tek bir bakışta 'kim ne kadar harcıyor' sorusuna cevap vermek.

Takım liderlerine haftalık özet göndermek de işi tamamlıyor. Basit bir Python script'iyle Prometheus'a sorguyu atıp Slack'e mesaj atabilirsiniz; bunu Slack webhook'uyla halletmek 50 satırı geçmez.

Sık karşılaşılan hatalar#

• Cardinality patlatmak: team.name iyi de, oraya kullanıcı id'si veya request id'si gibi yüksek cardinality bir alan kaçarsa Prometheus'u kendi panonuzla şişirirsiniz. Sadece düşük cardinality boyutları attribute olarak sayın.
• Sampling'i unutmak: Pano size pahalı servisleri gösteriyor diye işiniz bitmiyor; tail-based sampling olmadan bazı takımların tüm error trace'leri olduğu gibi geliyor olabilir. Maliyet kırılımı sampling kararıyla beraber okunur.
• Tek pipeline'a yüklenmek: Volume saymayı production trace pipeline'ına bağlamak, count connector'ında bir hata olduğunda gerçek trace akışını da etkiler. metrics/volume ayrı bir pipeline olsun.

Kapanış#

Telemetri maliyetini görünür kılmak FinOps'un gözlemlenebilirliğe uzanması gibi bir şey aslında. Bence her ekibin kendi telemetri faturasını görmeye başlaması, log seviyesi ve metric cardinality kararlarını çok hızlı düzeltiyor; kimse panoda kırmızı görmek istemiyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.