PromptWake
← Blog
·13 min

Gözlemlenebilirlik ve İzleme: Mühendislik Ekipleri İçin Kapsamlı Rehber

Gözlemlenebilirlik konusunda pratik bir derinlemesine inceleme — üç temel yapı taşı, OpenTelemetry, yapılandırılmış loglama, dağıtık izleme, uyarı stratejileri, SLI/SLO çerçeveleri ve üretim verilerini birinci sınıf bir varlık olarak ele alan bir kültürün nasıl inşa edileceği.

Her mühendislik ekibi üretim sistemlerini izler. Ancak çok azı "sistem neden bu şekilde davranıyor?" sorusuna uzun bir hata ayıklama seansı olmadan yanıt verebilir. İzleme ile gözlemlenebilirlik arasındaki fark bir araç seçimi değildir — ekibinizin bilinmeyen hata modlarını ne kadar hızlı anlayıp yanıt verebileceğini belirleyen bir tasarım felsefesidir.

Geleneksel izleme, neyi izleyeceğinizi bildiğinizi varsayar. CPU eşikleri belirler, uç nokta durum kodlarını kontrol eder ve disk kullanımı %90'ı aştığında birini ararsınız. Bu, bilinen hata modları için işe yarar. Ancak modern dağıtık sistemler, hiçbir panelin öngörmediği şekillerde başarısız olur: bir servisteki ince gecikme regresyonu bir kuyruk birikmesine yol açar, bu da yalnızca yoğun trafik altında ortaya çıkan bir veritabanı bağlantı havuzu tükenmesi olarak kendini gösterir. Sisteminizin iç durumu hakkında rastgele sorular sorabilme yeteneğiniz olmadan kör uçuş yapıyorsunuz demektir.

Gözlemlenebilirlik Neden Temel İzlemenin Ötesine Geçer

Gözlemlenebilirlik, bir sistemin dış çıktılarından iç durumunu çıkarsamanıza olanak tanıyan bir özelliktir. İzleme size bir şeyin yanlış olduğunu söyler. Gözlemlenebilirlik, o belirli hata modunu hiç tahmin etmemiş olsanız bile neyin yanlış gittiğini hata ayıklamanızı sağlar. Ayrım çok önemlidir: izleme uyarı odaklı ve panoya bağlıdır; gözlemlenebilirlik sorgulama odaklı ve veri açısından zengindir.

Sisteminiz loglar, metrikler ve izler arasında yüksek kardinaliteli yapılandırılmış veri yaydığında, olayları ilişkilendirebilir, belirli kullanıcılara veya isteklere derinlemesine inebilir ve hiçbir eşik tabanlı uyarının yakalayamayacağı olayların kök nedenini keşfedebilirsiniz. Gözlemlenebilirliğe yatırım yapan ekipler, ortalama çözüm süresini bir kat azaltır çünkü tahmin yürütmekten daha az, kanıtlara dayanarak hareket etmekten daha fazla zaman harcarlar.

"İzleme size bir sistemin çalışıp çalışmadığını söyler. Gözlemlenebilirlik, neden çalışmadığını sormanızı sağlar. İkincisi, tam olarak anlamadığınız sistemleri işletmek için bir ön koşuldur — ki bu da her üretim sistemidir."

Üç Temel Yapı Taşı: Loglar, Metrikler ve İzler

Gözlemlenebilirlik ekosistemi, her biri farklı bir amaca hizmet eden üç tamamlayıcı veri türü üzerine inşa edilmiştir. Bunları ayrı silolar yerine birleşik bir sinyal olarak ele almak, etkili hata ayıklamanın anahtarıdır.

Loglar: Olayların Değişmez Kayıtları

Loglar, ayrık olayların zaman damgalı kayıtlarıdır. En ayrıntılı gözlemlenebilirlik sinyalidir ve belirli bir zaman noktasında tam olarak ne olduğunu yakalarlar. İyi yapılandırılmış bir log satırı, birden fazla kaynak arasında ilişkilendirme yapmaya gerek kalmadan yürütme yolunu yeniden yapılandırmak için yeterli bağlamı içerir — istek kimliği, servis adı, süre, hata detayları.

