Kontrol paneli yeşil olmasına rağmen müşteriler ödeme işleminin bozulduğundan şikayetçi. Eğer bu konumdaysanız, izleme ile gözlemlenebilirlik arasındaki farkı zaten anlamışsınızdır. İzlemeniz yalnızca kontrol etmeyi düşündüğünüz şeyi kontrol etti ve bu başarısızlık yeni bir şey.

Bu kılavuz, her iki fikri de pazarlama dili olmadan açıklıyor ve kurgusal bir olayı uyarıdan temel nedene kadar takip ediyor. Günlükler, izleme ve sayılar, süreci göstermek için icat edilmiştir. Ayrıca satıcıların ve uygulayıcıların bu çizgiyi farklı çizdiğini ve bazılarının bunu kısmen bir pazarlama ayrımı olarak değerlendirdiğini de bilmelisiniz. Biz pratik kısma odaklanıyoruz.

Kısa cevap

İzleme bir etkinliktir. CPU, hata oranı veya disk alanı gibi neleri izleyeceğinize önceden karar verirsiniz ve uyarıları tetikleyen eşikleri belirlersiniz. Cevap veriyor: “Endişelendiğim şey mi oldu?”

Gözlemlenebilirlik sisteminizin bir özelliğidir. Terim, bir sistemin iç durumunu dış çıktılarından ne kadar iyi çıkarabileceğinizi açıklayan kontrol teorisinden gelir. Uygulamada şu yanıtı verir: “Hiç beklemediğim sorunlar da dahil olmak üzere ne oluyor ve neden?”

Bir araba düşünün. Gösterge panosundaki uyarı ışıkları izliyor. Bilinen bir dizi sorunu kapsarlar. Bir tamircinin motorun herhangi bir parçası hakkında yeni sorular sormasına olanak tanıyan tam teşhis portu, gözlemlenebilirliğe daha yakındır.

İzleme ve gözlemlenebilirlik yan yana

Bu ikisi arasında bir seçim değil. Ne zaman bakmanız gerektiğini söyleyen uyarılara hala ihtiyacınız var.

Neden tek başına izleme yeterli değil?

Tek bir sunucudaki tek bir uygulamayla, ters gidebilecek şeylerin listesi oldukça kısa olduğundan hepsini izleyebilirsiniz. Modern bir sistemde düzinelerce hizmet, kuyruk ve üçüncü taraf API’nin yanı sıra gelip giden kapsayıcılar bulunabilir. Başarısızlıklar, kimsenin öngörmediği kombinasyonlara dönüşür: bir bölge, bir müşteri türü, belirli bir uygulama sürümü ve tek bir yavaş bağımlılık.

Düşünmediğiniz bir soru için önceden gösterge tablosu yazamazsınız. Daha sonra sormanızı sağlayacak verilere ihtiyacınız var.

Günlükler, ölçümler ve izler

Bu üç tür telemetriye genellikle gözlemlenebilirliğin temelleri denir. Her biri farklı bir soruyu yanıtlıyor:

Metrikler

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Metriklerin saklanması ucuz ve sorgulanması hızlıdır; bu da onları gösterge tabloları ve uyarılar için ideal kılar. Birçok metrik sistemde kullanıcı kimliği gibi yüksek kardinaliteli etiketlere karşı dikkatli olun çünkü bunlar maliyeti büyük ölçüde artırabilir.

İzler

Bir izleme, hizmetler genelinde bir isteği takip eder. Her adım, başlangıç zamanı ve süresi olan bir aralıktır:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Bir izleme, yavaş bir adımı açıkça ortaya koyar ve bunu ayrı hizmetlerden ayrı günlüklerde görmek çok zordur.

Günlükler

Günlükler bir anda olup bitenlerin ayrıntılarını sağlar. Bunları bir anda nasıl faydalı hale getirebileceğimize bakıyoruz.

Bir olaya ilişkin açıklama

Kurgusal bir örnekte parçaların birbirine nasıl uyduğunu burada görebilirsiniz.

İzleme 1. adımı gerçekleştirdi. Bundan sonraki her şey gözlemlenebilirlikti. Her sorunun bir önceki yanıttan nasıl geldiğine dikkat edin. Hiç kimse “bugünün kampanyasından mobil uygulama kupon sorgusu” için önceden bir kontrol paneli oluşturamazdı. Düzeltmenin kendisi için, SQL sorgu optimizasyonu kılavuzumuzda bu tür bir planın nasıl okunacağı gösterilmektedir.

Daha iyi günlükler

Düz metin günlükleri insan gözüne göre yapılmıştır ve sorgulanması zordur. Yapılandırılmış günlükler, bir makinenin filtreleyebileceği alanları kullanır:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

İkinci formla hemen “son bir saatte sağlayıcı başına kaç arıza oldu?” diye sorabilirsiniz. trace_id alanı, dokunduğu her hizmette bir günlük satırını isteğin tamamına bağladığı için özellikle değerlidir.

Hiçbir zaman şifreleri, jetonları veya kart numaralarını kaydetmeyin ve kişisel verilerinize dikkat etmeyin. Rehberimizde açıklandığı gibi, JWT’ler onları bir günlükten okuyan herkes tarafından yeniden kullanılabilir.

Altın sinyaller

