Skip to main content
Dağıtık izleme (distributed tracing), bir isteği veya işlemi enstrümante edilmiş hizmetler boyunca takip eder. Bir iz, bu işin span’lerini bir araya getirir. Her span, süresi ölçülen tek bir işlemdir: HTTP isteği, veritabanı çağrısı, kuyruk işlemi veya arka plan işi gibi. Eksik bir span, yolun bir kısmını bilinmez bırakır. Bir log hatayı bildiriyor ama işlemin yolunu göstermiyorsa bir iz kullanın. Bir iz şunları gösterebilir:
  • İsteği hangi işlemin başlattığı.
  • İsteğin zamanını nerede harcadığı.
  • Hangi alt işlemin hata döndürdüğü.
  • Hangi logların, sorunların, aksiyonların ve metriklerin aynı iz kimliğine sahip olduğu.
  • Her span’i hangi hizmetin, ortamın ve sürümün gönderdiği.

İz ve span alanları

Kök span bir izi başlatır ve üst span’i yoktur. Alt span’ler aynı iz kimliğini, kendi span kimliklerini ve bir üst kimliği taşır. İşlemleri yalnızca bu kimlikler birbirine bağlar. Zaman damgaları tek başına bağlamaz. LogBrew bir span’i yalnızca status değeri error olduğunda hata span’i olarak sayar.

Hizmetler arasında bir istek

  1. Web hizmeti, ödeme rotası için bir sunucu span’i başlatır.
  2. Ödeme istemcisi, giden HTTP isteği için bir alt span oluşturur.
  3. Ödeme hizmeti, kendi sunucu span’iyle izi sürdürür.
  4. Bir veritabanı yardımcısı, yazma işlemi için bir alt span kaydeder.
  5. Uygulama, etkin ödeme span’inin içinde güvenli bir hata logu gönderir.
Bu beş kaydın iz kimliği aynıdır. Bir hizmet iz bağlamını almazsa zamanlar örtüşse bile onun işi ize katılmaz.

Bağlamı aktarın

LogBrew SDK’ları W3C iz bağlamını kullanır. Örneğin Node.js SDK’sı, gelen geçerli bir traceparent başlığını yeni bir istek span’iyle sürdürür. Başlık yoksa veya geçersizse yeni bir kök başlatır. Bu istek kapsamında yakalanan loglar, sorunlar, aksiyonlar ve metrikler isteğin izini taşır. Giden enstrümantasyon, traceparent başlığını yalnızca tracePropagationTargets gibi ayarlarla belirlediğiniz hedeflere yazar. İz bağlamını yalnızca güvenilir ve enstrümante edilmiş hizmetlere gönderin. İz kimliği işlemleri ilişkilendirir. Kimlik doğrulama değildir. Bir kuyruk mesajı da iz bağlamı taşıyabilir. Node.js’te mesaja traceparent başlığı eklemek için üretici işlemde createLogBrewQueueTraceHeaders() fonksiyonunu çağırın. Tüketicide bu başlığı queueOperationWithLogBrewSpan() fonksiyonuna traceparent olarak verin. Bkz. JavaScript kuyruk izleri. Node.js ve Python’un istek ve giden çağrı entegrasyonları; istek veya yanıt gövdelerini, sorgu dizelerini, rastgele başlıkları ve ham traceparent değerini span’lere kaydetmez. Span’leri somut URL’lere göre değil, rota şablonlarına göre adlandırın. Çalışma ortamınızın entegrasyonları için SDK entegrasyonu rehberini okuyun.

Yakalama span’leri

LogBrew her yeni logu, sorunu, aksiyonu ve metriği bir iz kimliğiyle saklar. Bir sinyal aynı gönderimdeki bir span’e başvurmuyorsa LogBrew onun için bir yakalama span’i ekler: Bu durumda sinyalin span_id değeri yakalama span’ini tanımlar. Sinyalin iz bağlamı yoksa LogBrew onun için yeni bir iz kimliği oluşturur. Bu iz, LogBrew’ün sinyali sakladığını gösterir. Bir istek yolunu göstermez. Bir izdeki yakalama span’lerini tek bir istek gibi okumayın. Yakalama span’leri span_count ve error_span_count sayılarına dâhildir. Bu yüzden bir hata logu, hiçbir uygulama işleminin başarısız olmadığı bir izi --status error ile seçtirebilir. Sonuca varmadan önce her hata span’inin operation değerini okuyun.