Ekiplerin loglarla yaptığı en yaygın hata, onları yapılandırılmamış metin olarak ele almaktır. Üç sunucunuz varken düz dosyalarda grep yapmak işe yarardı. Ölçekte, yapılandırılmamış loglar gürültüdür. Her log satırı ayrıştırılabilir olmalı, yapılandırılmış meta veriler içermeli ve mimarinizdeki her serviste tutarlı bir şemayı takip etmelidir.

Metrikler: Zaman İçinde Toplu Ölçümler

Metrikler, sisteminizin durumunun aralıklarla ölçülen sayısal temsilleridir. Verimli depolama ve hızlı toplama için tasarlanmıştır. Metrikler "saniyede kaç istek?" ve "p99 gecikmesi nedir?" gibi soruları yanıtlar. Logların aksine, metrikler bireysel istek verilerini atar — ayrıntı düzeyini sıkıştırma ve hız karşılığında takas ederler.

Standart metrik türleri — sayaçlar, göstergeler, histogramlar ve özetler — her biri farklı kullanım durumlarına hizmet eder. Sayaçlar toplam istek sayısı gibi kümülatif değerleri izler. Göstergeler, bellek kullanımı gibi anlık değerleri kaydeder. Histogramlar, gecikme dağılımları için gözlemleri yapılandırılabilir aralıklara örnekler. Doğru metrik türünü seçmek, yanıltıcı toplamaları ve boşa harcanmış kardinaliteyi önler.

İzler: Uçtan Uca İstek Yaşam Döngüleri

Dağıtık izler, tek bir isteğin servis sınırları boyunca yayılırken izini sürer. Her iz, belirli bir servis veya işlev tarafından yapılan işi yakalayan, başlangıç ve bitiş zaman damgalarına sahip adlandırılmış işlemler olan yayılımlardan oluşur. İzler, bir mikroservis mimarisinde bir isteğin tam yaşam döngüsünü yeniden yapılandırabilen tek sinyaldir.

İzler olmadan, yavaş bir sayfa yüklemesi, ilgili düzinelerce servisten herhangi birine atfedilebilir. İzlerle, darboğazın 800 milisaniye süren kullanıcı-servisi veritabanı sorgusu olduğunu, diğer tüm yayılımların 50 milisaniyenin altında tamamlandığını belirleyebilirsiniz. Bu hassasiyet, yalnızca loglar veya metriklerle imkansızdır.

"Loglar size ne olduğunu söyler. Metrikler size kaç kez olduğunu söyler. İzler size her şeyin nasıl bir araya geldiğini söyler. Varsayımlarda bulunmadan bir üretim olayında gezinmek için üçüne de ihtiyacınız var."

OpenTelemetry Kurulumu ve Enstrümantasyonu

OpenTelemetry, telemetri verilerini oluşturmak, toplamak ve dışa aktarmak için endüstri standardıdır. Log, metrik ve iz verilerini satıcıdan bağımsız bir formatta yayan, diller arası tek bir API ve SDK seti sağlar. OpenTelemetry'i benimsemek, satıcı bağımlılığını ortadan kaldırır ve enstrümantasyonunuzun Datadog, Grafana, Honeycomb veya şirket içi bir boru hattı kullanmanızdan bağımsız olarak çalışmasını sağlar.

Otomatik ve Manuel Enstrümantasyon

Çoğu OpenTelemetry SDK'sı otomatik enstrümantasyonu destekler — popüler çerçevelere ve kütüphanelere sıfır kod müdahalesi. Tek bir başlatma çağrısıyla HTTP sunucuları, veritabanı istemcileri, mesaj kuyrukları ve gRPC çağrıları enstrümante edilebilir. Otomatik enstrümantasyon yaygın yolları kapsar, ancak iş açısından kritik kod yolları, özel ara yazılımlar ve alana özgü işlemler için manuel enstrümantasyon gereklidir.

import { NodeSDK } from "@opentelemetry/sdk-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-grpc";
import { OTLPMetricExporter } from "@opentelemetry/exporter-metrics-otlp-grpc";
import { HttpInstrumentation } from "@opentelemetry/instrumentation-http";
import { ExpressInstrumentation } from "@opentelemetry/instrumentation-express";
import { PgInstrumentation } from "@opentelemetry/instrumentation-pg";
import { Resource } from "@opentelemetry/resources";
import { SEMRESATTRS_SERVICE_NAME } from "@opentelemetry/semantic-conventions";

