Obser­va­bi­lity bir mimari mese­le­si­dir

Çoğu sistem istekleri yanıtlamak için inşa edilir ve kendisi hakkındaki soruları yanıtlama yeteneğiyle ancak bundan sonra donatılır. Pek çok sistemin hata anında dilsiz kalmasının nedeni bu sıralamadır: Bir sonuç üretirler, ama o sonuca nasıl vardıklarını söyleyemezler. Sonra bir şeyler ters gittiğinde tahmin yürütme başlar — ve yük altında, etkilenen kullanıcılarla tahmin yürütmek, bir sistemi işletmenin en pahalı yoludur.

Bu doküman tek bir tezi savunuyor ve geri kalan her şeyi ondan türetiyor: Kendi davranışını açıklayamayan yazılım güvenle işletilemez. Bu nedenle observability, sonradan gelen bir işletim görevi değil, mimari bir yetenektir. Doküman bilinçli olarak framework'ten, buluttan ve üreticiden bağımsız tutulmuştur ve belirli bir araç için kılavuz içermez. Araçlar değişir; söz konusu olan özellik kalır.

1. İzleme neden yetmez

Monitoring (izleme) ve observability (gözlemlenebilirlik) çoğu zaman eş tutulur, oysa farklı soruları yanıtlarlar. Monitoring önceden sorulmuş soruları yanıtlar: Servis erişilebilir mi? Hata oranı bir eşiğin üzerinde mi? Yanıt süresi çok mu yüksek? Bir metrik, bir dashboard, bir alarm tanımlarsınız — ve tam olarak bu, önceden formüle edilmiş soruya yanıt alırsınız. Monitoring, bilinen soruları sürekli göz önünde tutma sanatıdır.

Sorun şu ki ciddi kesintiler nadiren öngörülen biçimdedir. Bir dashboard hata oranının yükseldiğini gösterir — ama neden, hangi kullanıcılar için, hangi yolda olduğunu göstermez. Tam da en çok ihtiyaç duyduğunuz anda monitoring'in sağlayabileceği şey biter ve observability'nin sağlaması gereken şey başlar: çalışan sisteme, önceden bilmediğiniz bir soruyu, bunun için yeniden deploy etmek zorunda kalmadan sorabilme yeteneği.

Bu yüzden monitoring, observability'nin karşıtı değil, bir alt kümesidir: önceden tanımlanmış sorular. Gözlemlenebilir bir sistem ikisini de yapabilir — bilinen soruları göz önünde tutmak ve acil durumda bilinmeyenleri yanıtlamak. Yalnızca izlenen bir sistem ise sadece birincisini yapabilir.

Trade-off. Monitoring daha ucuz ve basittir, çünkü yalnızca bildiğiniz soruları saklar. Observability daha pahalıdır, çünkü sorulmamış soruları da yanıtlayabilecek kadar ham malzeme tutmak zorundadır.

Maliyet. Ek yeteneğin bedelini daha pahalı bir dashboard'la değil; daha fazla veriyle, olay başına daha fazla bağlamla ve bu bağlamı en baştan taşıma disipliniyle ödersiniz.

Ne zaman farklı karar veririz. Az sayıda, iyi anlaşılmış hata türüne sahip basit, izole bir sistem için salt monitoring yeterli olabilir. Bir sistem dağıtık, uzun ömürlü ya da iş açısından kritik hâle geldiği anda artık yetmez.

2. Unknown unknowns

Meselenin özü eski bir ayrımdır. Bildiğimizi bildiğimiz şeyler vardır — dashboard'a koyduğumuz bilinen metrikler. Bilmediğimizi bildiğimiz şeyler vardır — alarm kurduğumuz tahmini riskler. Ve bilmediğimizi bilmediğimiz şeyler vardır: Hiçbir planlamada yer almayan koşulların bir araya gelmesinden doğdukları için kimsenin öngörmediği hatalar.

Karmaşık sistemler ağırlıklı olarak bu üçüncü türden başarısız olur. Bilinen bir değer bir eşiği aştığı için değil; iki zararsız durum bir araya geldiği, nadiren kullanılan bir yol yük altında devrildiği, bir varsayım sessizce yanlış hâle geldiği için. Bu tür hatalar için tanım gereği hazırlanmış bir dashboard olamaz — bunu sormanız gerektiğini bilmiyordunuz.

