2023’te OpenTelemetry

 (bit.kevinslin.com)
2 puan yazan GN⁺ 2023-08-29 | 1 yorum | WhatsApp'ta paylaş
  • 2019’da OpenTracing ile OpenCensus’ın birleşmesiyle yola çıkan OpenTelemetry, 4 yıl içinde trace, metrik ve logları kapsayan bir gözlemlenebilirlik standardı olarak yerini aldı
  • Temel yapısı spesifikasyon ve uygulamalar olarak ayrılır; vendor uyumluluğunu sağlayan ölçütleri ve gerçek enstrümantasyon/toplama araçlarını birlikte sunar
  • OTEL spesifikasyonunda 2020’de tracing, 2021’de metrikler, 2023’te loglar kararlı hale gelerek tüm sinyaller stable durumuna ulaştı; ancak log desteği SDK’lara göre hâlâ farklılık gösteriyor
  • OTLP ve Collector, gözlemlenebilirlik verilerini ortak bir formatta göndermek ve işlemek için temel oluşturur; Grafana ve Datadog gibi vendor agent’ları da bunu uygular
  • OTEL; Collector, Semantic Conventions, OpAMP, OTTL ve Demo’ya kadar kapsamını genişleterek vendor bağımsız gözlemlenebilirliğin ortak temeline dönüşüyor

OpenTelemetry’nin bugünkü konumu

  • OpenTelemetry, kısaca OTEL, 2019’da OpenTracing ile OpenCensus’ın birleşmesiyle başladı
  • Başta tracing odaklı bir projeydi, ancak birleşme sonrasında kapsamı tüm gözlemlenebilirliğe genişledi
  • Amaç, kurumların yüksek kaliteli, evrensel ve taşınabilir telemetri sunmasına yardımcı olmak
  • 4 yılın ardından OTEL şu temellere sahip hale geldi
    • Metrikler, loglar ve trace’ler için kararlı standart
    • Her ortamda telemetriyi alabilen, işleyebilen ve dışa aktarabilen Collector
    • Başlıca dillerde kod enstrümantasyonunu destekleyen SDK’lar
    • Semantic Conventions ve agent yönetimiyle ilgili ek standartlar
  • OTEL şu anda CNCF’de Kubernetes’ten sonra en aktif proje; katkıda bulunanlar başlıca gözlemlenebilirlik vendor’larının geneline yayılmış durumda ve protokolü de gözlemlenebilirlik sağlayıcıları arasında neredeyse evrensel olarak benimsenmiş durumda

Spesifikasyon ve uygulamalara ayrılan OTEL yapısı

  • OTEL genel olarak spesifikasyon (specification) ve uygulama (implementation) bileşenlerinden oluşur
  • Spesifikasyon, telemetrinin yakalanma, toplanma, işlenme ve dışa aktarılma şeklini tanımlar
    • Vendor’ların OTEL ile uyumlu olmak için izlemesi gereken ortak bir standarda yakındır
  • Uygulamalar, telemetri verileriyle çalışan istemci kütüphaneleri ve araçlardır
    • Son kullanıcıların kodu enstrümante ederken doğrudan temas ettiği kısımdır
  • Projenin kararlılığı genellikle sinyal bazında gösterilir
    • OTEL’de sinyal, metrik, log ve trace gibi telemetri veri türlerini ifade eder
  • Başlıca alt projeler şunlardır
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification, OTEL’in temelidir ve diğer OTEL standartlarına zemin oluşturan API, SDK ve veri modellerini sağlar
  • Kararlı hale gelme süreci sinyal bazında ilerler
    • Eylül 2020: tracing stable
    • Kasım 2021: metrikler stable
    • Nisan 2023: loglar stable
  • Mevcut durumda OTEL spesifikasyonu tüm sinyallerde stable durumundadır
  • Log sinyali ancak 2023’te kararlı hale geldiği için birçok OTEL SDK’sı hâlâ logları desteklemiyor