const sdk = new NodeSDK({
  resource: new Resource({
    [SEMRESATTRS_SERVICE_NAME]: "payment-service",
  }),
  traceExporter: new OTLPTraceExporter({
    url: "http://otel-collector:4317",
  }),
  metricExporter: new OTLPMetricExporter({
    url: "http://otel-collector:4317",
  }),
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
    new PgInstrumentation(),
  ],
});

sdk.start();
process.on("SIGTERM", () => sdk.shutdown());

OpenTelemetry Toplayıcı Mimarisi

OpenTelemetry Toplayıcı, telemetri verilerini alan, işleyen ve dışa aktaran satıcıdan bağımsız bir proxy'dir. Herhangi bir üretim gözlemlenebilirlik boru hattının bel kemiğidir. Her bir sunucuya veya Kubernetes altyapınızda bir küme olarak bir toplayıcı dağıtmak, enstrümantasyonu arka uç seçiminden ayırarak, verileri gözlemlenebilirlik platformunuza ulaşmadan önce toplu olarak işlemenize, filtrelemenize, örneklemenize ve dönüştürmenize olanak tanır.

Toplayıcılar, sağlıklı trafiğin çoğunu atarken yüksek gecikmeli veya hatalı istekler için tam izleri saklayan kuyruk tabanlı örneklemeyi işleyen işlemcilerle yapılandırılabilir. Bu, en önemli istekler için hata ayıklama yeteneğinden ödün vermeden depolama maliyetlerini önemli ölçüde azaltır.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  filter:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.target"] == "/healthz"'
        - 'attributes["http.target"] == "/metrics"'
  attributes:
    actions:
      - key: environment
        value: production
        action: upsert

exporters:
  otlp:
    endpoint: "api.honeycomb.io:443"
    headers:
      "x-honeycomb-team": "${HONEYCOMB_API_KEY}"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, filter, batch, attributes]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp]

Yapılandırılmış Loglama Desenleri

Yapılandırılmış loglama, log girdilerini makine tarafından ayrıştırılabilir bir formatta — tipik olarak JSON — ve servisler arasında tutarlı alan adlarıyla yayınlamak anlamına gelir. Logları bir arama sorunundan bir sorgu sorununa dönüştürür. Her ekip, istek kimlikleri, servis adları, hata kodları ve süreler için aynı alan kurallarını kullandığında, özel ayrıştırıcılar yazmadan tüm altyapınızda anlık sorgular çalıştırabilirsiniz.

Loglar için Şema Tasarımı

Her yapılandırılmış log olayı asgari bir dizi nitelik içermelidir: zaman damgası, önem düzeyi, servis adı, iz kimliği, yayılım kimliği ve mesaj. Bunların ötesinde, alana özgü alanlar ekleyin ancak adlandırma kurallarını zorunlu kılın. Örneğin, her zaman camelCase kullanın, kullanıcıyla ilgili alanları user ile önekleyin ve hata ayrıntılarını mesaj dizesine birleştirmek yerine iç içe bir hata nesnesinde saklayın.

  • Logları izlerle ilişkilendirmek için her zaman trace_id ve span_id ekleyin
  • Geliştirici rahatlığına değil, eyleme dönüştürülebilir sinyallere karşılık gelen bir log düzeyi (debug, info, warn, error) kullanın
  • Geliştirme ortamlarında bile hassas verileri — PII, sırlar veya belirteçler — asla loglamayın
  • Log mesajlarını statik tutun ve değişken verileri toplamayı etkinleştirmek için yapılandırılmış alanlara koyun
  • Tüm servislerde zaman damgası biçimini RFC 3339 veya Unix milisaniye olarak standartlaştırın

Yaygın Yapılandırılmış Loglama Tuzakları

