Gözlemlenebilirlik Mimarisi Diyagramı: OpenTelemetry ile Loglar, Metrikler ve İzler

Çoğu mimari diyagram servislerde durur. Telemetri yolu daha sonra, bir olay sırasında, izlerin yarısının neden eksik olduğunu ya da log faturasının neden ikiye katlandığını anlamaya çalışan kişi tarafından çizilir. O noktada yanıt, kimsenin yazmadığı ayrıntılara bağlıdır: hangi bileşen örnekleme yapıyor, hangisi pod adını ekliyor ve bir depo yavaşladığında ne oluyor.

Gözlemlenebilirlik mimarisi diyagramı; logların, metriklerin ve izlerin her servisten nasıl çıktığını, nerede zenginleştirildiğini, örneklendiğini ve filtrelendiğini ve nerede son bulduğunu gösterir. Bu yazı Kubernetes üzerinde OpenTelemetry etrafında böyle bir diyagram kuruyor, arkasındaki agent ve gateway kalıplarını açıklıyor ve diyagramın bir sonraki kesintide de işe yaraması için neyin etiketlenmesi gerektiğini listeliyor.

Üç sinyal, üç soru

Üçü ancak bağlamı paylaştıklarında birlikte işe yarar. Log satırındaki bir trace ID ile her sinyaldeki aynı service.name ve pod adı, bir uyarıdan yavaş span'e, oradan da onu açıklayan log satırına atlamanızı sağlar. Mimari bu bağlamı bozmadan korumalıdır.

Yapı taşları

OTLP, üç sinyalin tümü için OpenTelemetry protokolüdür. Spesifikasyon varsayılan portları belirler: gRPC üzerinden OTLP için 4317, HTTP üzerinden OTLP için 4318.

SDK'lar ve otomatik enstrümantasyon her servisin içinde çalışır ve OTLP dışa aktarır. Onları bir sağlayıcıya değil, yerel bir Collector'a yönlendirin; böylece yönlendirme değişiklikleri yeniden dağıtım gerektirmez.

Collector, sinyal başına hatları olan tek bir ikili dosyadır: receiver'lar veriyi alır, processor'lar değiştirir, exporter'lar ileri gönderir. Dağıtım belgeleri onu çalıştırmanın iki ana yolunu anlatır:

• Agent. Bir Collector uygulamanın yanında çalışır: sidecar olarak ya da düğüm başına bir pod'lu bir DaemonSet olarak. Kubernetes'te agent, Kubernetes bileşenlerinin işini yaptığı yerdir de: Kubernetes Attributes Processor pod, ad alanı ve deployment adlarını ekler, Filelog Receiver konteynerlerin stdout ve stderr çıktısını izler, Kubeletstats Receiver da düğüm ve pod metriklerini çeker.
• Gateway. Bir ya da daha fazla Collector bağımsız bir servis olarak çalışır; tipik olarak küme, veri merkezi ya da bölge başına bir uç nokta. Gateway, bir kez vermek istediğiniz kararların yeridir: örnekleme, hassas niteliklerin filtrelenmesi, depo kimlik bilgilerinin tutulması ve birden fazla depoya gönderim.

Head ya da tail sampling

İzler pahalı sinyaldir, bu yüzden çoğu ekip onları örnekler. Head sampling iz başladığında karar verir, örneğin yüzde 10'unu tutar. Ucuzdur, ancak bir izi daha sonra başarısız oldu diye tutamaz. Tail sampling bir izin span'lerinin tamamını ya da çoğunu gördükten sonra karar verir; böylece her hatayı ve her yavaş isteği tutabilir.

Tail sampling'in yapısal bir bedeli vardır: bir izin tüm span'leri aynı Collector'a ulaşmalıdır. Round-robin bir yük dengeleyicinin arkasında bu olmaz. Gateway kalıbı bunu iki katmanla çözer: ilk katman yönlendirme anahtarı trace ID olarak ayarlanmış load-balancing exporter'ı, ikinci katman da tail sampling processor'ı çalıştırır. Bu diyagramda iki kutu demektir ve ikisini de göstermeye değer.

Örnek: Kubernetes üzerinde bir mağaza

Mağaza, bir shop ad alanında üç Deployment çalıştırır: her biri OpenTelemetry SDK'lı web, checkout-api ve payments-worker. observability ad alanı hattı barındırır: bir otel-agent DaemonSet'i, span'leri trace ID'ye göre yönlendiren bir otel-lb Deployment'ı ve tail sampling politikasını uygulayan bir otel-sampler Deployment'ı. Metrikler, izler ve loglar her biri kendi deposuna gider ve uyarı kuralları metrikler üzerinde çalışır.

Nasıl okunur:

• Sol, servisler. Her Deployment izleri, metrikleri ve logları OTLP/gRPC ile 4317 portundan kendi düğümündeki agent'a aktarır. Kesikli kenar konteyner stdout'udur; agent onu ağ üzerinden almaz, düğümden okur.
• Orta, agent. Agent her şeye Kubernetes meta verisini ekler, ardından metrikleri ve logları doğrudan depolarına, izleri ise gateway'e gönderir.
• Orta, gateway. otel-lb her span'i trace ID'ye göre yönlendirir; böylece bir izin tüm span'leri aynı otel-sampler pod'una ulaşır. O da hataları ve yavaş izleri tutar, geri kalanını örnekler.
• Sağ, depolama ve uyarılar. Her sinyalin kendi deposu vardır. Uyarı kuralları metrikleri okur ve nöbetçi kişiyi çağırır.
• Markdown bloğu, örnekleme politikasını ve her hattın uyduğu tek kuralı belirtir: önce memory limiter.

Neler etiketlenmeli

• Her adımda protokol ve port. OTLP/gRPC 4317 ya da OTLP/HTTP 4318 ve her depoya giden dışa aktarım biçimi.
• Her kenarda hangi sinyallerin taşındığı. Tek bir hat nadiren üçünü de aynı şekilde taşır.
• Örneklemenin nerede yapıldığı ve politikası. Sayıları yazın; yalnızca "örneklenmiş" demek yanlış varsayımlara davetiye çıkarır.
• Verinin nerede zenginleştirildiği ya da maskelendiği. Kubernetes meta verisi agent'ta, token'ların ve kişisel verilerin çıkarılması gateway'de.
• Her depo için saklama süresi. Maliyeti ve bir incelemenin hâlâ neler bulabileceğini açıklar.
• Hata davranışı. Bir depo çöktüğünde kuyruklar, yeniden denemeler ve neyin düşürüldüğü.

Yaygın hatalar

• Doğrudan bir sağlayıcıya aktaran SDK'lar. Her yönlendirme ya da kimlik bilgisi değişikliği yeniden dağıtıma dönüşür ve veri dışarı çıkmadan önce filtrelenecek bir yer kalmaz.
• Düz bir yük dengeleyicinin arkasında tail sampling. Bir izin span'leri farklı Collector'lara düşer ve örnekleme kararları parçalar üzerinden verilir.
• Memory limiter olmaması. Yapılandırma belgeleri bir memory_limiter processor'ı içerir; onu her hattın başına koyun ki bir ani artışta Collector belleği tüketmek yerine veriyi reddetsin.
• Yüksek kardinaliteli metrik etiketleri. Metrik etiketi olarak bir kullanıcı ID'si ya da istek ID'si zaman serilerini katlar. Bunları span'lere ve loglara koyun.
• İzlenmeyen bir hat. Collector, dahili telemetri belgelerinde anlatıldığı gibi kendi metriklerini varsayılan olarak 8888 portunda sunar. Başarısız dışa aktarımlar için uyarı kurun; yoksa kaybolan veriyi, ona ihtiyaç duyduğunuz olay sırasında fark edersiniz.

Kümenin kendisi için Kubernetes mimari diyagramı kontrol düzlemini, düğümleri ve iş yüklerini; mikroservis mimari diyagramı da bu hattın gözlemlediği servisleri ele alır.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Kubernetes paketinden iki Namespace çerçevesi ekleyin: shop ve observability. shop içine her servis için bir Deployment koyun.
3. observability içine agent için bir DaemonSet, yük dengeleme ve örnekleme katmanları için de iki Deployment ekleyin.
4. DevOps paketinden depolar için Metrikler, İzler ve Loglar düğümlerini, uyarılar için bir Uyarı düğümü ekleyin.
5. Bunları bağlayın ve her kenarı sinyallerle ve protokolle etiketleyin, örneğin "OTLP/gRPC 4317". Konteyner log kenarını kesikli yapın.
6. Örnekleme politikasıyla bir Temel paketi Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Servisleriniz zaten Kubernetes üzerinde çalışıyorsa Kubernetes YAML'dan diyagrama aracı manifest'leri sol yarının ilk taslağına dönüştürür.

SSS

Bir gateway Collector'a ihtiyacım var mı, yoksa agent'lar yeterli mi? Küçük kurulumlarda yalnızca agent'lar iş görür. Tail sampling'e, kimlik bilgileri ve filtreleme için tek bir yere ya da birden fazla depoya ihtiyacınız olduğunda bir gateway ekleyin; agent veriyi o zaman ona iletir.

Loglar da Collector'dan geçmeli mi? Geçebilir. Agent'taki Filelog Receiver konteyner loglarını okur, izler ve metriklerle aynı Kubernetes meta verisini ekler ve depolamadan önce filtrelemenizi sağlar. Birçok ekip logları Collector'a en son, izlerden ve metriklerden sonra taşır.

Head sampling hiç yeterli olur mu? Evet; trafik düşükse ya da her iz birbirine benziyorsa. Her hatayı ve yavaş isteği tutmanız gerekiyorsa tail sampling kullanın ve gerektirdiği iki gateway katmanını çizin.

Panolar ve uyarılar diyagramda nereye ait? Sorguladıkları deponun yanına. Metrikler üzerindeki uyarı kuralları mimarinin parçasıdır: kimin uyandırılacağına onlar karar verir.

Bu diyagramı nasıl güncel tutarım? Onu Collector yapılandırmasıyla aynı pull request'te değiştirin ve runbook'tan bağlantı verin. Eskimeyen mimari diyagramlar yazısına bakın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.