Bir izi okuyun

Bir logdan, sorundan veya iz listesinden alınan kesin bir iz kimliği kullanın:
--status error en az bir hata span’i olan izleri seçer. --status ok hata span’i olmayan izleri seçer. --min-duration-ms 500 500 milisaniye veya daha uzun süren izleri seçer. Önce kök span’in süresini okuyun. Ardından en uzun alt span’leri ve hata durumlarını inceleyin. Proje, hizmet, ortam ve sürümü göz önünde tutun. Böylece bir staging izi, production hakkında kanıta dönüşmez. Bir iz tek bir yürütmeyi gösterir, bir performans temel çizgisini değil. Bir performans değişikliği önermeden önce birkaç izi ilgili metrik eğilimiyle karşılaştırın.

İz özeti

GET /api/telemetry/traces/{trace_id}/summary, span öznitelikleri olmadan bir özet döndürür: root_span.parent_span_id bir değer içeriyorsa gerçek kök span izde değildir. Bu durumda root_span değerini isteğin başlangıcı olarak okumayın.

Bir izi açıklayın

logbrew explain trace bir iz incelemesi döndürür:
analysis.causality değeri evidence_only olur. Analiz bir kök nedeni kanıtlamaz. CLI, yanıt sürümü 3’ü ister. Bu sürümde ilişkili her sorun, aksiyon ve metrik kendi kesin span_id değerini de taşır. Bir span’i üst span’i, alt span’leri ve hizmet sınırlarıyla birlikte incelemek için şunu çalıştırın:
topology.parent_chain_status, üst span zincirinin tam olup olmadığını bildirir:

Eksik iz bağlamı

Her olayın, isteğine ait bir izi yoktur. İz durumunu okuyun: not_linked bir hata değildir. available bir iz de olayın istek bağlamı olmadığını gösterebilir. Olayın yakalama span’inde parent_span_id yoksa uygulama olayı yakaladığında hiçbir span etkin değildi. İstek kapsamı dışındaki arka plan işleri genellikle bu sonucu verir. Eksik bir ilişkiyi bulmak için:
  1. Olayın projesini, hizmetini, ortamını, sürümünü ve zamanını okuyun.
  2. İşin enstrümante edilmiş bir istek veya işlem içinde çalıştığını kontrol edin.
  3. İstemci ve sunucu entegrasyonlarının bağlamı bu sınırın ötesine aktardığını kontrol edin.
  4. Enstrümantasyonu düzelttikten sonra yeni bir olay yakalayın ve okuyun.
Yeni bir SDK sürümü, daha önce gönderilmiş olaylara iz bağlamı eklemez. Bir olayı zaman damgasına, rotaya, mesaja veya sürüme bakarak bir ize bağlamayın.

Bir proje için dağıtık izlemeyi planlayın

Ödeme gibi önemli bir istekle veya işle başlayın. Her seferinde bir sınırı enstrümante edin:
  1. Gelen istek veya arka plan işlemi için bir span oluşturun.
  2. Önemli giden çağrılar için alt span’ler ekleyin.
  3. W3C iz bağlamını güvenilir hizmet sınırları boyunca sürdürün.
  4. Etkin span’in içinde güvenli bir log gönderin.
  5. Bu logu okuyun, iz kimliğini açın ve kökü, alt span’leri, hizmeti, ortamı, sürümü, durumu ve süreyi kontrol edin.
Sonraki sınırı ancak bu kontrol başarılı olduktan sonra ekleyin. Ortak bir iz ilişkiyi gösterir. Bir span’in bir soruna neden olduğunu kanıtlamaz. Span adlarını kontrol etmek için logbrew traces --project "<project_id>" --pagination cursor --json komutunu çalıştırın. naming_quality nesnesi, o sayfadaki izlerden kök adı genel olanları (generic_name_traces) ve rotası eşleşmeyenleri (unmatched_route_traces) sayar. Adlandırmanın düzeltilmesi gerekiyorsa naming_quality.next_action.code değeri improve_trace_naming olur.