Yaygın bir refleks sorunu çözmek yerine ağırlaştırır: Her olaydan sonra tam o durum için yeni bir dashboard kurulur. Zamanla böylece bir dashboard mezarlığı birikir; her biri geçmiş bir kesintinin anıtıdır — ve hiçbiri bir sonrakine yardımcı olmaz, çünkü bir sonraki farklı bir biçimdedir. Unknown unknown'ları geriye dönük göstergeler ekleyerek known known'lara dönüştüremezsiniz; yalnızca bir sonraki, öngörülmemiş durum anında yeni bir soru sorabilme yeteneğini hazır tutabilirsiniz. Refleks son olayın semptomunu tedavi eder; yetenek ise gelecekteki tüm olayların sınıfını.

Şema: Monitoring öngörülmüş alanlara hizmet eder. Ciddi kesintiler sağ alttaki alanda yaşar — sorunun önceden bilinmediği yerde.

Observability'nin asıl tanımı buradan çıkar: Bir sistem, dışarıdan görülebilen çıktılarından iç durumuna — inşa edilirken kimsenin aklına gelmemiş durumlar da dahil — çıkarım yapılabiliyorsa gözlemlenebilirdir. Bu bir aracın özelliği değil, sistemin kendisi hakkında açığa vurduğu şeyin özelliğidir.

Trade-off. Bilinmeyen sorulara hazırlıklı olmak, normal işletimde hiçbir zaman ihtiyaç duyulmayacak kadar fazla bağlam taşımak demektir. Yalnızca istisnai durumda karşılığını veren bir yetenek için sürekli ödeme yaparsınız.

Maliyet. Bedeli veri hacmi ve her olayı, ileride hangi bağlamın belirleyici olacağını bilmeden, sonradan sınıflandırılabilecek kadar bağlamla donatma özenidir.

Ne zaman farklı karar veririz. Olası durumların sayısının az ve kavranabilir olduğu yerlerde unknown unknown'lar için harcanan emek abartıdır; orada bilinen durumları düzgünce kapsamak yeterlidir.

3. Loglar, metrikler ve trace'ler

Observability genellikle birbirini tamamlayan, birbirinin yerini tutmayan üç tür sinyale dayanır. Bunları ayırt etmek önemlidir, çünkü her biri bir soruyu iyi, diğerlerini kötü yanıtlar — ve birinden çok fazla, diğerinden çok az toplamak kolaydır.

Metrikler zaman içindeki toplulaştırılmış sayılardır: sayaçlar, dağılımlar, oranlar. Saklaması ucuzdur ve trendleri ve eşikleri görmek için idealdir — ama tekil vakayı kaybederler. Bir metrik yanıt süresinin arttığını söyler, hangi istek için arttığını asla söylemez. Loglar ayrıntılı, ayrık olaylardır: Belirli bir noktada ne olduğunu anlatırlar ve somut bir işlemi takip etmek istediğinizde güçlüdürler — ama yüksek hacimde pahalı ve dağınık hâle gelirler. Trace'ler tek bir işlemi bileşen ve sistem sınırları boyunca izler, nedensel yolu ve zamanın nerede harcandığını gösterir — dağıtık sistemlerde vazgeçilmezdir, ama her şey saklanamıyorsa ne kadarının kaydedileceği sorusunu da beraberinde getirir.

En yaygın tasarım hatası, üçünü de birbirinin yerine geçebilir sayıp birini her şey için kullanmaktır — örneğin loglardan zahmetle metrik üretmeye çalışmak ya da metriklerle tekil bir vakanın peşine düşmek. Her sinyalin bir yeri vardır; ustalık, her soru için yeterli olan en ucuz sinyali seçmektir.

Trade-off. Daha fazla sinyal türü daha fazla kapsam demektir, ama aynı zamanda daha fazla sistem, daha fazla veri ve bağlamın tutarlı tutulması gereken daha fazla nokta.

