OpenTelemetry ile İzleme: Log, Metrik ve Trace Ne İşe Yarar?

Üç sinyali aynı şey için kullanmayın

Metrik zaman içindeki sayısal değişimi, log belirli olay bağlamını, trace ise bir işlemin bileşenler arasında izlediği yolu açıklamaya yardımcı olur. OpenTelemetry bu sinyallerin toplanması ve ilişkilendirilmesi için bir çerçeve sunar. [1] Her sorunu daha fazla log yazarak çözmeye çalışmak uygun olmayabilir.

Önce cevaplamak istediğiniz soruları yazın. Siparişler neden yavaş, hangi sürümde hata arttı ve belirli müşteri işi nerede kaldı? Sinyal seçimi bu sorulara göre yapılmalıdır. Veri toplamakla araştırılabilir bilgi üretmek aynı şey değildir.

Teknik isteği ticari işle ilişkilendirin

Bir sipariş oluşturma işi web isteği, kuyruk, ERP çağrısı ve bildirim içeriyor olabilir. Bu adımların ortak işlem referansı yoksa ekip farklı günlüklerde elle arama yapmak zorunda kalır. İş referansı ile trace kimliğinin ilişkisi tasarlanabilir; kişisel verileri kimlik olarak kullanmayın.

Kuyrukta uzun süre bekleyen işte web isteği çoktan bitmiştir. Bu yüzden yalnızca HTTP yanıt süresi yeterli değildir. Bekleme süresi, işleme süresi ve doğrulanmış tamamlanma ayrı ölçülebilir. Müşteriye görünen durum bu teknik gerçekle uyuşmalıdır.

Örnek: ödeme sonrası sipariş ekranı bekliyor

Varsayımsal kullanıcı ödeme sonrası uzun süre sonuç göremiyor. Web sunucusunun ortalama yanıtı normaldir, fakat ERP çağrıları belirli ürünlerde uzuyordur. İzleme sadece sunucu CPU’suna bakıyorsa sorun anlaşılmayabilir. İşlem izi hangi adımda bekleme olduğunu gösterebilir.

Bu tablo, belirli bir izleme ürününün her hatayı otomatik bulacağı anlamına gelmez. Sinyaller doğru toplanmalı ve iş bağlamıyla yorumlanmalıdır.

Etiketleri sınırsız büyütmeyin

Her kullanıcı veya sipariş kimliğini metrik etiketi yapmak çok sayıda benzersiz seri oluşturabilir. Ayrıntılı işlem araştırmasıyla toplu ölçümün ihtiyaçları farklıdır. Metrik boyutlarını sınırlı ve anlamlı seçin; ayrıntılı referansları uygun kayıt veya izleme katmanında tutun.

Örnekleme kullanılıyorsa hangi izlerin tutulduğu ve hangilerinin tutulmadığı bilinsin. Kayıt bulunmaması işlemin hiç gerçekleşmediğini her zaman kanıtlamaz. Özellikle hata araştırma ve müşteri açıklamalarında veri kapsamını açıkça belirtin.

Hassas veriyi gözlem bahanesiyle çoğaltmayın

Parolalar, erişim anahtarları ve gereksiz kişisel içerik loglara taşınmamalıdır. OWASP günlük rehberi hassas bilgi ve kayıt erişimi kontrollerini ele alır. [2] İstek gövdesinin tamamını otomatik yazmak yerine gerekli alanları seçmek değerlendirilebilir.

İzleme sistemine kimlerin eriştiği ve verinin ne kadar tutulduğu proje kapsamına dahil olsun. Üçüncü taraf izleme kullanılıyorsa gönderilen veri ve bağlantı koşulları ayrıca değerlendirilmelidir. Gözlemlenebilirlik yeni bir kontrolsüz veri deposu oluşturmamalıdır.

Teslimde bir olayın araştırılmasını isteyin

Örnek bir yavaşlık veya kontrollü hata üretip ilgili metriği, işlem izini ve kaydı birlikte bulun. Ekip hangi müşterilerin etkilendiğini ve hangi işlerin yeniden ele alınması gerektiğini açıklayabilsin. Sadece hazır dashboard ekran görüntüsü yeterli teslim kanıtı değildir.

Alarmın sorumlusu, anlamı ve ilk müdahale adımı yazılı olsun. Her küçük dalgalanmada alarm üretmek, önemli uyarıların görülmesini zorlaştırabilir. İzleme kapsamı ürün değiştikçe güncellenmeli; kullanılmayan sinyaller ve gereksiz maliyetler düzenli gözden geçirilmelidir.

Sık sorulan sorular

### OpenTelemetry tek başına logları saklar mı? Toplama ve enstrümantasyon çerçevesi ile verinin saklandığı ve incelendiği arka uç ayrı değerlendirilebilir. Kullanılan mimarinin bu parçaları açıkça tanımlanmalıdır.

Daha çok log her zaman daha iyi teşhis sağlar mı?

Hayır. Gürültü, maliyet ve hassas veri riski artabilir. Doğru referanslarla ilişkilendirilmiş gerekli kayıtlar daha değerlidir.