En maliyetli loglama hatası çok fazla loglamaktır. Kullanıcı kimlikleri veya IP adresleri gibi yüksek kardinaliteli alanlar, log hacmini katlanarak artırabilir. Yüksek hacimli hata ayıklama logları için örnekleme stratejileri kullanın ve ayrıntılı loglamayı belirli iz kimlikleri veya hata koşulları için saklayın. İkinci hata, tutarsız alan adlandırmasıdır — bir servis user_id, diğeri customerId ve üçüncüsü user.id kullandığında, dönüşüm katmanları olmadan servisler arası sorgular imkansız hale gelir.

"Sorgulanamayan bir log satırı var olmasa da olur. Yapılandırılmış loglama okunabilirlikle ilgili değildir — her log girdisini gözlemlenebilirlik platformunuzda birinci sınıf bir vatandaş yapmakla ilgilidir."

Mikroservislerde Dağıtık İzleme

Dağıtık izleme, mikroservis mimarilerinde hata ayıklamak için en etkili araçtır. Yirmi servise yayılan bir iz, zamanın nerede harcandığını, hangi isteklerin başarısız olduğunu ve hataların nasıl yayıldığını tam olarak gösterir. İzler olmadan, yavaş bir ödeme akışını hata ayıklamak, bir düzine servisteki logları kontrol etmek ve nedensellik hakkında tahmin yürütmek anlamına gelir.

İz Bağlamı Yayılımı

İz bağlamı, her servis sınırı boyunca yayılmalıdır — HTTP başlıkları, mesaj kuyruğu meta verileri, gRPC meta verileri ve hatta zamanlanmış işler veya arka plan çalışanları gibi async sınırlar boyunca. OpenTelemetry, HTTP, gRPC ve mesajlaşma çerçeveleri için enstrümantasyon kütüphanelerini kullandığınızda bunu otomatik olarak halleder. İz kimliği, giriş ağ geçidinden her alt servise doğru akar ve yol boyunca yayılımları toplar.

  • Tüm giriş noktalarını enstrümante edin: API ağ geçitleri, yük dengeleyiciler, giriş denetleyicileri
  • Mesaj kuyrukları aracılığıyla iz bağlamını başlıklar veya mesaj meta verileri kullanarak yayın
  • Logdan iz'e ilişkilendirmeyi etkinleştirmek için iz kimliklerini log çıktısına ekleyin
  • Hata veya yüksek gecikme içeren izleri koruyan örnekleme stratejileri kullanın
  • İş bağlamı için yayılımlara özel nitelikler ekleyin — kullanıcı katmanı, ürün SKU'su, bölge

İzleri Okuma ve Yorumlama

İyi açıklanmış bir iz, bir isteğin kritik yolunu ortaya çıkarır. En uzun süreli yayılıma odaklanın — darboğazınız budur. Hata olayları veya yüksek nitelik kardinalitesi olan yayılımları arayın. Başarılı ve başarısız istekler arasındaki izleri karşılaştırarak desenleri belirleyin. İzler tutarlı bir şekilde belirli bir alt akış çağrısının zaman aşımına uğradığını gösteriyorsa, bu bir uygulama hatası değil, bir bağımlılık sorunudur.

Uyarılar: Neye Uyarı Gönderilmeli ve Uyarı Yorgunluğu Nasıl Önlenir

Uyarı yorgunluğu, olay müdahalesine yönelik en büyük tehdittir. Bir ekip vardiya başına elli uyarı aldığında, her uyarı göz ardı edilir. Sağlıklı bir uyarı stratejisinin amacı her anormalliği tespit etmek değil — insan muhakemesi gerektiren küçük, yüksek sinyalli bir bildirim seti üretmektir. Geriye kalan her şey bir panel veya log sorgusu olmalıdır.

Uyarı Kademe Sistemi