Maliyet. Her sinyal türünün kendi maliyet etkeni vardır — kardinalite, hacim, kayıt miktarı —; bunlar gerçek yük altında şaşırtıcı hızda büyür.

Ne zaman farklı karar veririz. Tek, dağıtık olmayan bir serviste trace'lerden vazgeçip metrikler ve yapılandırılmış loglarla idare edilebilir; trace'ler ancak bir işlem birden fazla sınırı geçtiğinde karşılığını verir.

4. Observability için tasarım

Belirleyici cümle şudur: Observability, sisteme dokunmadan sonradan eklenemez. Bir kısmı sonradan ucuzdur, en önemli kısmı değildir. Bu yeteneği isteyen, onu tasarım aşamasında öngörmelidir.

İki şey baştan düşünülmelidir. Birincisi bağlamın aktarılmasıdır: Her işlem, her sınır boyunca — fonksiyon çağrısı, mesaj, ağ sınırı — taşınan bir korelasyon ya da trace kimliği taşır; böylece sonunda bir işlemin tüm izleri bir araya getirilebilir. Bu aktarımı sonradan eklemek, sistemdeki her sınıra dokunmak demektir; baştan yapıldığında neredeyse bedavadır. İkincisi, olayları biçimsiz metin olarak değil, yapılandırılmış ve zengin bağlamla üretmektir: Kim, ne, hangi işlemde, hangi sonuçla. İşlemin kimliğini, etkilenen kullanıcıyı ya da tenant'ı ve sonucu taşıyan yapılandırılmış bir olay, daha sonra yazılırken akla gelmeyen boyutlara göre sorgulanabilir.

Şema: Aktarılan bir kimlik olmadan bir işlem birbirine bağlı olmayan parçalara dağılır. Bu aktarım bir tasarım kararıdır, bir araç ayarı değil.

Gözlemin doğru birimi burada tekil log satırı değil, tam bağlamıyla işlemin kendisidir — istek, iş emri, transaction; baştan sona. İşlem başına zengin, yapılandırılmış bir olay üreten sistem gözlemlenebilirdir; ortak bir ipliği olmayan dağınık metin satırları üreten sistem ise üzerine kaç araç geçirilirse geçirilsin gözlemlenebilir değildir.

Trade-off. Bağlam aktarımı ve yapılandırılmış olaylar tüm kodda disiplin ve her sınırda biraz emek gerektirir — karşılığında sonradan istediğiniz soruyu sorabilme kazancı gelir.

Maliyet. Zengin bağlam olay başına daha fazla veri ve yeni yolların da kimliği taşımasına yönelik sürekli bakım demektir — code review'da uygulatılması gereken bir konvansiyon.

Ne zaman farklı karar veririz. Çok küçük, kısa ömürlü bir sistemde biçimsiz loglama yeterli olabilir; bağlam aktarımına yatırım ancak işlemler sınırları aştığında ya da sistem uzun yaşadığında karşılığını verir.

5. Geliştirme sırasında observability

Observability çoğu zaman salt bir production konusu olarak görülür. Bu bir hatadır, çünkü production'daki bir kesintiyi açıklayan sinyaller, geliştirme sırasında başarısız olan bir testi ya da belirsiz bir durumu açıklayan sinyallerle aynıdır. Observability'yi ancak ilk olaydan sonra tasarlayan, onu baskı altında ve eksik tasarlar.

Pratik mihenk taşı basittir: Bir geliştirici, sistemin belirli bir girdide neden öyle davrandığını yerelde — yalnızca sistemin ürettiği çıktılardan, debugger olmadan ve araya ek print'ler serpiştirmeden — açıklayabiliyor mu? Açıklayamıyorsa, aynı eksiklik production'da, yük altında ve etkilenen kullanıcılarla kıyaslanamayacak kadar pahalıya mal olur. Geliştirme sırasında observability bu yüzden bir lüks değil, yeteneğin gerçekten var olup olmadığının sınavıdır. Production için zaten ihtiyaç duyduğunuz yapılandırılmış olayları ve bağlam aktarımını en iyi kodu yazarken yaparsınız — çünkü kod hakkında en çok şeyi o an bilirsiniz.