Neyi izleyeceğinizden emin değil misiniz? Google’ın Site Güvenilirliği Mühendisliği kitabı, kullanıcıya yönelik sistemler için dört sinyal önerir:

Yük testi ile stres testinin karşılaştırması bölümünde gösterdiğimiz gibi, ortalamalar yavaş istekleri gizlediğinden gecikme için yüzdelik dilimleri kullanın.

İnsanların güvendiği uyarılar

Uyarılar sürekli olarak etkinleşirse insanlar bunları okumayı bırakır. İyi olanlar birkaç kurala uyar:

• Kullanıcıların hissettiği belirtilere ilişkin uyarı. “%2’nin üzerindeki ödeme hataları”, “%85’teki CPU”yu geride bırakır. Kimseye zarar vermeyen yüksek CPU kimseyi uyandırmamalı.
• Her uyarıyı uygulanabilir hale getirin. Kimsenin bir şey yapması gerekmiyorsa, bunu bir kontrol paneli öğesi haline getirin veya kaldırın.
• Runbook’a bağlantı. Yanıtlayan kişiye nereye bakacağını ve neyi deneyeceğini söyleyin.
• Bunları düzenli olarak inceleyin. Geçen ay yok sayılan uyarıları silin veya düzeltin.

Hizmet seviyesi hedefleri

Bir SLO, “site hızlı ve güvenilir olmalıdır” ifadesini “ödeme isteklerinin %99,9’u 30 gün içinde başarılı olur” gibi ölçülebilir bir hedefe dönüştürür. Bu, hata bütçesi olarak bilinen hataların yaklaşık %0,1’ine izin verir. Elinizde çok şey kaldıysa daha hızlı gönderim yapabilirsiniz, tükenmek üzereyse güvenilirliğe öncelik verebilirsiniz. Teslimat hızı ve istikrar arasındaki tartışmaları çözmenin yararlı bir yoludur.

OpenTelemetry ve araçlar

OpenTelemetry, telemetri oluşturmaya ve dışa aktarmaya yönelik açık kaynaklı, satıcıdan bağımsız bir standarttır. Cloud Native Computing Foundation’ın bir projesidir. Bununla enstrümantasyon yapmak, arka ucunuzu daha sonra kodunuzu yeniden yazmaya gerek kalmadan değiştirebileceğiniz anlamına gelir. Kendisi bir depolama veya gösterge paneli ürünü değildir, bu nedenle onu bir ürünle eşleştirirsiniz:

Bu ürünler sıklıkla değiştiğinden mevcut özellikleri ve fiyatları kendiniz kontrol edin. Veri hacmi arttıkça maliyetler hızla artabilir; bu nedenle örneklemeyi kullanın ve saklama sınırlarını belirleyin.

Nasıl başlanır?

1. En önemli hizmetiniz için altın sinyallerle başlayın.
2. Kullanıcıların fark ettiği belirtilere bir veya iki uyarı ekleyin.
3. Her satırda bir istek kimliği bulunan yapılandırılmış günlüklere geçin.
4. Otomatik enstrümantasyon birçok yaygın çerçeveyi kapsayabildiğinden, OpenTelemetry ile ana kullanıcı yolculuğunuza izleme ekleyin.
5. Dağıtımları grafiklerinize bağlayın böylece CI/CD ardışık düzeninizden bir sürümün bir değişikliğe neden olup olmadığını görebilirsiniz.
6. Her olaydan ders alın. Her olaydan sonra, hangi verilerin çözümü daha hızlı hale getirebileceğini sorun ve bunu ekleyin.

Tek bir hizmete sahip küçük bir ekibin büyük bir platforma ihtiyacı yoktur. Temel ölçümler, iyi günlükler ve birkaç uyarı yeterli olabilir. Hizmetlerin sayısı arttıkça izleme de varlığını sürdürüyor.

Yaygın hatalar

• Bir araç satın almak ve buna gözlemlenebilirlik adını vermek. Değer, iyi enstrümantasyondan ve verileri nasıl kullandığınızdan gelir.
• Üç sütunu bir kontrol listesi olarak ele almak. Bağlantı kurmanın hiçbir yolu olmayan ayrı veriler, sekmeler arasında gezinmenizi sağlar. Paylaşılan kimlikler önemlidir.
• Her şeyi toplamak. Filtrelenmemiş telemetri pahalı hale gelir ve gürültüye neden olur.
• Çok fazla kontrol paneli. Birkaç güvenilir görünüm, kimsenin açmadığı yüz görünümü geride bırakıyor.
• Test etmenin yerini aldığını düşünüyorum. Yayınlanmadan önce hâlâ testlere ihtiyacınız var. Ancak Canary bültenleri bu sinyallerle iyi bir şekilde eşleşiyor.

Son sözler

İzleme size bir şeylerin ters gittiğini söyler ve gözlemlenebilirlik size bunun nedenini bulmanın yolunu verir. Pratik test basittir: Alışılmadık bir sorun ortaya çıktığında, yeni kod göndermeden nedenini bulabilir misiniz? Bir dahaki sefere bir olayla karşılaştığınızda cevaplayamadığınız her soruyu yazın. Bu liste sizin yol haritanızdır.

Sık sorulan sorular

Öğrenmeye devam et