OpenTelemetry SDK ve otomatik enstrümantasyon

  • OTEL SDK, OTEL spesifikasyonuna dayalı istemci tarafı enstrümantasyon sağlar
  • Dil bazındaki her SDK’nın metrik, log ve trace sinyallerine göre ayrı olgunluk seviyesi vardır
  • Bazı SDK’lar programlama diline bağlı olarak otomatik enstrümantasyonu (auto instrumentation) destekler
    • Otomatik enstrümantasyon, SDK’nın uygulama koduna sinyalleri, ağırlıklı olarak trace’leri, otomatik olarak enjekte ederek manuel enstrümantasyon yükünü azaltmasıdır
  • go ve rust gibi derlenen dillerde otomatik enstrümantasyon çalışmaz
  • Ancak SDK dışında eBPF veya service mesh tabanlı araçlar kullanılırsa otomatik trace enjeksiyonu elde edilebilir

OTLP 1.0 ve veri aktarım standardı

  • OTLP, gözlemlenebilirlik verilerini iletmek için kullanılan ortak wire protocol’dür
  • Resmî aktarım yöntemleri ikidir
  • Bu spesifikasyon stable kabul edilir ve OTEL verilerini alan, işleyen ve dışa aktaran tüm servislerde uygulanabilir
  • OTLP, OpenTelemetry Collector tarafından uygulanır; Grafana ve Datadog gibi gözlemlenebilirlik vendor’larının agent’ları da bunu uygular

OpenTelemetry Collector 0.83.0

  • OTEL Collector, gözlemlenebilirlik verilerini toplayan, dönüştüren ve ileten vendor bağımsız bir agent’tır
  • Collector şu bileşenlerden oluşur
    • receivers: Birden fazla kaynaktan veriyi push/pull yöntemiyle alır
    • processors: Aktarım halindeki veriyi dönüştürür, filtreler, zenginleştirir ve türetir
    • exporters: Veriyi downstream hedeflere gönderir
    • connectors: Hem receiver hem exporter olarak çalışır ve birden fazla pipeline’ı birbirine bağlar
    • pipelines: Receiver, sıfır veya daha fazla processor ve exporter’dan oluşan zincirler
    • extensions: basic auth ve health check gibi telemetri işleme dışındaki işlevleri sağlar
  • Bu bileşenler birlikte gözlemlenebilirlik pipeline’ı olarak çalışır; herhangi bir kaynaktan telemetri toplayıp aktarım sırasında işleyerek istenen hedefe gönderebilir
  • Collector iki projeye ayrılır
    • otel-collector: Collector’ın yalnızca çekirdek bileşenlerini içerir; çoğunlukla OTLP veri işleme ile doğrudan ilgili mantığı barındırır
    • otel-collector-contrib: Çoğu gözlemlenebilirlik sağlayıcısı için exporter ve receiver içeren entegrasyon koleksiyonudur
  • Yazı tarihi itibarıyla otel-collector-contrib içinde 91 receiver, 48 exporter, 24 processor bulunur
  • Son kullanıcıların, yalnızca ihtiyaç duydukları bileşenleri içeren özel bir otel-collector-contrib derlemesi oluşturmak için OpenTelemetry Collector Builder kullanmaları önerilir
  • AWS ve Splunk gibi vendor’lar da kendi OTEL dağıtımlarını sunar

OpAMP ve agent’ların uzaktan yönetimi

  • OpAMP, agent’ların uzaktan yönetimi için bir ağ protokolüdür
  • 2022’de OTEL’e eklenen görece yeni bir standarttır ve agent kümelerini kontrol etmek için vendor bağımsız bir yöntem sunar
  • Yönetilen hedef otel-collector instance’ı da olabilir, OpAMP’yi uygulayan vendor’a özel bir agent da olabilir
  • OpAMP kullanılarak şu işlevler etkinleştirilebilir
    • Dinamik konfigürasyon dağıtımı
    • Agent güncellemeleri
    • Kimlik bilgisi yönetimi
  • Mevcut durumda OpAMP spesifikasyonunun Go uygulaması üzerinde çalışılmaktadır