Trade-off. Observability'yi erken inşa etmek ilk sürümü yavaşlatır, çünkü olayları ve bağlamı, bir olay faydalarını kanıtlamadan önce tasarlarsınız.

Maliyet. Bu emek, çalışan bir şey gösterme baskısının en yüksek olduğu anda ortaya çıkar — görünür ilerlemeyle doğrudan rekabet eder.

Ne zaman farklı karar veririz. Hiçbir zaman canlıya alınmayacak, atılacak bir prototip için bu yatırım yanlıştır; orada önemli olan tek şey hızlı öğrenmektir.

6. Production'da observability

Tasarlanan yeteneğin taşıyıp taşımadığına production'da karar verilir. Burada sinyaller gerçek yükle, gerçek kardinaliteyle ve bir olay anında yanıtlanması gereken gerçek sorularla karşılaşır. Bunun başarılı olup olmadığını üç şey belirler.

Birincisi kardinalitedir — ayırt edilebilir boyut değerlerinin sayısı. Zengin bağlam, istediğiniz soruyu sorabilmenizin nedenidir; aynı zamanda yüksek kardinalite en büyük maliyet etkenidir ve bazı sinyal sistemlerinde katı bir sınırdır. Hangi boyutları kalıcı olarak taşıyacağınıza ve hangilerini atacağınıza bilinçli olarak karar vermelisiniz. İkincisi örneklemedir: Her işlem eksiksiz kaydedilemiyorsa hangilerinin kaydedileceğini seçmelisiniz — ve bu sırada nadir, hatalı işlemlerin tam da dışarıda kalmamasını sağlamalısınız. Üçüncüsü “yeterince iyi”nin dilidir: Hangi davranışın kabul edilebilir olduğuna dair ölçülebilir hedefler; böylece alarmlar belki de zararsız olan nedenleri değil, kullanıcıların hissettiği semptomları hedefler.

Tüm bunların tüketicisi nöbetteki (on-call) kişidir. Production'da observability, bu kişi bir olay sırasında sistemi değiştirmeden yeni bir soru sorup yanıtlayabiliyorsa başarılmıştır. Bu başarılamazsa veri toplanmış, ama observability sağlanmamıştır.

Trade-off. Eksiksizlik ve kardinalite yanıt gücünü maliyet ve işletim emeğiyle satın alır; örnekleme ve saklama sınırları ise tasarrufu tam da nadir olanı kaybetme riskiyle satın alır.

Maliyet. Production observability'si kalıcı bir kalemdir: depolama, saklama, hedeflerin ve alarmların bakımı ve tamamını güncel tutmak için harcanan zaman.

Ne zaman farklı karar veririz. Düşük yüklü ve yüksek hata toleranslı bir sistem için cömert örnekleme ve kısa saklama süresi seçilir; dar hedefleri olan iş açısından kritik bir sistem için ise daha yüksek maliyetler bilinçli olarak üstlenilir.

7. Observability'nin maliyeti

Observability bedava değildir ve dürüst bir karar dokümanı bedelini faydası kadar açık söyler. Maliyetler üç alanda ortaya çıkar.

Birincisi veridir: Sinyaller hacim üretir ve zengin bağlam bu hacmi katlar. Depolama, aktarım ve saklama gerçek maliyettir ve kardinalite maliyetleri orantısız biçimde artırabilir. İkincisi çalışma zamanıdır: Sıcak yoldaki (hot path) enstrümantasyon biraz işlem süresine mal olur ve dikkatsizce yerleştirilirse kendisi bir gecikme kaynağına dönüşebilir. Üçüncüsü, çoğu zaman hafife alınanı, bilişsel yüktür: Düzensiz çok fazla sinyal, çok azı kadar işe yaramazdır — verinin içinde boğulursunuz ve yine de yanıtı bulamazsınız. Daha fazla toplamak, daha fazla anlamakla aynı şey değildir.

Bu metnin tamamına yayılan tutum buradan çıkar: Observability “mümkün olduğunca çok” değil, “istenen her soruyu yanıtlayabilmek için gerektiği kadar”dır. Hedef verinin maksimumu değil, yeteneği koruyan minimumdur. Bunun ötesindeki her şey içgörü getirmeyen maliyettir.

