Health Check nedir:

Health Check servisleri; uygulamanın sağlık durumunun kendisi tarafından ölçülebilmesini ve bunu dışarıyla paylaşmasını sağlayan, uygulamanın iç metriklerini kontrol eden bir servistir. Son yıllarda AWS, Azure gibi Public Cloud firmalarının sunduğu PaaS yapıları üzerinde uygulama barındırmanın yaygınlaşması ve microservislerin günlük operasyonlarımızı daha fazla işgal etmeye başlanmasıyla beraber sıcak bir konu haline gelmiş olsa da aslında uzun zamandır var olan; bir uygulama izleme ve performans ölçme yöntemidir.

Birçok izleme aracından/yönteminden farklı olarak tamamen bizim kendi uygulamamız için kendimizin geliştirdiği ve metriklerini belirlediği bir endpoint/servis olma özelliğini taşımaktadır. Kafanızda biraz daha canlandırmam gerekirse uygulama üzerindeki ki HC endpoint’i çağrıldığında (Örnek http://uygulalam/health) uygulamanın düzgün çalıştığını işaret eden bir ifade dönmektedir. Bu ifade kimi zaman basit bir “http 200“olabilirken, karmaşık bir iş süreci çalıştırarak dönen sonucu diğer sistemlerle karşılaştırarak sapma olup olmadığının sonucu olabilir. Buradaki kritik performans ve risk kriterleri tamamen size ve uygulamanızın türüne göre değişebilir.

Neden HC servisine ihtiyacım var?

Birçok çalışma arkadaşımla bu servislerin kullanımı üzerine tartışırken zaten hali hazırda farklı alt yapı, OS ve APM izleme araçlarının kullanıldığını; ekstra çaba harcayarak böyle endpoint yazmanın mantığını sorguluyorlar. Öncelikle HC diğer tüm izleme servislerinden farklı olarak uygulamanın içerisinden bir görüş sunmaktadır, bunun haricinde uygulamanın nasıl çalışması gerektiğini ve iç mantığını en iyi yazılım geliştiricinin kendisi bilmektedir. Bu yüzden kendi yazdığı servis ile uygulama mantığında ki sapmalar, thread leak, deadlock, hatalı konfigürasyonları daha kolay tespit edebilir üstelik uygulamaya her yeni sürüm geçerken HC servisini de buna göre güncelleyerek izlenen parametrelerin güncel kalmasını sağlayabilir. Burada şunun da altını çizmek istiyorum HC diğer izleme araçlarının yerine gecen değil onların tamamlayıcısıdır.

Health Checklerin Yapısı

Health Check servislerinin yapısına baktığımızda bir uygulama (monolitik veya microservice) üzerinde barınan, dışarıdan çağrılabilen ve çağrıldığında anlamlı bir cevap dönebilen bir servis ile sürekli bu servisler üzerinden uygulamaların sağlıklarını kontrol edip gerekli aksiyonları tetikleyen bir koordinatörden oluşmaktadır.

Koordinatör; herhangi bir load balancer, Konteyner orkestrasyonu yapabilen K8, Openshift gibi platformalar veya mikroservisler için kullanılan service discovery araçları olabilir (Consul gibi). Koordinatörler Health Check servisinin döndüğü sonuca göre sistemin kararlı olmadığına karar verdiğinde çok farklı aksiyonları tetikleyebilmektedir.

Mesela;

• Load balancer http 200 cevabı alamadığında uygulamaya giden trafiği kesip başka bir yere yönlendirebilir
• Openshift üzerinde çalışan bazı POD’ların latencylerinin istenen değerin üzerine çıktığını yakalayıp o servis için container sayısını artırabilir
• Kendi yazdığınız bir koodinatör ile uygulamanın veritabanına erişemediğini yakalarsa uygulama sunucusunu yeniden başlatacak ansible playbook’unu çağırabilir.

Burada alınabilecek aksiyonların türü ve sayısı tamamen size kalmış durumdadır. Koordinatör olarak kullanılan araçların genellikle yetkinlikleri farklı olsa da hemen hemen hepsi aşağıdaki aksiyonları yapabilir.

• Uyarı oluşturma
• Trafik yönlendirme/kesme
• Sunucuyu yeniden başlatma
• Yeni sunucu/konteyner kurulmasını başlatma; burada K8, Openshift, cloud foundry gibi ürünler out-of-box bu özelliğe sahipken diğer koordinatör tiplerini farklı api’lar veya araçlarla kombine ederek yapabilirsiniz.

Konumlandırma:

Microservisler, hayatımıza birçok rahatlık getirmesinin yanında yeni riskler ve yönetim zorluklarını da beraberinde getirmektedir. Arka tarafta artık Ops ekibinin kontrolüne ihtiyaç duymadan uygulamalar gerekli durumlarda container/node sayısını artırabiliyor, azaltabiliyor veya bir anda eski sürümleri öldürüp yenilerini servis kesintisine sebep olmadan devreye alabiliyor. Doğal olarak monolitik uygulamaları microservise dönüştürürken birkaç sunucudan onlarca, yüzlerce hatta binlerce container’a bölünmüş olabilir, bu kadar geniş bir havuz içerisinde tek bir microservisin doğru çalışmaması ve bunu doğru zamanda tespit edilememesi çok ciddi sorunlara sebep olmaktadır.

Kullanıcılarınızın bir ödeme sisteminde para transferi yapmaya çalıştığını hayal edin ve sadece bir grup kullanıcı ödeme yapmak istediklerinde hata alıyorlar ve tekrar denediklerinde sorun olmuyor. Tüm süreçte sorunlu adımı bulmak ve bu adım içerisindeki tüm container’ları tek tek kontrol etmek canlı sistemlerde her zaman mümkün olmuyor. Öte yandan container’ların ayak izini küçük tutabilmek için daha geleneksel dünyadan alışkın olduğumuz ajan bazlı izleme araçlarından da kaçınmak istenmektedir.

Health Check endpoint’inin yaratılması ve doğru metriklerin kurgulanması burada çok kritik bir adım olmaktadır. Çok fazla metrik belirlenip veya sürekli endpointe sorgulama yaparak sistem üzerinde de ek yük yaratılmamasına dikkat etmek gerekiyor. Benim önerim şu metriklerin mutlaka takip edilmesi yönündedir;

• Servisin bağımlı olduğu API’lara erişip erişemediği; burada karşı tarafın varsa health check servisini çağırıp ona göre kontrolü yapabilir
• Basit OS seviyesinde kontroller; disk doluluğu veya kritik bir path’deki dosyaların büyüklüğü olabilir
• Kritik servislere erişip erişemediği; mesela SQL sunucusuna bağlantı açabiliyor mu? MQ sunucusuna erişebiliyor mu gibi?
• Uygulama üzerinde açılmış threat sayısı; bazen uygulama üzerinde çok fazla veya çok az threat’in açık olması bir anormaliye işaret ediyor olabilir.

Bu 4 tip metrik haricinde her zaman performans veya iş süreçleri üzerinde de metrikler koyabilirsiniz ama burada bahsettiğimiz metrikler uygulamanız ne olursa olsun platform seviyesindeki çoğu hatayı yakalamanızı sağlar.

Bu tip bir endpoint’i sadece microservislerde değil monolitik uygulamalarınızda da kullanabilirsiniz, bu servis sayesinde farklı bir bakış açısı yakalar hem de kök sebebi bulma konusunda ciddi kolaylık sağlanır.

Son olarak mutlaka standart bir JSON çıktısı belirleyip tüm uygulamalarınızda bunu kullanmanızdır, böylelikle bir birine bağımlı uygulamalarda bağlı oldukları uygulamaların hc endpointlerini çağırarak gerekirse kontrolleri yapabilir ve sorun anında ona göre bir aksiyon alabilirler.