Cloud Native Uygulamalarda İzlenebilirlik — 1. Bölüm
Çoğunlukla gözlemleme (monitoring) ile karıştırılsa da özellikle Cloud Native ve dağıtık uygulamaların yaygınlaşmasıyla ortaya atılan izlenebilirlik (observability) kavramı klasik anlamıyla gözlemlemenin çok daha fazlasını içerdiğini söylememiz gerekli. Yazının ilk kısmı olan “İzlenebilirlik Nedir?” başlığında bu kapsamında sayılabilecek tüm bu uygulamaları inceleyeceğiz. Sonraki bölümlerde “Nasıl Uygulanır?” başlığı altında tüm bunların Cloud Native uygulamalar için defacto haline gelen Kubernetes ortamını da resmin içine katarak nasıl uygulanabileceğine bir miktar bakacağız.
Not: Yazıyı kaleme alırken mümkün olduğunca Türkçe terimleri kullanmaya çalıştım. Bu Türkçe terimlerin bir kısmını sıklıkla kullanıyoruz (örn. görselleştirme), bazılarının ise İngilizce karşılığına daha aşinayız (örn. monitoring). Bir kısmının da İngilizce karşılığı Türkçe’ye yerleşmiş durumda (örn. loglama). Kafa karışıklığına yol açmamak için terimi ilk kullandığımda yanına İngilizce halini de ekleyip, sonraki kullanımlarda Türkçe ile devam etmeyi seçtim.
İzlenebilirlik Nedir?
Yazının başında da bahsettiğim gibi gözlemleme (monitoring) ile birlikte loglama (logging), metrik toplama (metrics collection), takip etme (tracing), görselleştirme (visualization) ve uyarma (alerting) işlerinin tamamına izlenebilirlik diyebiliriz. Yani bu pratiklerin hepsini optimum ölçüde yerine getirdiğimizde servislerimizi izleyebildiğimizi söyleyebiliriz.
The goal of an observability team is not to collect logs, metrics or traces. It is to build a culture of engineering based on facts and feedback, and then spread that culture within the broader organization. — Brian Knox (DigitalOcean)
Gözlemleme (Monitoring)
Gözlemleme en basit anlamıyla verdiğiniz servisin erişilebilir olup olmadığını dış gözlemci gözüyle incelemektir. Yani bir servisin HTTP Status Code OK (200) dönüp dönmediğinin belli aralıklarla kontrol edilmesi yapılabilecek en temel gözlemleme çalışmasıdır. Daha detaylı bir gözlemleme için yapılan isteğe dönen yanıtta belirli bir değer aranabilir veya istek ve yanıt arasında geçen süre ölçülüp belirli bir eşik değerinin üzerine çıkması halinde uyarı mekanizmaları harekete geçirilebilir.
Gözlemleme yöntemleri her zaman servisimizin kullanıcısı gözüyle yapılır, bu nedenle kara kutu kontrolü (black box check) adıyla da anılır. Servisimizin bizim bakış açımızdan çalışır halde olması her zaman kullanıcıya hizmet verebileceği anlamına gelmediğinden bu bakış açısı her zaman yararlıdır. Ancak gözlemleme araçları ile inceleyebileceğimiz durumları önceden planlamış olmanız gerektiğinden bu yöntemler ile ancak “önceden kestirilebilir problemleri” yakalama şansımız olabilir. Ayrıca gözlemleme yaklaşımı bir problem olduğu anda bizi bundan haberdar edebilir, yani gözlemleme yöntemleri ile ancak reaktif aksiyonlar almamız mümkün olabilir, proaktif olarak yani bir problem oluşmadan önce bizi uyarma şansı genellikle olmaz. Son olarak gözlemleme ile bir problemin oluştuğunu yani ne olduğunu görebiliriz ancak bu yaklaşım son kullanıcı gözüyle yapıldığı için neden olduğu hakkında bir fikir vermeyecektir.
Loglama (Logging)
Loglama, muhtemelen her uygulama geliştiricinin en aşina olduğu izleme yöntemidir çünkü loglama ancak uygulama geliştiricinin uygulamaya loglama kodlarını eklemesiyle mümkün olur.
Loglama, doğru uygulandığı takdirde bir problem oluştuğunda ne olduğu bilgisinin yanı sıra neden olduğu bilgisine de kolayca ulaşmamızı sağlayabilir. Ancak tıpkı gözlemleme yönteminde olduğu gibi loglama da ancak “önceden kestirilebilir problemleri” yakalamızda yardımcı olabilir. Hatta çoğu zaman bir hata oluştuğunda o hata hakkında elle tutulur bilgi edinmek için log seviyesini yükseltip aynı hatanın tekrarlanmasını beklemek gerekebilir. Yani loglama yöntemi de proaktif olmaktan ziyade reaktif bir yöntemdir.
Metrik Toplama (Metrics Collection)
Metrikler loglardan farklı olarak sayısal değerler içeren ve uygulamamızın çalıştığı süre boyunca herhangi bir t anında uygulamamızın kullandığı hafıza miktarı, o andaki CPU tüketimi gibi temel donanım verilerinden, uygulamamıza özel takip etmek istediğimiz tüm sayısal bilgiye erişmemizi sağlar. Metrik verileri sayısal olduğu için loglama işleminden çok daha düşük maliyettedir, dolayısı ile loglardan çok daha yüksek sıklıkta metrik verisi toplanabilir. Veriler sayısal olduğu için belirli aralıklarla tutulan bu verilerin zaman içindeki değişimi bize uygulamamızda problemler oluşmadan önce haberdar olmamızda yardımcı olabilir. Örneğin geçen her saatte CPU kullanımı %10 artan bir uygulamanın bir kaç saat sonra yanıt veremez hale geleceğini tahmin etmek çok zor değildir. Hatta geçmiş metrik verisi ve oluşan hatalar eşleştirilerek yapılan makine öğrenmesi (Machine Learning, ML) modelleri ile çok daha isabetli problem tahminlemeleri yapılabilmektedir. Bu nedenle toplanan metrik verisinin zaman serisi veritabanlarında (time series database) tutulması ve bu zaman ekseninde grafiğe dökülerek izlenmesi çok yaygın bir yaklaşımdır.
Takip Etme (Tracing)
Loglama, metriklerin takibi gibi yöntemler bize uygulamamızın bileşenlerinin durumları hakkında fikir verse de, özellikle dağıtık sistemlerde son kullanıcıdan gelen bir isteğin bizim sistemlerimiz içinde nasıl bir yaşamı olduğunu anlatamazlar. Bu nedenle oluşturulan takip mekanizmaları, isteğin bizim sistemlerimize girişinden itibaren sistemimizi oluşturan servisler arasındaki tüm iletişimi ve hatta veritabanları gibi destek servisler ile bize ait olmayan dış servislerle etkileşimimizi takip ederek görselleştirmemize ve bu hareketlerle ilgili metrikleri toplamamıza yardımcı olurlar. Yani son kullanıcının talebi ile bizim ona yanıt döndüğümüz zaman aralığı içindeki sürenin servis bazında kırılımına ulaşmamızı sağlarlar.
Uygulamamızın tüm bileşenlerinin metrikleri beklediğimiz değer aralığında dahi olsa aralarındaki network bağlantısında yaşanacak bir sıkıntının veya metriklerini takip edemediğimiz bir dış servisteki gecikmenin bizim servislerimize olası yansımalarını izlememiz, sistemlerin birbirleri ile bu kadar etkileştiği bir dünyada olmazsa olmaz hale gelmektedir.
Görselleştirme (Visualization)
Sistemimizi izleyebilmek için topladığımız tüm verileri ham haliyle takip etmek, The Matrix filmindeki monitörlere bakarak bir anlam çıkarmaya çalışmaya benzeyecektir.
Bilimsel çalışmalar (http://misrc.umn.edu/workingpapers/fullpapers/1986/8611.pdf) insan beyninde görsel verinin metin verisinden 60.000 kat daha hızlı işlendiğini ve saklanan verinin %90 oranında görsel veri olduğunu göstermiştir. Bu nedenle bir bakışta sistemimizin o andaki durumunu anlamamızı sağlayacak görselleştirme araçlarını kullanmak gerekmektedir.
Uyarma (Alerting)
Sistemimiz üzerinde izlenebilirliğin diğer tüm bileşenlerini devreye alsak da uyarma mekanizmaları devreye alınmadan sistemimizde olup bitenden haberdar olmamız her zaman mümkün olmayabilir. Bu durumda uygulamalarımızı 7/24 takip edecek ve beklenmedik bir durumda bu duruma dikkatimizi çekecek bir sistem devreye almamız gerekecektir. Sistemde oluşacak problemleri kullanıcılardan önce tespit etmek ve mümkünse çözmek kullanıcı memnuniyeti ve prestij açısından olduğu kadar, değer üretiminin de kesintiye uğramaması açısından kritiktir.
Yazının bu ilk bölümünde İzlenebilirlik başlığı altında inceleyeceğimiz kavramların neler olduğunu incelemiş olduk. Takip eden bölümlerde bu kavramları hangi araçlarla ve yöntemlerle gerçekleştirebileceğimize bakacağız.
Serinin ikinci bölümüne buradan erişebilirsiniz.