Uyarıları üç kademede organize edin. 1. Kademe uyarılar, nöbetçi mühendisi hemen arar çünkü kullanıcıya yönelik bir sorunu işaret eder — yüksek hata oranı, tam servis kullanılamazlığı veya SLO tükenme oranının eşiği aşması. 2. Kademe uyarılar, bir sonraki iş günü triyajı için bir görev oluşturur — yüksek gecikme, düşük performans gösteren ancak başarısız olmayan bileşenler. 3. Kademe uyarılar bilgilendirme amaçlıdır — süresi yaklaşan sertifika, depolama sınırlarına yaklaşma.

  • Yalnızca semptomlara, nedenlere değil sayfa açın. Kullanıcı 5xx hatası görüyor — buna sayfa açın, CPU kullanımına değil
  • Tetiklenmeden önce sürekli sapma gerektiren çok koşullu uyarılar kullanın (örneğin, eşiğin 5 dakika üzerinde)
  • Sinyal kalitesini korumak için vardiya başına mühendis başına en fazla üç sayfalama uyarısı belirleyin
  • Her çeyrekte uyarı kurallarını gözden geçirin ve budayın — güncel olmayan uyarılar sisteme olan güveni aşındırır
  • Her uyarıya çalıştırma kılavuzu bağlantıları ekleyin, böylece müdahaleci ilk üç adımı bilir

Tükenme Oranı ile Uyarı

Tükenme oranı ile uyarı, hata bütçeniz beklenenden daha hızlı tüketildiğinde tetiklenir. Statik eşik uyarılarının aksine, tükenme oranı uyarıları doğrudan SLO'larınıza bağlıdır. SLO'nuz 30 gün boyunca %99,9 kullanılabilirlik ise, yaklaşık 43 dakikalık kesinti süresine izniniz var demektir. Bir tükenme oranı uyarısı, öngörülen bütçe tükenmesi pencerenizi planlanandan daha hızlı tüketeceğinde tetiklenir ve SLO ihlal edilmeden önce yanıt vermeniz için size zaman tanır.

Kullanışlı Paneller Oluşturma

Çoğu mühendislik paneli, kullanılmayan grafiklerin mezarlığıdır. Bir panel, yorumlama gerektirmeden belirli bir soruyu yanıtladığında kullanışlıdır. En iyi paneller tek bir kişilik ve tek bir kullanım durumu için oluşturulur: olay triyajı için nöbetçi paneli, kapasite planlaması için haftalık inceleme paneli ve SLO başarımını izlemek için ekip paneli.

Nöbetçi Paneli

Nöbetçi paneli tek bir ekrana sığmalı ve dört soruyu yanıtlamalıdır: servis çalışıyor mu? hata oranı nedir? gecikme dağılımı nedir? hata bütçesi ihlal edildi mi? Her grafik, izleyicinin mevcut değerin sağlıklı olup olmadığını hemen söyleyebilmesi için net bir eşik çizgisine sahip olmalıdır. Tek bir nöbetçi paneline altıdan fazla grafik koymaktan kaçının — bir olay sırasında bilişsel yük önemlidir.

  • RED metrikleriyle başlayın: Hız (saniyedeki istek sayısı), Hatalar (başarısız istekler), Süre (gecikme yüzdelikleri)
  • Altyapı için USE metriklerini ekleyin: Kullanım, Doygunluk, Hatalar her kaynak için
  • Önemli durum göstergeleri olarak SLO başarımı ve tükenme oranını ekleyin
  • Her grafiği, tek tıkla detaylandırma için temelindeki log veya iz sorgusuna bağlayın
  • Gecikme grafikleri için logaritmik ölçekler kullanın — doğrusal ölçekler kuyruklardaki önemli varyasyonu gizler

Yaygın Panel Anti-Desenleri

En yaygın anti-desen, altyapınızın ürettiği her metriği gösteren paneldir. Bu "yeşil duvar" panelleri yanlış bir güvenlik hissi yaratır ve bir olay sırasında sinyali bulmayı imkansız hale getirir. Diğer anti-desenler arasında zaman serisi verileri için pasta grafikleri kullanmak, tutarsız eksenlerde birden fazla metriği istiflemek ve eşik çizgilerini etiketlememek yer alır. Bir grafik açıklama gerektiriyorsa, panele ait değildir.

SLI'lar, SLO'lar ve Hata Bütçeleri