Trade-off. Her ek kayıt yanıt gücünü ve maliyeti aynı anda artırır; ustalık toplamakta değil, gereksiz olanı dışarıda bırakmaktadır.

Maliyet. Bilinçli sınırlar olmadan observability en büyük ve en hızlı artan işletim kalemlerinden birine dönüşür — ve bunu yaparken otomatik olarak daha fazla içgörü üretmez.

Ne zaman farklı karar veririz. Bütçenin ya da çalışma zamanının kesin biçimde sınırlı olduğu yerlerde, en sık soruları taşıyan az sayıda sinyale bilinçli olarak indirgenir ve nadir soruların yanıtlanmasının daha pahalı olacağı kabul edilir.

8. Tipik hatalar

Observability'nin başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi aynı hatanın varyasyonlarıdır: onu bir tasarım özelliği olarak değil, bir araç olarak ele almak:

• Yanıtın zaten içinde olacağı umuduyla her şeyi loglamak — ve soruları yanıtlayabilmek yerine hacimde boğulmak.
• Çok az ve bağlamsız loglamak; öyle ki her satır kendi başına durur ve hiçbir işlem birleştirilemez.
• Korelasyon ya da trace kimliği aktarmamak ve böylece nedensel yolu kurtarılamaz biçimde parçalara ayırmak.
• Yapılandırılmış olaylar yerine biçimsiz metin üretmek; öyle ki sonradan boyutlara göre sorgulama yapılamaz.
• Yalnızca bilinen-bilinenler için dashboard kurmak ve bununla öngörülmemiş olana hazırlıklı olduğunu sanmak.
• Kullanıcıların hissettiği semptomlar yerine nedenler üzerine alarm kurmak — ve zararsız alarmların selinde duyarsızlaşmak.
• Kardinalitenin sınırsız büyümesine izin vermek; ta ki maliyetler patlayana ya da sinyal sistemi katı bir sınıra dayanana kadar.
• Örneklemeyi, tam da nadir, hatalı işlemler dışarıda kalacak şekilde seçmek.
• Observability'yi ancak ilk olaydan sonra tasarlamak — baskı altında, eksik ve pahalıya sonradan tamamlanmış.
• Üreticiye özgü enstrümantasyona bağlanmak; öyle ki bir araç değişikliği tüm sisteme dokunur.

9. Karar kontrol listesi

Bir sistemin tasarımından önce ve tasarım sırasında sırayla netleştirilecekler:

• Açıklanabilirlik? Sistem, somut bir işlemde neden öyle davrandığını çıktılarından açıklayabiliyor mu — debugger olmadan ve yeni bir deployment olmadan?
• Bağlam aktarımı? Her işlem tüm sınırlar boyunca bir korelasyon/trace kimliği taşıyor mu?
• Yapılandırılmış olaylar? Olaylar yapılandırılmış ve zengin bağlamla mı üretiliyor; öyle ki sonradan akla gelmemiş boyutlara göre sorgulama yapılabilsin?
• Doğru birim? Gözlemin birimi tekil satır değil, işlemin tamamı mı?
• Sinyal seçimi? Her soru için yeterli olan en ucuz sinyal seçilmiş mi — trendler için metrikler, tekil vakalar için loglar, sınırlar ötesi yollar için trace'ler?
• Unknown unknowns? İnşa edilirken kimsenin bilmediği soruları da yanıtlamaya yetecek kadar ham malzeme var mı?
• Kardinalite ve örnekleme düşünüldü mü? Hangi boyutların kalıcı olarak taşınacağına ve nadir hataların örneklemden düşmeyeceğine karar verildi mi?
• Semptom alarmları? Alarmlar, belki de zararsız olan nedenleri değil, hissedilen semptomları ve ölçülebilir hedefleri mi hedefliyor?
• Maliyetler sınırlı mı? Observability azami olana değil, gerekli olana sınırlanmış mı — tesadüfen değil, bilinçli olarak?
• Geliştirmede denendi mi? Açıklanabilirlik ancak production'da değil, yerelde test edildi mi?

Bu sorulara cevap veremeyen, acil durumda susan bir sistem inşa etmiştir — ve acil durumda susmak, var olabilecek en pahalı özelliktir.