Semantic Conventions ve ek projeler

  • OTEL Semantic Conventions, gözlemlenebilirlik verilerinde kullanılan ortak nitelik kümesini tanımlar
  • Kapsamına bulut kaynakları, veritabanları, istisnalar, sistemler ve benzerleri girer
  • Semantic Conventions, OTEL SDK’ları tarafından kullanılır; otomatik enstrümantasyonu destekleyen SDK’larda otomatik olarak uygulanır
  • Ortak semantik yapı, farklı sinyaller arasında korelasyon kurulmasını mümkün kılar
  • OTEL’in başka önemli bileşenleri de ayrı olarak bulunur
    • OpenTelemetry Transformation Language (OTTL): Telemetri için ortak bir dönüşüm dilidir; performans ve esneklik sunar, otel-collector-contrib içinde tasarlanıp uygulanmıştır
    • OTEL Demo: OTEL özelliklerinin ve dil SDK’larının çoğunu gösteren mikroservis tabanlı bir alışveriş sitesi

4 yıldaki değişim

  • OTEL, rekabet halindeki tracing spesifikasyonlarının birleşmesinden yola çıkıp gözlemlenebilirliğin endüstri standardına dönüştü
  • Geçen 4 yıl, vendor’lar ve araçlar genelinde ortak bir temel oluşturma dönemi oldu

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-29
Hacker News yorumları

  • OpenTelemetry’nin iki sorunu var

    1. Ne olduğu belirsiz. Semantik bir standart mı, protokol mü, facade mı, kütüphane mi, hangi soyutlama katmanını sunduğu muğlak; cevap ise “hepsi”ne yakın
    2. OpenTelemetry tarafında gerçekten bir kütüphaneyi enstrümante etmiş kimse yokmuş gibi görünüyor. Enstrümantasyon yapanların metrikleri, trace’leri ve log’ları nasıl kullanması gerektiğine; üçünü birden mi yoksa yalnızca birini mi kullanmaları gerektiğine dair de öneri yok. 2 yıl önce sormuştum ama cevap alamadım: https://github.com/open-telemetry/opentelemetry-specificatio...
    • Katılıyorum. Bir lavaboyu ve ona bağlı evi aynı anda vermek gibi; bu yüzden dokümantasyon da ince ve kafa karıştırıcı oluyor
      Benzer şekilde, bir masaüstü uygulamasında kullanımı anlamak için basit bir heartbeat uygulamak istemiştim; projenin adını düşününce şaşırtıcı biçimde neredeyse imkânsızdı. Sorulara verilen tepki de azdı, bu yüzden OpenTelemetry planından tamamen vazgeçtim: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • Katılıyorum. OpenTelemetry’nin önerdiği bazı şeyler gerçek SDK ile mümkün değil
      Örneğin histogramı tanımladığınız yerin yakınında bucket’ları tanımlayamıyorsunuz. Global exporter gibi bir yere, histogram adından bucket’lara eşlenen bir “override” listesi vermeniz gerekiyor. Metrik yayımlayan bir kütüphane varsa bu çok dağınık hale geliyor: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • İyi sorular ama çok önemli olduklarını düşünmüyorum. Bu tür sorulara, OpenTelemetry olsun başka bir kapalı sistem olsun, gözlemlenebilirlik alanında net cevap vermek zor
      Önde gelen gözlemlenebilirlik şirketlerinin web sitelerine baksanız bile özel enstrümantasyonla ilgili yazılar yaklaşık 4 sayfa ve yalnızca çok temel konuları ele alıyor. OTel’in özellikle geride kaldığı söylenemez; cevap çoğunlukla “duruma göre değişir”e yakın. Deneyim biriktikçe, yeni başlayanlar için kafa karıştırıcı olan bu noktalar da çözülebilir
    • Gereken şey, 3 JSON şema dosyasını bakımını yapmak kadardı
    • Üçüncü soru, ölçeklenebilir olup olmadığı

  • OpenTelemetry’yi çok seviyorum ve neredeyse tüm span’leri izlemek istiyorum. Bir vendor kullanmış olsaydım maliyet yüzünden batardım
    Java otomatik enstrümantasyonuyla neredeyse hiç çaba harcamadan OpenTelemetry’yi ekledim ve kendi barındırdığım ClickHouse’a göndererek günde 700 milyondan fazla span’i 100 dolarlık bir EC2’de saklıyorum: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • Küçük bir kişisel projede SigNoz üzerinden trace/log/metrikleri ClickHouse’a gönderiyorum. Günde yaklaşık 400 bin–800 bin span var (https://i.imgur.com/s0J6Mzo.png); tek bir t4g.small üzerinde CPU genelde %11, IOPS ise %4 seviyesinde
      Trace’ler için 1 aylık saklama bazında signoz_index_v2 26,9 milyon satırda 17.06GiB, trace_log 123 milyon satırda 2.64GiB, samples_v2 ise 949 milyon satırda yaklaşık 345MiB; sıkıştırma oranı iyi. Önerilen özelliklerde bir ClickHouse makinesi kullansaydım ayar yapma süresini azaltırdı, ama şu an da iyi çalışıyor
      Dezavantajı, küçük sc1 diskin IOPS değerinin yaklaşık 4 olması nedeniyle ClickHouse’un başlamasının 5 dakika kadar sürmesi ve SigNoz UI’ın işlev olarak yeterli olsa da Datadog seviyesinde polish beklemenin zor olması
    • Bir örnekleme oranı belirleyip hataların tamamını gönderdiğinizden emin olmalısınız
      Eski iş yerimde hata olmayan trace’lerin yalnızca %5’ini topluyorduk
    • Gerçekçi bakınca çoğu kişi kendi ClickHouse deposunu işletmek istemez ve her mühendis de SQL’i kod gibi verimli kullanamaz. Yine de oldukça hoş bir kurulum
    • Kurulum için gereken çabanın az olması da güzel. Kombinasyon Java otomatik enstrümantasyonu + ClickHouse exporter + Grafana ClickHouse eklentisi

  • OpenTelemetry’den büyük hayal kırıklığına uğradım. Deneyimlerime göre aşırı tasarlanmış, kafa karıştırıcı bir yığın ve varsayılan kullanım deneyimi son derece kullanıcı düşmanı.
    Kendini genel amaçlı bir tracing/metrik/log formatı ve ihtiyaç duyulan her şey için adaptörü olan tak-çalıştır bir kütüphane paketi gibi pazarlıyor; ama gerçekte iç uygulama ayrıntıları fazlasıyla dışarı sızan, adaptör kalitesi kötü ve fazla özelliği de olmayan yarım yamalak bir kütüphane paketine daha yakın.

    • Katılıyorum. SDK’yı her kullandığımda sağduyuya dik açıyla düşünmem gerekiyormuş gibi hissediyorum. Beklendiği gibi çalışan hiçbir şey yok; her şeyin üzerinde gereksiz 3 kat soyutlama var ve arka kapıdan yaklaşmak gerekiyor.
      Pek çok özellik, ne zaman, nerede, ne kadar, ayın evresi ne durumdayken, Jüpiter gökyüzünde görünürken ve dizge uzunluğu şu kadarken çalışacağı gibi ipuçlarına bağlı.
      Yine de sızdıran SDK API’lerini ve yarım uygulanmış özellikleri görmezden gelirseniz, değiştirilebilirlik vaadini bir ölçüde yerine getiriyor. OTel’den önce her şey özel bir stack’ti; şimdi ise tek bir standart SDK’ya farklı logging backend’leri takıp genel olarak çalışmasını bekleyebiliyorsunuz. Dikey entegre stack’lerden daha kötü ama gözlemlenebilirlik stack’inin tamamını baştan aşağı değiştirmeden parça bazında rekabet ve evrimi mümkün kıldığı için mimari açıdan kısmi bir başarı.
    • Aynı acıları yaşadım; ama OpenAPI spesifikasyonu olduğu için daha iyi olduğunu iddia eden alternatifleri deneyince de pek farklı olmadığını görüyorsunuz: https://github.com/openzipkin/zipkin-api-example
      Örnek, swagger araçlarıyla OpenAPI spesifikasyonunu (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) parse edip Go glue code’u otomatik üretiyor; ardından otomatik üretilmiş tek bir fonksiyonu çağırarak trace kaydetmeyi gösteriyor.
      Ne belge ne de başka örnek vardı; bu yaklaşımı gerçekten kullanan biri var mı diye merak ettim ve sonunda servis API’sini (https://zipkin.io/zipkin-api/#/) REST çağrılarıyla doğrudan kullanmaya başladım. OTel acı verici, ama alternatifler de daha iyi değil. SLO ve SLI ölçümü giderek önem kazandığı için bu alana daha fazla ilgi olmasını isterim.
    • Öyleyse bir alternatif önerebilir misiniz, yoksa sadece OTel’e katlanıyor musunuz merak ediyorum.
    • Somut deneyimler ve iyileştirme önerileri paylaşılabilse iyi olur.

  • OTel’in resmi kütüphaneleri web frontend’de hâlâ iyi çalışmıyor. Örneğin varsayılan durumda hataları source map’lerle ilişkilendirmenin bir yolu yok.
    OTel projesinin yayımladığı web tarayıcı collector’ı, Zone.js kullanarak tarayıcıdaki neredeyse her şeyi context olarak yakalıyor. Modern Angular kullandıysanız Zone.js’in zaman zaman oldukça sancılı olabildiğini ve global alanlara dokunarak öngörülmesi zor davranışlar yaratabildiğini bilirsiniz.
    Session replay gibi şeyler için OTel standardı olduğunu da bilmiyorum. Sentry, Rollbar, DataDog gibi pek çok telemetry platformu bunu destekliyor. Backend ekipleri bunu epey seviyor gibi; benzersiz tag’lerle tüm sistem boyunca takip edilebilen span’lerin sınır aşan niteliği hoşuma gidiyor. Ancak üretilen payload bazen çok geveze olabiliyor; bazı logging platformları daha kompakt. Pratikte bunu büyük bir sorun olarak hissetmedim.

    • Native Promise ve async/await ortamlarında Zone.js benzeri bir şeyi düzgün uygulamanın şu an bir yolu yok gibi görünüyor.
      Manuel instrumentation da denedim, ama hataya açık ve laf kalabalığı fazlaydı. Tarayıcıların da gerçekten https://nodejs.org/api/async_context.html#class-asynclocalst... gibi bir şeye ihtiyacı var.
    • Çoğu platformda Otel, iyi instrumentation kütüphaneleri oluşturmak için bir başlangıç noktasına daha yakındı.
      Bizim paketimizde Otel/Splunk tarayıcı SDK uygulamasının üstüne session replay, iyileştirilmiş exception takibi vb. ekliyoruz. Ne yazık ki bunlar varsayılan olarak sunulmaktan çok uzak. Yine de frontend session’larını backend trace/log’larıyla ilişkilendirebilmenin geliştirici deneyimini ciddi biçimde değiştirdiğini düşünüyorum: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Otel’in şu dokümanı da bakmaya değer: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      Sorunu tamamen çözmüyor ama bir başlangıç noktası sağlıyor.
    • DataDog’un frontend instrumentation’ı olan Real User Monitoring de belirgin biçimde cilalanmış değil. Duplo bloklarıyla uğraşmak kadar ince ayarlı bir deneyim.
      Frontend tracing’e az da olsa başlamış biri var mı merak ediyorum.
    • Grafana Faro’yu görüp görmediğinizi merak ediyorum. Grafana Agent’a gönderecek şekilde ayarlanabiliyor; Grafana Agent açık kaynak ve trace’leri başka bir yerde saklayabiliyor.

  • Birkaç iş arkadaşımla, artık loglara ihtiyaç kalmadığı gibi biraz tuhaf bir fikir geliştirmiştik. Log mesajları yerine span event eklemek yeterli: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    Sonra da sadece span başlığını ve Jaeger’daki ilgili span bağlantısını loglamak gibi. Bunu yalnızca kişisel projelerde denedim ama oldukça iyi hissettirdi; yalnız Jaeger UI’ın bu kullanım biçimini daha iyi desteklemesini isterdim
    Hatta o iş arkadaşlarım bu konuda bir sunum da yaptı. Almanya’da Hannover yakınlarındaysanız https://javaforumnord.de/2023/programm/ adresinde “Nie wieder Log-Files!”ı arayabilirsiniz

    • Projenin ne kadar greenfield olduğuna bağlı olarak, belirli bir işin yalnızca zaman damgasına ihtiyacınız olup süresine ihtiyacınız olmadığı durumlar dışında span event’lere bile gerek kalmayabilir
      Anlamlı tüm işler için span kullanmak, daha güçlü yapılandırılmış loglar kullanmaya benziyor. Mevcut logları da beraberinde taşımak zorunda olan birçok sistem için zor, ama yeterince greenfield ise tavsiye ederim
    • Ben de bu yaklaşımı düşündüm, ama basit araçlarla neler olduğunu kabaca anlayabilmeyi seviyorum
      Trace kullanmak için doğru çalışması gereken çok şey var. Ya da belki de henüz yeterince deneyimli olmadığım için araçlar gözümü korkutuyor
    • Bu, Stripe’ın Veneur projesinin fikriydi. Span’leri, logları ve metrikleri aynı formatta ele alıp gerektiğinde kardinaliteyi “otomatik olarak” rollup yapma yaklaşımı
      Birkaç yıl önce sunumunu gördüğümde harika olduğunu düşünmüştüm, ama SRE olmayan geliştiricileri ikna etmenin çok zor olacağını sanmıştım: https://github.com/stripe/veneur
    • Trace’leri herhangi bir yere göndermeniz de gerekmiyor. Sürecin içinde tutup, o in-memory trace verisi üzerinde API oluşturabilirsiniz
    • Aynı şeyi şirkette de konuşuyoruz. Oldukça mantıklı ve logları neredeyse tamamen ortadan kaldırabileceğimizi düşünüyorum

  • OpenTelemetry pazarlama odaklı bir proje; komite usulü tasarlanmış, safça ve verimsiz biçimde uygulanmış ve sanki ana hedefi Fortune X00 CTO’larının strateji yol haritası belgelerindeki kutucukları işaretlemesini sağlamakmış gibi görünüyor
    Seçme şansı olan birinin kullanması gereken bir şey değil

    • Bu başlıktaki diğer yorumlar genel olarak olumlu ya da çok olumlu; tam olarak neyin kötü olduğunu daha ayrıntılı duymak isterim
    • highlight.io’nun kurucusu olarak, tüketici tarafında OTEL’de çok değer gördüm. Birden fazla müşteri için dil desteğini genişletmekte kullandık ve topluluk da oldukça kapsayıcıydı
      Gönderdiğimiz değişikliklere bir örnek burada: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      Neden kimsenin kullanmaması gerektiğini düşündüğünüzü paylaşırsanız sevinirim
    • Bu değerlendirmenin doğru olmadığını düşünüyorum. Daha çok “açık kaynak yazılımlar Prometheus metrikleri ve Jaeger trace’leri yayımlıyor; biz bunların alternatifi olan tescilli bir ürün satmak istiyoruz ve her projeye patch göndermek istemiyoruz” durumuna benziyor
      Datadog gerçekten de OSS projelerine Datadog desteği ekleyen çok sayıda insan görevlendirmişti. Tanımadığınız codebase’lere dalmak güçlü bir beceri, bu yüzden kariyerin erken aşaması için oldukça iyi olmuş olabilir
      OTel, açık kaynak projelerin bir soyutlama katmanı kullanmasını sağlayarak kullanıcıların self-hosting yerine satın alabilmesine imkân veriyor. Buna pek bayılmıyorum, ama şirket dışındaki insanların işlettiği bir hizmetse artık OTel’i değerlendireceğimi düşünüyorum. Çünkü herhangi bir kullanıcı Datadog kullanmak isterse bizim buna engel olmamamızı sağlıyor
      OTel’in çok erken dönemlerinde kullandığımda Go API’si çok verimsiz olduğu için hayal kırıklığına uğramıştım. Bir counter’ı artırmak için context.Context gerekiyordu; Prometheus’a export ederken histogram bucket’larını ayarlamanın bir yolu olmaması gibi yerlerde soyutlama da sızıyordu. Şimdi muhtemelen düzeltmişlerdir diye düşünüyorum
    • Fazla sert. Veri modelinin doğru yönde atılmış bir ilerleme olduğunu düşünüyorum
      Processor da epey yetenekli, receiver ve exporter contrib koleksiyonları da genel olarak iyi. En iyi çözüm olduğunu söylemiyorum; kullanım durumuna göre değişir, ama bu kadar sert eleştirinin haklı görünmediğini düşünüyorum. Not olarak, fluent-bit bakım ekibindeyim
    • Servislerin OTLP konuşmasını sağlamak ve uygulama yapılandırmasını verileri OTEL Collector’a göndermeye indirgemek harika
      Operasyon açısından bakınca, geliştiriciler koda hangi gözlemlenebilirliği eklerse eklesin merkezi olarak filtreleme dayatabiliyorsunuz ve uygulamaların konuştuğu tek bir merkezi giriş yolu olması yetiyor
      Her şey OTLP export ettiği için yeni bir backend’e geçmek istediğinizde yalnızca YAML dosyasını değiştirmeniz yeterli; yeni bir logging backend’i desteklemek için uygulamayı yeniden yazmanız gerekmiyor. Vendor’a özgü logging kütüphaneleri kullandığımız eski yönteme dönmektense, kusurları olsa bile 10 seferin 10’unda OTEL kullanmaya devam ederim

  • Bu blogun abonelik pop-up’ından gerçekten nefret ediyorum. x düğmesi yok; e-posta vermeden kapatılabileceği hiç net değil
    Abone ol düğmesinin altında hiç sezgisel olmayan “continue reading” var; bunun çalışacağını bilmiyordum, dışarı tıklayınca da kapanmadı. Bunların daha iyi olması gerekiyor
    OpenTelemetry tarafında ise, verileri Datadog’a gönderirken ihtiyaç duyduğum tüm özellikleri sağlayıp sağlamadığını uzun zamandır denemek istiyordum. Ancak temel işlevlerin ötesinde hâlâ Datadog agent gerekiyorsa, bu yönetilmesi ve öğretilmesi gereken bir şeyin daha eklenmesi demek, o yüzden tereddüt ediyorum
    Bunu gerçekten Datadog’a bağlamış biri var mı merak ediyorum. Hedef illa Datadog’a bağlı kalmak değil, ama şu anda alarmların ve logların önemli bir kısmı orada olduğu için önce OpenTelemetry’ye geçersem teoride daha sonra başka bir şeye taşınabilirim gibi geliyor

    • O pop-up medium.com tarafının bir özelliği. Çok sinir bozucu olduğuna katılıyorum
    • Kişisel olarak anket daha kötüydü. Fikrimi sordu, seçeneklerden birine tıkladım ve ödül olarak tam ekran bir hesap oluşturma penceresi aldım
      Geri tuşuna basınca HN’ye geri döndüm

  • Gelir akışını personel, altyapı ve lisans maliyetleri açısından ciddi ölçüde aşındırmayan bir frontend hâlâ var mı merak ediyorum
    Saniyede 2.000’den fazla istek alıyoruz; yalnızca logları tutmak bile pahalı

    • Henüz yapmıyorsanız trace sampling öneririm. Datadog APM’in ucuz bir yapılandırması yok; bu yüzden pek etkileyici bulmadım
      Biz kendi Jaeger stack’imizi %0,1 örneklemeyle çalıştırıyoruz ve Datadog APM’e kıyasla maliyeti yok sayılacak düzeyde
      Metrikler ve loglar için örnekleme pek işe yaramıyor; bu yüzden iyi bir yanıt yok. Datadog’un brüt marjı %80 ise ödediğiniz tutarın altyapı maliyeti en fazla %20’dir; iş gücü maliyeti de bu %80’den düşükse, açık kaynak bir stack’i kendiniz çalıştırarak çok maliyet düşürebilirsiniz. Datadog kullanırken bile her 3 ayda bir kullanımı azaltma projesi yapıyoruz; yani nasıl olsa sürekli bakım gerektiriyor
    • Cevap sampling. Başarılı isteklerin yalnızca %1’ini örnekleyip hataların tamamını toplamak yeterli
      Maliyet de sorun ama gözlemlenebilirliğin servise beklenenden daha ağır yük bindirdiğini görünce şaşırabilirsiniz. Oldukça fazla CPU kullanıyor
    • “Ciddi”nin ölçütünü belirlemek gerekiyor. Önceki şirkette trace’leri Cassandra’ya yönlendirip AWS Elasticsearch domain’inde saklıyor, Jaeger ile görselleştiriyorduk
      Yavaş sorguları bulmaya yönelik temel raporlar oluşturmak için birkaç Elasticsearch sorgusu da yazmıştım. OTEL/Jaeger eğitimlerini izlerseniz oldukça standart bir kurulum
      Trace’ler saniyede birkaç yüz düzeyindeydi ve downsampling olmadan hepsini topluyorduk. Saklama süresi 7 gün olarak ayarlanabiliyordu; ayrıldığım sırada gerçek anlamda neredeyse hiç optimizasyon yoktu. Aylık maliyetin onlarca ila yüzlerce dolar civarında olduğunu sanıyorum
      Container’da ayarlanabilen ortam değişkenleriyle tracing sampler davranışını tanımlayabilirsiniz. Dokümantasyondaki OTEL_TRACES_SAMPLERa bakın: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • Çoğu gözlemlenebilirlik sağlayıcısı artık OTEL destekliyor. Katkıda bulunduğum OSS projesi de OTEL toplama desteği sunuyor: https://github.com/grafana/tempo/
    • Neden downvote aldığını bilmiyorum. Biz de aynı acıyı yaşıyoruz; sadece ölçeğimiz saniyede 500 bin istek
      Şu anda Datadog kullanıyoruz ama herkes çok pahalı olduğunu biliyor

  • Bu başlığın çoğu, OpenTelemetry ile metrikleri/logları kendi barındırdığınız collector işlerine gönderme hakkında
    ClickHouse gibi birçok collector aracının desteklediği standart bir kütüphane kullanmak başlı başına faydalı, ama bir başka avantajı da spesifikasyonun sistem sınırları boyunca trace ID taşımayı mümkün kılması
    Siz ve bağımlılıklarınızın tamamı OpenTelemetry spesifikasyonunu uygularsa, yolculuk sırasında neler olduğunu ayrıntılı gösteren span’ler elde edebilirsiniz. Örneğin bir sayfa yüklemesinin uzun sürmesine veritabanındaki disk sayfası yüklemesinin mi, yoksa bir bulut servisinin metadata plane span’inin yüksek gecikmeye neden olmasının mı yol açtığını anlayabilirsiniz

  • OpenTelemetry’nin ilerlemesinden çok memnunum. Birkaç yıl önce benimsemesini zorladığımda geliştiriciler yeni ve adını duymadıkları bir şey diye tereddüt ediyordu; ama bir yıl önce tekrar baktığımda OpenTelemetry sistemlerimizin her yerindeydi ve kullandığımız log/traceability sağlayıcısı da o tarafa geçiş yapıyordu