Hizmet Seviyesi Göstergeleri, Hedefleri ve Hata Bütçeleri, mühendislik ekibiniz ile kullanıcılarınız arasındaki sözleşmeyi oluşturur. SLI'lar ham ölçümlerdir — istek gecikmesi, hata oranı, iş hacmi. SLO'lar taahhüt ettiğiniz hedeflerdir — isteklerin %99,9'u 200 milisaniyenin altında tamamlanır. Hata bütçeleri, izin verilen başarısızlık marjıdır — ekiplere taahhütleri ihlal etme korkusu olmadan dağıtım yapma, deneme ve yineleme izni veren %0,1'lik boşluk.

Anlamlı SLI'lar Seçme

İyi SLI'lar kullanıcıya yönelik, ölçülebilir ve eyleme dönüştürülebilirdir. Kullanılabilirlik (başarılı isteklerin oranı), gecikme (bir eşiğin altındaki isteklerin oranı) ve tazelik (sunulan verinin yaşı) web servisleri için en yaygın SLI'lardır. Anahtar, kullanıcının bakış açısından ölçüm yapmaktır — sunucunuzdan 50 milisaniyede başarılı olan ancak yavaş bir mobil ağda iki saniye süren bir istek, kullanıcının bakış açısından bir başarısızlıktır.

SLO Hedeflerini Gerçekçi Belirleme

%99,999 SLO kulağa etkileyici gelir ancak muazzam bir mühendislik maliyetiyle gelir. Her ek dokuz, yedeklilik, test ve operasyonel araçlara yaklaşık on kat daha fazla yatırım gerektirir. Çoğu servis için %99,9 ile başlayın ve daha yüksek SLO'ları müşteriye yönelik kritik yollar için saklayın. Neyi başarabileceğiniz konusunda dürüst olun — sürekli ihlal edilen bir SLO, hiç SLO olmamasından daha kötüdür çünkü başarısızlığı normalleştirir ve mühendislerin metriklere olan güvenini aşındırır.

Hata Bütçeleri Hızı Nasıl Sağlar

Hata bütçeleri, güvenilirliği bir kısıtlamadan ölçülebilir bir riske dönüştürür. Bütçe doluyken, ekipler boş alanları olduğunu bilerek özgürce dağıtım yapabilir. Bütçe tükendiğinde, ekip kritik olmayan sürümleri durdurur ve yalnızca güvenilirlik çalışmalarına odaklanır. Bu, bir sürümün "yeterince güvenli" olup olmadığı konusundaki öznel tartışmaların yerini alan net, veri odaklı bir karar süreci oluşturur.

Sunucusuz ve Uç Bilişimde Gözlemlenebilirlik

Sunucusuz ve uç bilişim, benzersiz gözlemlenebilirlik zorlukları getirir. İşlevler geçicidir, altyapı soyutlanmıştır ve yürütme ortamı küresel varlık noktalarına dağıtılmıştır. Geleneksel ajan tabanlı izleme başarısız olur çünkü ajan çalıştıracak bir sunucu yoktur. Bu ortamlarda gözlemlenebilirlik farklı bir yaklaşım gerektirir: push tabanlı telemetri, soğuk başlangıçlar için ince taneli dağıtık izleme ve küresel dağıtımlar arasında kardinalitenin dikkatli yönetimi.

Sunucusuza Özgü Desenler

Soğuk başlangıçlar, sunucusuz işlevlerde baskın gecikme faktörüdür. İşlev başlatmayı istek işlemeden ayrı olarak enstrümante edin, böylece soğuk başlangıç gecikmesini iş mantığı gecikmesinden ayırt edebilirsiniz. Yapılandırılmış loglama kullanarak çağrı bağlamını yakalayın — istek kimliği, bölge, işlev sürümü, yürütme ortamı — ve yanıt yolunu bloke etmemek için çağrı sayısı, süre ve hata oranı için özel metrikleri asenkron olarak yayınlayın.

  • Soğuk başlangıç süresini özel bir metrik olarak enstrümante edin — bu, standart bulut sağlayıcı metriklerinde görünmez
  • Lambda eklentileri veya Cloudflare Workers ile uyumlu OpenTelemetry yayıcıları kullanın
  • İşlev yürütme süresine gecikme eklememek için telemetri dışa aktarımını toplu hale getirin
  • Özel metrik API'lerinin kullanılamadığı ortamlar için log tabanlı metrikler kurun
  • Etkili filtreleme için tüm telemetriyi dağıtım ortamı, bölge ve işlev sürümü ile etiketleyin

