Bir hata anında üç farklı ekranda aynı dakikayı aramak, verilerin toplanmış olmasına rağmen birbirine bağlanmadığını gösterir. Metrik yükselmiştir, log hata yazmıştır, trace yavaş çağrıyı göstermiştir; fakat bunların aynı isteğe veya aynı servis sürümüne ait olup olmadığı belirsizdir. OpenTelemetry çalışmasının asıl değeri bu ilişkiyi kurabilmektir.
Metrikler zaman içindeki sayısal davranışı, loglar olay kayıtlarını, trace'ler ise bir isteğin işlem adımlarını görünür kılar. OpenTelemetry bu sinyallerin üretilmesi ve taşınması için ortak yapı sağlar. Verilerin saklanması ve sorgulanması için ayrıca uygun bir arka uç gerekir. Sinyallerin kapsamı OpenTelemetry belgelerinde açıklanıyor.
Ortak kimlik olmadan korelasyon zorlaşır
İlk adım her servisin tutarlı bir kimlikle veri üretmesidir. Servis adı, sürüm ve ortam bilgisi farklı kütüphanelerde başka biçimde yazılıyorsa aynı uygulama birkaç ayrı sistem gibi görünür. Bu alanlar için kısa bir ekip standardı belirlemek, yüzlerce panel hazırlamaktan önce gelmelidir.
Örneğin aynı uygulamanın test ve üretim verileri birbirine karışmamalı. Sürüm bilgisi, hata artışının bir dağıtımla ilişkili olup olmadığını araştırmayı kolaylaştırmalı. Ancak kullanıcı kimliği veya her isteğe özel değer gibi yüksek çeşitlilik oluşturan alanları gelişigüzel metrik etiketi yapmak da ayrı maliyetler doğurabilir. Hangi bilginin hangi sinyalde tutulacağı bilinçli seçilmeli.
İstek bağlamını zincir boyunca taşımak
Dağıtık trace'in bütün kalması için ilgili bağlamın servisler arasında aktarılması gerekir. Bağlam aktarımı koparsa tek kullanıcı işlemi birbirinden bağımsız izlere bölünebilir. Loglara trace ve span kimliklerinin eklenmesi de kullanılan enstrümantasyon ve log entegrasyonuna bağlıdır. Bunların otomatik olarak her dilde aynı biçimde çalıştığı varsayılmamalı. Bağlam aktarımı rehberi temel mekanizmayı açıklıyor.
Kontrol için tek bir örnek işlem seçmek yeterli olabilir: isteği başlat, ilgili trace'i bul, alt çağrıların ilişkisini incele ve aynı bağlama ait loga geç. Kuyruk üzerinden devam eden işlemlerde bağlamın mesajla nasıl taşındığı ayrıca doğrulanmalı. Göstergelerin aynı zaman aralığında hareket etmesi, tek başına nedensellik kanıtı sayılmamalı.
Daha çok veri her zaman daha iyi inceleme sağlamaz
İstek gövdesini, erişim anahtarını veya kişisel bilgiyi kayda almak kolaydır; sonradan bütün kopyalardan temizlemek zordur. Veri üretim noktasında azaltma, gerektiğinde maskeleme ve saklama politikası birlikte düşünülmeli. Baggage içine eklenen değerlerin başka servislere taşınabileceği unutulmamalı. Hassas veri işleme belgesi bu riskleri ve kullanılabilecek kontrolleri ele alıyor.
Örnekleme tercihleri de inceleme kabiliyetini etkiler. Her isteğin trace'i saklanmıyorsa aranan olayın bulunamaması, olayın yaşanmadığını göstermez. Ekip hangi verinin hangi koşulla tutulduğunu bilmeli ve alarm incelemesini buna göre yapmalı.
Pilotun başarı ölçütünü somut tutmak yararlıdır: seçilen bir kullanıcı hatasından ilgili servise, sürüme ve işlem adımına ulaşılabiliyor mu? Ardından telemetri hattının kendi hataları izlenmeli. Veri gönderimi durmuşken panelin sakin görünmesi yanlış güven yaratabilir. Küçük ama uçtan uca doğrulanmış bir akış, birbirinden kopuk büyük bir veri koleksiyonundan daha kullanışlı bir başlangıçtır.
Yorumlar (0)
Henüz onaylanmış yorum yok.