Sıkça Sorulan Sorular

Observability yalnızca daha iyi bir monitoring değil mi? Hayır, farklı bir yetenektir. Monitoring önceden sorulmuş soruları yanıtlar; observability ise çalışan sisteme, onu değiştirmeden, önceden bilinmeyen yeni sorular sormaya izin verir. Monitoring önceden tanımlanmış soruların alt kümesidir. İkisine de ihtiyacınız var, ama ikincisinin yerini birincisinden daha fazlasıyla dolduramazsınız.

Observability'yi sonradan ekleyemez miyiz? Bir kısmını evet, en önemli kısmını hayır. Bir korelasyon kimliğinin tüm sınırlar boyunca aktarılması ve olayların yapılandırılmış olarak üretilmesi, tüm koda yayılan tasarım kararlarıdır; bunları sonradan eklemek her sınıra dokunmak demektir. Bu yüzden observability sonraki bir işletim adımı değil, mimaridir.

Her soruya hazırlıklı olmak için her şeyi kaydetmeli miyiz? Hayır. Her şeyi kaydetmek, anlayışı garanti etmeden maliyet ve bilişsel yük üretir — verinin içinde boğulursunuz. Hedef, istenen her soruyu yanıtlama yeteneğini koruyan minimum sinyaldir. Observability “mümkün olduğunca çok” değil, “gerektiği kadar”dır.

Önce hangi sinyale ihtiyacımız var — loglar, metrikler mi yoksa trace'ler mi? Bu bir sıralamaya değil, soruya bağlıdır. Metrikler trendleri ucuza gösterir, loglar tekil vakayı açıklar, trace'ler sınırlar ötesindeki yolu gösterir. Tek bir serviste çoğu zaman metrikler ve yapılandırılmış loglarla idare edilir; işlemler birden fazla sınırı geçtiği anda trace'ler vazgeçilmez olur.

Bu, mimarların değil, işletim ekibinin konusu değil mi? İşletim tüketicidir, ama yetenek tasarımda doğar. Bir işletim ekibi yalnızca sistemin açığa vurduğunu gözlemleyebilir — ve neyin açığa vurulacağına onu inşa edenler karar verir. Bu yüzden observability nöbet hizmetine değil, mimarinin masasına aittir.

Observability bizi belirli bir sağlayıcıya bağlar mı? Yalnızca üreticiye özgü enstrümantasyona bağlanırsanız. Sinyal üretimini ve bağlam aktarımını kendi kodunuzda ve tarafsız tutarsanız, backend değiştirilebilir kalır. Yetenek sisteme aittir; sinyalleri değerlendiren aracı ise sisteme dokunmadan değiştirebilmelisiniz.

İleri okuma

• Mimari ilke olarak observability — bu dokümanın arkasındaki kompakt bakış açısı.
• On yıl sonra hâlâ çalışan yazılım — işletilebilirliğin ömür boyunca neden belirleyici olduğu.
• Dağıtık sistemlerde idempotency ve Asenkron işlemeyi devreye almak — dağıtık işlemler aktarılan bağlam olmadan izlenemez.
• Caching bir performans özelliği değildir — ölçemediğiniz bir cache bir varsayımdır.

Temelinde Batunet Engineering Method yatar: hata durumu için tasarlamak, ilk günden observability, kararları sistemin özelliklerine göre vermek.

Son mühendislik ilkesi

Kendi davranışını açıklayamayan bir sistem, normal durumda ne kadar doğru çalışırsa çalışsın, bitmiş değil yarım kalmış bir sistemdir. Çünkü yazılım iyi günlerinde değil, kötü günlerinde değerlendirilir ve kötü günde önemli olan tek soru şudur: Şu anda ne olduğunu söyleyebiliyor mu? Observability bu soruya verilen mimari yanıttır. Sonunda üstüne serpilen bir malzeme değil, baştan birlikte inşa edilen bir özelliktir — ya da en çok ihtiyaç duyduğunuzda elinizde olmayan bir özellik.

Anlamadığınız şeyi işletemezsiniz — yalnızca dayanmasını umarsınız. Observability, işletmek ile ummak arasındaki farktır.