Uç Bilişim Değerlendirmeleri

Cloudflare Workers veya Vercel Edge Functions gibi uç platformlar, düzinelerce küresel konumda çalışır. Bu coğrafi dağılım, geleneksel merkezi telemetri toplamayı pratik olmaktan çıkarır. Her bir varlık noktasında telemetri toplayan ve minimum yük ile merkezi olarak toplayan uç bilişime özgü gözlemlenebilirlik araçlarını kullanın. Bölge düzeyindeki hata oranlarını izleyin — bölgesel bir ISS sorunu, küresel ortalama sağlıklı görünürken hizmetinizi bir coğrafyada düşürebilir.

Gözlemlenebilirlik Kültürü Oluşturma

Araçlar ve boru hatları gerekli ancak yetersizdir. Gözlemlenebilirliğin en zor kısmı kültüreldir. Ekibiniz, enstrümante edilmiş koda test edilmiş kod kadar değer vermelidir. Her yeni özellik, birim testleri ve kod incelemesi içerdiği gibi, tanım gereği gözlemlenebilirlik enstrümantasyonunu da içermelidir. Bu, altyapı gerektirir — paylaşılan kütüphaneler, belgelenmiş kurallar ve her takımda bir gözlemlenebilirlik şampiyonu.

Gözlemlenebilirliği Birinci Sınıf Bir Unsur Haline Getirmek

Her servis için standart alanları, metrik adlandırma kurallarını ve izleme gereksinimlerini tanımlayan bir telemetri tasarım belgesi oluşturarak başlayın. Bu belgeyi yeni servisler için onboarding sürecinin bir parçası haline getirin. CI'da minimum enstrümantasyonu zorunlu kılan otomatik kontroller kurun — örneğin, karşılık gelen iz enstrümantasyonu veya yapılandırılmış log girdileri olmadan yeni HTTP işleyicileri ekleyen çekme isteklerini reddedin.

  • Her özellik için tamamlanma tanımına gözlemlenebilirlik enstrümantasyonunu ekleyin
  • Ekibin yalnızca paneller ve iz sorguları kullanarak hata ayıklama pratiği yaptığı düzenli oyun günleri düzenleyin
  • Gözlemlenebilirlik başarılarını kutlayın — iyi telemetrinin hızlı çözüme nasıl yol açtığını vurgulayan olay sonrası incelemeleri paylaşın
  • Her sprintte takımlar arasında telemetri kalitesini gözden geçiren dönüşümlü gözlemlenebilirlik şampiyonları atayın
  • Doğru olanı yapmayı yanlış olanı yapmaktan daha kolay hale getiren paylaşılan enstrümantasyon kütüphanelerine yatırım yapın

Geri Bildirim Döngüsü

Gözlemlenebilirlik tek seferlik bir uygulama değildir. Sürekli bir geri bildirim döngüsüdür. Enstrümante et, dağıt, gözlemle, öğren ve iyileştir. Bir olay bir kör noktayı ortaya çıkardığında — izlenmeyen bir metrik, eksik bir log alanı, atlanan bir iz — bunu gözlemlenebilirlik platformunuzda bir hata olarak ele alın ve düzeltin. Zamanla, telemetriniz daha eksiksiz hale gelir, hata ayıklamanız hızlanır ve ekibiniz daha önce hiç görmedikleri hata modlarını bile anlayabileceklerini bilmenin getirdiği güveni geliştirir.

"Gözlemlenebilirliğin amacı olayları önlemek değildir. Olaylar olduğunda, ekibinizin kullanıcılarınız fark etmeden önce bunları çözmek için verilere, araçlara ve güvene sahip olmasını sağlamaktır."

Gözlemlenebilirliği benimsemek bir yolculuktur, bir satın alma değil. Küçük başlayın — kritik bir servisi uçtan uca enstrümante edin, tek bir kullanışlı panel oluşturun ve anlamlı bir SLO yazın. Değerin kendisi için konuşmasına izin verin. Ekibiniz bir olay sırasında tahmin etmek ile bilmek arasındaki farkı deneyimlediğinde, asla geri dönmek istemeyecektir.