Sistem çalışıyor. Ta ki durana kadar
Müşterilerin ürünleri inceleyebildiği, sepete ekleyebildiği ve ödeme aşamasına geçebildiği bir e-ticaret mağazası hayal edin. Sunucu yanıt veriyor, sayfa açılıyor ve temel altyapı metrikleri ciddi bir sorun göstermiyor. Görünüşte her şey düzgün çalışıyor.
Oysa bazı müşteriler siparişi tamamlayamıyor. Kimilerinde ödeme birkaç saniye sürüyor, kimilerinde hata oluşuyor. Teknik ekip bildirimler alıyor, ancak sorunun ödeme geçidinden mi, veritabanından mı, son uygulama güncellemesinden mi yoksa hizmetler arası iletişim sorunundan mı kaynaklandığını henüz bilmiyor.
Bu, sıradan izlemenin yetersiz kalabileceği bir durumdur. İzleme, hata sayısının arttığını veya yanıt süresinin uzadığını gösterebilir, ancak her zaman kök nedeni hızlıca bulmak için gereken bilgiyi sağlamaz.
İşte bu boşluğu observability, yani sistemin gözlemlenebilirliği doldurur. Amacı yalnızca uygulamanın hatalı çalıştığını tespit etmek değildir. Davranışını analiz edebilmek, olayların akışını yeniden oluşturabilmek ve problemin kaynağını bulabilmek anlamına gelir; üstelik daha önce belirli bir arıza senaryosu öngörülmemiş olsa bile.
Monitoring ve observability - benzer hedefler, farklı olanaklar
Monitoring ve observability birbiriyle yakından ilişkilidir, ancak aynı şey değildir.
Monitoring, uygulama ve altyapı durumuna ilişkin verilerin sistematik olarak toplanması ve analiz edilmesidir. Belirli parametreleri izlemeyi, kabul edilen normlardan sapmaları tespit etmeyi ve müdahale gerektiren bir durum oluştuğunda uyarılar tetiklemeyi sağlar.
Monitoring’in yanıt verdiği örnek sorular şunlardır:
- Sunucu erişilebilir mi?
- API’nin ortalama yanıt süresi nedir?
- HTTP 500 hata sayısı belirlenen eşiği aşıyor mu?
- Bellek ve işlemci kullanımı ne durumda?
- İş kuyruğu, sistemin işleyebileceğinden daha hızlı mı büyüyor?
Observability bir adım daha ileri gider. Sistemin farklı bölümlerinden gelen verileri analiz etmeyi ve bunları belirli bir davranışın neden ortaya çıktığını anlamaya yardımcı olan bir bağlamda birleştirmeyi sağlar.
Bunu üç soruyla ifade edebiliriz:
- Monitoring: Bir sorun var mı?
- Teşhis: Sorun nerede ortaya çıktı?
- Observability: Ne oldu, neden oldu ve sistemin çalışmasına etkisi neydi?
Gözlemlenebilirlik, monitoring’in yerini almaz. Monitoring’i ve uygun şekilde hazırlanmış telemetri verilerini kullanarak uygulamanın davranışını daha derinlemesine incelemeyi mümkün kılan bir yaklaşımdır. OpenTelemetry, observability’yi loglar, metrikler ve dağıtık izler gibi sinyallere dayanarak sistemin davranışı hakkında ona sorular sorabilme yeteneği olarak tanımlar. <Cite ref="turn154932search0"/>
Observability’nin üç sütunu: loglar, metrikler ve tracing
Gözlemlenebilirliğin temeli üç tür telemetri verisidir: logs, metrics ve traces. Her biri uygulamanın işleyişinin farklı bir yönünü gösterir. Ancak bunların birlikte korele edilmesi, durumun daha geniş bir resmini sunar.
1. Loglar - uygulamada ne oldu?
Loglar (logs), uygulama, işletim sistemi, sunucular, veritabanları ve altyapının diğer bileşenleri tarafından üretilen düzenli olay kayıtlarıdır.
Örneğin şunları kaydedebilirler:
- bir sürecin başlaması ve sona ermesi,
- bir kullanıcının giriş denemesi,
- harici bir API’ye istek gönderilmesi,
- veri doğrulama hatası,
- başarısız bir işlem,
- uygulama tarafından bildirilen istisna,
- sipariş durumunun değişmesi.
Bir log; zaman damgası, önem seviyesi, hizmet adı, mesaj, istek kimliği ve olayı tanımlayan ek öznitelikler içerebilir.
Metin logları ile yapılandırılmış logları ayırt etmek gerekir. Metin kaydı şöyle görünebilir:Sipariş işlenirken hata oluştu
Bu mesaj bir sorun olduğunu bildirir, ancak bağlamı hakkında çok az şey söyler. Yapılandırılmış bir log ise sipariş kimliği, işlem adı, hata kodu, çalışma süresi ve iz kimliği gibi ayrı alanlar içerebilir. Bu sayede veriler filtrelenebilir, gruplanabilir ve otomatik olarak analiz edilebilir.
İyi uygulama: loglar yalnızca mesaj kaydetmek için değil, daha sonra analiz edilmeyi kolaylaştıracak şekilde tasarlanmalıdır. Farklı bileşenlerden gelen olayları birbirine bağlamayı sağlayan tutarlı adlandırmalar, önem seviyeleri ve korelasyon kimlikleri kullanmak faydalıdır.
Aynı zamanda loglama dikkatli yapılmalıdır. Her işlemi tam kapsamıyla kaydetmek devasa miktarda veri üretebilir, depolama maliyetlerini artırabilir ve önemli bilgileri bulmayı zorlaştırabilir. En az bunun kadar önemli olan bir diğer nokta da logların parolaları, erişim tokenlarını, ödeme kartı bilgilerini veya diğer hassas verileri açığa çıkarmamasıdır. Maskeleme, erişim kontrolü, uygun saklama süreleri ve güvenli veri işleme kuralları uygulanmalıdır.
2. Metrikler - sistem zaman içinde nasıl davranıyor?
Metrikler (metrics), belirli bir zaman içinde sistemin durumunu, performansını ve davranışını tanımlayan toplu sayısal verilerdir.
Örnek metrikler şunları içerir:
- saniye başına işlenen istek sayısı,
- hata ile sonuçlanan isteklerin oranı,
- API yanıt süresi,
- CPU ve bellek kullanımı,
- aktif oturum sayısı,
- iş kuyruğunun uzunluğu,
- tamamlanan işlem sayısı,
- veritabanı bağlantısı için bekleme süresi.
En büyük avantajları, eğilimlerin gözlemlenebilmesidir. Tek bir hata münferit bir olay olabilir; ancak giderek artan yanıt süresi, başarısız işlem sayısının yükselmesi veya büyüyen iş kuyruğu, gelişmekte olan bir probleme işaret edebilir.
Uygulamada metrikler, yalnızca uygulamanın çalışıp çalışmadığı sorusuna değil, performansının kullanıcı beklentilerini ve iş gereksinimlerini karşılayıp karşılamadığına da yanıt vermeye yardımcı olur.
Özellikle yanıt süresi yüzdelikleri, örneğin p95 ve p99, çok kullanışlıdır. Ortalama değer, çoğu kullanıcının hızlı yanıt aldığı ama küçük bir kısmının çok büyük gecikmeler yaşadığı bir durumu gizleyebilir. Yüzdelikler, daha yavaş isteklerin ne kadar sürdüğünü gösterir ve ortalama değerlerde görünmeyen sorunları fark etmeye yardımcı olur.
İyi uygulama: kullanıcı ve iş süreci açısından anlam taşıyan metrikleri seçin. Yalnızca işlemci yüküne bakmak, müşterinin sipariş verip veremeyeceğini söylemez. Bu nedenle ödeme başarı oranı, sipariş tamamlama süresi veya en önemli işlemlerin erişilebilirliği gibi kritik işlevlerle ilgili göstergeleri de izlemek gerekir.
3. Tracing - istek hangi yollardan geçti?
Tracing, özellikle de distributed tracing yani dağıtık izleme, tek bir isteğin sistemin farklı bileşenleri arasındaki yolculuğunu takip etmeyi sağlar.
Modern bir uygulamada kullanıcı işlemi birçok aşamayı içerebilir. “Sipariş ver” düğmesine tıklamak, tarayıcıda bir isteği tetikleyebilir; bu istek API’ye, ardından sipariş hizmetine, veritabanına, envanter sistemine ve harici bir ödeme sağlayıcısına ulaşır.
Süreç gecikirse, yalnızca tüm API’nin yanıt süresi bilgisi yeterli olmayabilir. İzleme (tracing), bu süreyi tek tek işlemlere ayırmayı ve gecikmeden hangi aşamanın sorumlu olduğunu görmeyi sağlar.
Bir iz (trace) içindeki temel öğe, yani tek bir işlemin kaydı olan span’dir. Span başlangıç ve bitiş zamanını, işlem adını, durumu ve meta verileri içerebilir. İlişkili span’ler, tüm isteğin akışını gösteren bir iz oluşturur.
Örneğin:
- API isteği alır ve onu ilerletir.
- Sipariş hizmeti verileri doğrular.
- Veritabanı siparişi kaydeder.
- Envanter hizmeti ürünün kullanılabilirliğini kontrol eder.
- Harici ödeme geçidi işlemi işler.
- Uygulama sonucu kullanıcıya döner.
Tüm süreç 8 saniye sürerse, tracing bunun 6,5 saniyesinin harici ödeme geçidinden gelen yanıta gittiğini, diğer işlemlerin ise düzgün ilerlediğini gösterebilir. Böylece ekip, tanılama sürecine rastgele bileşenlerden başlamak yerine, ileri analiz için somut bir nokta elde eder.
Tracing özellikle mikroservis mimarilerinde, dağıtık sistemlerde, kuyruk tabanlı uygulamalarda ve birçok harici hizmeti entegre eden çözümlerde çok yararlıdır. <Cite ref="turn154932search0"/>
Uyarılar - bilginin doğru kişiye ulaşması gerekir
Telemetri verileri, ancak bunlar üzerinden aksiyon alınabiliyorsa faydalıdır. Bu yüzden observability’nin önemli bir parçası da uyarı sistemidir.
Uyarı, dikkat gerektiren bir olay veya durum hakkında bildiridir. Bir metrik eşiğinin aşılması, belirli bir hata örüntüsünün tespit edilmesi ya da uygulamanın kritik bir özelliğinin beklendiği gibi çalışmadığının anlaşılmasıyla tetiklenebilir.
Ancak her yük artışı alarm üretmemelidir. Sistem yoğun saatlerde düzenli olarak yüksek trafiği işliyorsa, her istek artışı için bildirim göndermek bilgi gürültüsüne yol açar. Çok fazla uyarı, onların göz ardı edilmesine ve sonuçta gerçekten önemli bir olayın kaçırılmasına neden olur.
Bu nedenle şunlar belirlenmelidir:
- hangi olaylar anında tepki gerektirir,
- hangi sorunlar standart çalışma düzeninde analiz edilebilir,
- hangi uyarı tipinden kimin sorumlu olduğu,
- bildirimin hangi bilgileri içermesi gerektiği,
- alındıktan sonra hangi adımların atılması gerektiği.
İyi bir başlangıç noktası, uyarıları yalnızca altyapı parametrelerine göre değil, kullanıcı üzerindeki etki ve güvenilirlik hedeflerine göre tanımlamaktır. Örneğin, başarısız ödemelerin oranındaki artışa yönelik bir uyarı, CPU kullanımındaki kısa süreli bir sıçramadan daha büyük bir iş etkisine sahip olabilir.
Bir uyarı aksiyona yol açmalıdır. Kimin ele alacağı ve ne yapılacağı bilinmiyorsa, sistemdeki bir başka bildiriden ibarettir.
Pratikten örnek: observability arızanın nedenini bulmaya nasıl yardım eder?
Diyelim ki bir B2B uygulamasının kullanıcıları rapor oluşturmanın normalden çok daha uzun sürdüğünü bildiriyor. İzleme, yanıt süresindeki artışı tespit eder ve bir uyarıyı tetikler.
Ekip analize başlar:
- Metrikler sorunun esas olarak büyük veri aralıklarını kapsayan raporlarla ilgili olduğunu gösterir. Diğer işlevler normal çalışıyordur.
- Tracing en büyük gecikmenin veritabanı sorgusu çalıştırılırken ortaya çıktığını gösterir.
- Loglar sorgunun ayrıntılarını, çalışma parametrelerini ve hata bilgilerini içerir; hassas verileri açığa çıkarmadan.
- Veri korelasyonu belirli bir izi, loglardaki ilgili kayıtlarla ve metrik grafiklerinde görülen değişikliklerle ilişkilendirmeyi sağlar.
- Değişiklik analizi sorunun, pahalı bir sorgu çalıştırmaya başlayan yeni rapor sürümü devreye alındıktan sonra ortaya çıktığını gösterir.
Bunun sayesinde ekip, tüm altyapıyı körlemesine kontrol etmek zorunda kalmaz. Belirli bir operasyona odaklanabilir, dağıtım öncesi ve sonrası davranışı karşılaştırabilir ve ardından sorguyu optimize edebilir ya da değişikliği geri alabilir.
Observability arızaları ortadan kaldırmaz ve her nedenin otomatik olarak bulunacağını garanti etmez. Ancak arama alanını daraltır, teşhis süresini kısaltır ve kararların varsayımlar yerine verilere dayanmasını sağlar.
Veri korelasyonu - en büyük değer birlikte ortaya çıkar
Loglar, metrikler ve tracing tek başlarına faydalıdır; ancak gerçek değerleri, birbirleriyle ilişkilendirilebildiklerinde ortaya çıkar.
Bir dashboard’un aniden artan yanıt süresini gösterdiğini düşünelim. Metrik, sorunun ne zaman ve ne ölçekte ortaya çıktığını belirtir. Trace, yavaş isteği hangi işlemlerin oluşturduğunu gösterir. Loglar, belirli bir aşamada hangi olayların meydana geldiğini incelemeyi sağlar.
Bunun mümkün olması için sistem, istek bağlamını hizmetler arasında tutarlı biçimde aktarmalıdır. Trace ve span kimlikleri, log kayıtlarını izlerle ilişkilendirmek için kullanılabilir. Ayrıca hizmet adı, ortam, uygulama sürümü ve veri kaynağını tanımlayan diğer öznitelikler hakkında tutarlı bilgiler saklamak da önemlidir.
Korelasyon olmadan ekip birçok dashboard’a, dosyaya ve araca erişebilir ama yine de hangi olayların birbirine bağlı olduğunu manuel olarak belirlemeye zaman kaybeder. OpenTelemetry, logların, izlerin ve kaynak bağlamının korelasyonunu, kullanışlı telemetri oluşturmanın önemli bir unsuru olarak gösterir. <Cite ref="turn154932search1"/>
OpenTelemetry - telemetri verileri için ortak standart
Observability’yi uygulamak, tek bir araç sağlayıcısına bağımlı olmak zorunda değildir. Birlikte çalışabilirliği destekleyen çözümlerden biri OpenTelemetry’dir (OTel) - telemetri verilerini enstrümante etmek, üretmek, toplamak ve dışa aktarmak için açık bir standartlar, API’ler, kütüphaneler ve araçlar seti.
OpenTelemetry, bir uygulamanın metrik, log ve izleri tutarlı bir modelle üretmesini sağlar. Veriler daha sonra, bunların saklanmasından, aranmasından, görselleştirilmesinden ve analizinden sorumlu seçilen bir observability altyapısına aktarılabilir.
Ekosistemin önemli bir bileşeni OpenTelemetry Collector’dır. Farklı kaynaklardan veri alabilir, bunları işleyebilir, ek bağlamla zenginleştirebilir ve yapılandırılmış sistemlere dışa aktarabilir. Böylece uygulamanın, analiz için kullanılan her araçla doğrudan entegre olması gerekmez.
Bu yaklaşım, şirket birçok teknoloji kullanıyorsa, sistem mimarisini geliştiriyorsa veya araç sağlayıcısını değiştirme esnekliğini korumak istiyorsa özellikle yararlıdır. Ancak standardın kendisi tek başına eksiksiz observability sağlamaz. Hâlâ doğru enstrümantasyon, düşünülmüş bir veri toplama stratejisi, uygun dashboard’lar, uyarılar ve müdahale prosedürleri gerekir. <Cite ref="turn154932search3"/>
Observability’yi ne zaman uygulamak gerekir?
Observability, hem büyük dağıtık sistemlerde hem de kesinti veya tespiti zor bir arızanın önemli iş sonuçları doğurduğu daha küçük uygulamalarda faydalı olabilir.
Bu yaklaşımı özellikle şu durumlarda değerlendirmek gerekir:
- uygulama birçok hizmetten veya entegrasyondan oluşur,
- sorunlar düzensiz ortaya çıkar ve yeniden oluşturulmaları zordur,
- kullanıcılar, standart testlerde görünmeyen hatalar bildirir,
- olayları teşhis etme süresi çok uzundur,
- ardışık dağıtımlar öngörülmesi zor sonuçlara yol açar,
- şirket sistemi büyütmektedir ve performans planlaması için verilere ihtiyaç duymaktadır,
- uygulama kritik satış, operasyon veya finans süreçlerini destekler,
- ekip, dış hizmetlerin tüm çözümün çalışmasına etkisini daha iyi anlamaya ihtiyaç duyar.
Bu, ancak her web sitesinin kapsamlı bir telemetri ortamına ihtiyaç duyduğu anlamına gelmez. Küçük ve basit bir serviste temel loglar, erişilebilirlik kontrolü ve birkaç önemli metrik yeterli olabilir. Çözümün kapsamı, uygulamanın karmaşıklığına, trafik ölçeğine, güvenilirlik gereksinimlerine ve olası kesinti maliyetlerine uygun olmalıdır.
Observability ne zaman gereğinden fazla olabilir?
Açıkça belirlenmiş bir amaç olmadan kapsamlı araçlar uygulamak, faydadan çok maliyet getirebilir.
En yaygın hatalar şunlardır:
- Plansız şekilde her şeyi toplamak. Fazla veri maliyetleri artırır ve teşhis için önemli bilgilerin bulunmasını zorlaştırır.
- Sistemin yanıt vermesi gereken soruların olmaması. Paneller etkileyici görünebilir, ancak gerçek sorunların çözümüne yardımcı olmayabilir.
- Her sapma için uyarı vermek. Çok fazla bildirim, uyarı yorgunluğuna neden olur ve bir olayın gözden kaçma riskini artırır.
- Müdahaleden sorumluluğun olmaması. İyi tespit edilmiş bir sorun bile uzun sürebilir; eğer kimin ilgilenmesi gerektiğini kimse bilmiyorsa.
- Veri korumasının olmaması. Telemetri; kısıtlı erişim ve uygun saklama süresi gerektiren hassas bilgiler, kullanıcı kimlikleri veya operasyonel veriler içerebilir.
- Enstrümantasyon maliyetini göz ardı etmek. Ayrıntılı izler ve logları büyük ölçekte toplamak uygulamanın performansını etkileyebilir ve önemli depolama ile işleme maliyetleri oluşturabilir.
- Araçları hazır çözüm olarak görmek. Bir platformu yalnızca kurmak, doğru enstrümantasyonu ya da etkili bir teşhis sürecini garanti etmez.
Bu nedenle observability yalnızca teknoloji değil, aynı zamanda organizasyonel kararlar da gerektirir: hangi verilerin gerekli olduğu, bunları kimin analiz ettiği, ekibin nasıl tepki verdiği ve olaylardan çıkarılan sonuçların sistemdeki değişikliklere nasıl dönüştüğü.
Observability uygulaması nasıl planlanır?
Gözlemlenebilirliği en güvenli şekilde aşama aşama geliştirmek gerekir; işe, arızası kullanıcılar ve şirket üzerinde en büyük etkiye sahip olan süreç ve işlevlerden başlanmalıdır.
1. Temel iş süreçlerini belirle
Giriş yapma, sipariş oluşturma, ödeme, belge üretimi veya veri senkronizasyonu gibi en önemli işlemleri belirleyin. Uygulamanın doğru çalışmasının ne anlama geldiğini tanımlamak için başlangıç noktası bunlar olmalıdır.
2. Güvenilirlik göstergelerini belirle
Kullanıcı deneyimini yansıtan metrikleri seçin; örneğin temel işlevlerin erişilebilirliği, yanıt süresi veya başarıyla tamamlanan işlem oranı. Önemli hizmetler için SLI (Service Level Indicator), yani hizmet seviyesi göstergesi, ve SLO (Service Level Objective), yani bu göstergeye ilişkin hedef tanımlanabilir.
3. Yapısal logları düzenle
Log formatını, önem seviyelerini ve temel nitelikleri standart hale getirin. Korelasyon kimliklerini ve hassas verilerin silinmesi ya da maskelenmesine ilişkin politikayı belirleyin. Loglar ekip için okunabilir ve araçlar tarafından işlenebilir olmalıdır.
4. Kritik akışlara tracing ekle
Birden fazla hizmet, veritabanı veya dış entegrasyon içeren süreçlerle başlayın. İsteklerin sistem içindeki yolunu izleyin ve bileşenler arasında bağlamın aktarılmasına özen gösterin.
5. Panelleri belirli sorular etrafında oluşturun
Tek, devasa bir panel oluşturmak yerine, farklı rollere yönelik ihtiyaçlara cevap veren görünümler hazırlayın. Teknik ekip hata ve gecikme bilgilerine ihtiyaç duyarken, ürün sahibi kritik süreçlerin etkinliği ve arızaların kullanıcılar üzerindeki etkisine dair verilere ihtiyaç duyabilir.
6. Uyarıları ve müdahale prosedürlerini tasarlayın
Eşikler, öncelikler, sorumlu kişiler ve izlenecek talimatlar belirleyin. Uyarı, yalnızca bir eşik aşıldığını bildirmekle kalmamalı, teşhise hızlı başlamaya yardımcı olacak bağlamı da içermelidir.
7. Observability’yi test edin
Ekibin, mevcut verilere dayanarak örnek bir hatanın nedenini bulup bulamadığını kontrol edin. Test ortamında kontrollü arıza testleri veya olay müdahale tatbikatları yapılabilir. Uyarıların gerektiği zaman tetiklenip tetiklenmediğini de doğrulamakta fayda vardır.
8. Çözümü olaylara dayanarak geliştirin
Her önemli sorundan sonra hangi bilgilerin mevcut olduğunu, nelerin eksik olduğunu ve enstrümantasyon, uyarı mekanizmaları veya prosedürlerin nasıl iyileştirilebileceğini gözden geçirmek gerekir. Observability tek seferlik bir proje değil, sistemin çalışma biçimi hakkındaki bilgiyi sürekli geliştirme sürecidir.
Maliyet ve güvenlik - göz ardı edilemeyecek iki yön
Telemetri verilerinin bir bedeli vardır. Maliyetler; enstrümantasyon, aktarım, indeksleme, saklama, muhafaza süresi ve veri analizi gibi kalemlerden kaynaklanabilir. Yüksek trafikli sistemlerde özellikle tüm izleri veya çok ayrıntılı logları toplamak maliyetli olabilir.
Bu nedenle ihtiyaçlara uygun saklama süreleri, veri filtreleme, iz örnekleme (sampling) ve ortama göre farklı ayrıntı seviyeleri kullanmak önemlidir. Örneğin üretim sistemi, hatalar ve seçili kritik işlemler için tam veri toplayabilir; doğru isteklerin bir kısmını ise hacmi azaltmak için örnekleyebilir.
Veri koruması da en az bunun kadar önemlidir. Loglar ve izler farkında olmadan kişisel veriler, oturum kimlikleri, sorgu parçaları veya altyapı yapısına ilişkin bilgiler içerebilir. Telemetriye erişim sınırlandırılmalı, gereksiz veriler kaldırılmalı, hassas bilgiler maskelenmeli ve saklama süreleri kontrol edilmelidir. Ayrıca observability sistemleri, kendi başlarına da güvenlik önlemleri, yedekler ve yetki kontrolleri gerektiren üretim ortamının bir parçası olarak ele alınmalıdır.
Yalnızca teşhis için değil, yönetim aracı olarak observability
Gözlemlenebilirlik çoğunlukla geliştiriciler, DevOps ekipleri ve yöneticilerle ilişkilendirilse de, değeri BT alanının ötesine geçer.
Yanıt süresi, hatalar, erişilebilirlik ve süreçlerin başarısı hakkındaki veriler, şirketin teknolojinin hangi unsurlarının işi desteklediğini, hangilerinin ise sınırladığını anlamasına yardımcı olabilir. Tekrarlayan sorunları belirlemeyi, değişikliklerin etkisini değerlendirmeyi ve sistemin gerçek davranışına dayanarak gelişimi planlamayı sağlarlar.
Örneğin sipariş sistemi belirli saatlerde düzenli olarak yavaşlıyorsa, telemetri verileri sorguların optimize edilmesi, görevlerin işlenme biçiminin değiştirilmesi ya da altyapının genişletilmesi gerekip gerekmediğini anlamaya yardımcı olabilir. Şirket, içgüdülere dayanarak ek kaynak yatırımı yapmak yerine önce gerçek darboğazı belirleyebilir.
Gözlemlenebilirlik, dağıtımların etkilerinin analizini de destekler. Değişiklik öncesi ve sonrası metriklerin, izlerin ve logların karşılaştırılması, regresyonları daha hızlı tespit etmeyi ve güncellemenin beklenen etkiyi getirip getirmediğini değerlendirmeyi sağlar.
Ancak gözlemlenebilirliği otomatik karar verme ile özdeşleştirmemek gerekir. Veriler sistemin davranışını gösterir, fakat bunların yorumlanması mimari, iş süreçleri ve belirli bir olayın bağlamı hakkında bilgi gerektirir.
Terimler sözlüğü
- Observability (gözlemlenebilirlik) - bir sistemin ürettiği verilere dayanarak iç davranışını anlama yeteneği.
- Monitoring (izleme) - seçilen parametrelerin sürekli olarak takip edilmesi ve dikkat gerektiren belirli durumların tespit edilmesi.
- Telemetry (telemetri) - bir uygulama ve altyapıdan davranışlarını analiz etmek amacıyla toplanan ve iletilen veriler.
- Logs (loglar) - uygulamada veya altyapıda gerçekleşen olayların kayıtları.
- Metrics (metrikler) - sistemin zaman içindeki durumu, performansı veya davranışının sayısal ölçümleri.
- Tracing - işlemlerin uygulama bileşenleri arasındaki akışının izlenmesi.
- Distributed tracing - birçok servis veya süreçten oluşan bir sistemde tek bir isteğin izlenmesi.
- Span - bir izleğin parçası olan tek bir işlemin kaydı.
- Trace - bir işlemin akışını gösteren ilişkili span’lerden oluşan küme.
- Alert - tepki gerektiren tespit edilmiş bir durum veya olay hakkında bildirim.
- SLI - bir hizmetin belirli bir yönünü ölçen gösterge.
- SLO - seçilen güvenilirlik göstergesi için belirlenmiş hedef.
- Sampling - olayların temsili bir bölümünü seçerek toplanan telemetri verisi miktarını sınırlama tekniği.
- OpenTelemetry - telemetri verilerinin enstrümantasyonunu ve dışa aktarımını destekleyen açık standartlar ve araçlar kümesi.
Özet
Bir uygulamanın arızası her zaman erişilemeyen bir sunucu ya da bir hata mesajıyla başlamaz. Bazen sistem resmî olarak çalışır, ancak temel bir özellik çok yavaşlar, işlemlerin bir kısmı başarıyla tamamlanmaz ya da entegrasyon yalnızca belirli koşullarda başarısız olur.
Monitoring anormallikleri tespit etmeye yardımcı olur. Observability ise bunların ortaya çıkmasına neyin yol açtığını ve uygulamanın işleyişi üzerindeki etkisinin ne olduğunu anlamayı sağlar. Loglar, metrikler, tracing ve iyi tasarlanmış alert’ler birlikte daha etkin teşhis, bilinçli geliştirme ve operasyonel riskin azaltılması için temel oluşturur.
Amaç mümkün olduğunca çok veri toplamak ya da en gösterişli dashboard’ları oluşturmak değildir. Amaç, sorun ortaya çıktığında yalnızca şunu sormamak olmalıdır: „Sistem çalışıyor mu?”, bunun yerine şunu tespit edebilmektir: „Sistemde tam olarak ne oldu, neden oldu ve bundan sonra ne yapmalıyız?”
Olgun bir uygulama yalnızca çalışan bir uygulama değildir. Aynı zamanda davranışı anlaşılabilen, teşhis edilebilen ve geliştirilebilen bir uygulamadır.
