Asp.Net Core HealthChecks
Selamlar arkadaşlar, bugünkü yazımda microservice’ler hype olması ve container teknolojilerinin kullanılması ile birlikte daha da önem kazanan Health Checks’ten bahsetmek istiyorum.
Bir seçim yaptığınızda bir şeylerden vazgeçiyorsunuz ya da yeni sorumlulukları kabul ediyorsunuz demektedir. Evet biz de distributed yapıları seviyoruz ve uygulama alanı bulduğumuz noktalarda getirisi challenge’lardan fazla olduğu takdirde uygulamaya gayret gösteriyoruz.
Yönetmemiz gereken endpoint çoğaldıkça monitör etmekle kalmayıp, uygulamanın ayakta olup-olmadığını trace edip uygulamayı yeniden initialize edecek veya probleme göre aksiyon alacak otomasyonlar oluşturmamız gerekmektedir. Tamda bu noktada uygulamamızın sağlığı ile ilgili bize bilgi verecek Health Checks devreye giriyor.
Açıklayacak olursak Health Checks; bir endpoint üzerinden bize uygulmanın durumu hakkında bilgi veren middleware ya da library diyebiliriz.
.Net dünyasında ele alacak olarak olursak; .net core 2.2 ile hayatımıza girip Microsoft.Extensions.Diagnostics.HealtChecks namespace altında yer almaktadır. Net Core içinde built-in olarak gelen HealChecki’i middleware vasıtasıyla kolaylıkla implemente edebiliriz.
Liveness and Readness Healthchecks
Temel olarak 2 farklı yapıda Healthecks’i implemente edebiliriz.
Liveness Healtcheck: Nispeten daha basit olan healtcheck türüdür. Detaya inmeden, uygulamanın çalışıp- çalışmadığı hakkında bilgi vermektedir. Kısaca uygulama ayakta mı değil mi diye bilgi verir ancak bağlı olduğu yapılar ile ilgili herhangi bir detay içermez.
ReadnessHealtcheck: Liveness’ a ek olarak, uygulamanın çalışması için ihtiyaç duyduğu ek yapılar/bağlantılar (db, message broker, api, cache) hakkında da bilgi içermektedir.
Healthchecks Status
Evet yukarıda da belirttiğimiz gibi uygulamamızın durumunu bir endpoint üzerinden paylaşıyoruz. Bu endpoint uygulamamız hakkında bilgiyi health status üzerinden belirtmektedir. Burada 3 farklı status karşımıza çıkıyor.
Healthy: Uygulama tıkır tıkır çalışıyor 😃
Degreaded:Var aksaklıklar ama iş görür. Üzerine düşünmek gerekiyor🤔
UnHealthy: Ölmüş gömeni yok 😢
Biraz Pratik Yapalım
Çok fazla uzatmadan hemen HealthCheckSample adında bir web api proje oluşturuyorum. Basit olarak Health-Check middleware ini devreye sokmak için startup.cs içinde yapmamız gereken 2 şey; öncelikle kullanılacak servisleri register etmek için ConfigureServices icerisinde services.AddHealthChecks() methodunu call ediyoruz. Akabinde Configure içerisinde middleware i endpoints.MapHealthChecks methodunu call ederek aktif edip endpoint için path belirliyoruz.
Evet yukarıda görebileceğiniz gibi health-check endpoint’ini “/canary” olarak belirledik. Yine “/health” olarak belirlemek de çok yaygındır. Yurt dışında çalıştığım projede arkadaşım, health-check için neden canary endpoint inin kullandıkları ile ilgili aşağıdaki gibi açıklama yapmıştı.
it originates from when they used to take canary birds down into coal mines, if the canary died it meant there may be poisonous gas so they would evacuate the mine
O günden itibaren bende aynı şekilde “/canary” olarak devam ediyorum. Şimdi, projeyi ayağa kaldırıp canary endpoint’inin çağırdıgınızda aşağıdaki gibi bir ekranla karşılaşmanız gerekmekte.
Şimdiye kadar her şey çok güzel. Artık biraz daha detaya girme zamanı. Peki custom bir check nasıl ekleriz?
Aslında ihtiyacımız olan her şey built-in olarak geliyor. Sadece configure etmemiz gerekiyor.
Yukarıda görebileceğiniz gibi 3 farklı şekilde custom health-check tanımladık. BasicHealthCheck, IHealthCheck interface’ini implemente etmiş ve içeriği aşağıdaki gibidir.
Tanımladığımız tüm healt-checkler için farklı bir status tanımladık. Sonuç ne olacak dersiniz ?
Tahmin edeceğiniz gibi status Unhealty olarak döndü. İceride projenin çalışmasını engelleyen tek bir servis bile olsa bu projenin çalışmadığı anlamına gelir. Unhealty olan servisi kaldırdığımızda sonuc Degraded olacaktır.
Şimdiye kadar yaptığımız örnekler Liveness ile alakalıydı. Yani herhangi bir detay içermiyordu. Hadi endpoint result’ımızi biraz daha zenginleştirelim. Readness ile devam edelim.
Tanimlamış olduğumuz healthcheck’lere bakacak olursak name, status, description dan ibarettir. Zaman kaybetmeden class ımızı oluşturalım.
public class HealthCheckService
{public string Status { get; set; }public string Component { get; set; }public string Description { get; set; }}
Birden fazla servisimiz var ve bunların üzerinde genel bir status var. Evet simdi bu yapıyı wrap’leyen class’ımızı oluşturalım.
public class HealthCheckReponse{public string Status { get; set; }public IEnumerable<HealthCheckService> Services { get; set; }}
Şimdi custom response oluşturma vakti geldi. Healthcheck için endpoint belirlerken, bununla birlikte options parametresini de geçmemiz gerekiyor.
HealthCheckOptions ResponseWriter property ile custom responsunuzu oluşturacagınız function’ı verebiliyorsunuz. Bu function bize HttpContext ile birlikte healhtcheck servislerimiz ile ilgili raporu vermektedir. Size responsunuzu şekillendirmek kalıyor.
Projejimizi ayağa kaldırıp sonucu görelim.
Gördüğünüz gibi şimdi daha anlamlı bir response oldu. Bununla birlikte dilerseniz Status degerine göre httpresponseCode’unuzu da belirleyebilirsiniz.Ayrıca healthcheck için resposunuzu cache’leyebilirsiniz. Detaya girmemek ile bililikte dilerseniz https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-6.0 adresinden inceleyebilirsiniz.
Ek olarak, custom healthcheck’ten bahsetmiştik ancak muhtemelen ihtiyacınız olan tüm tool, service vs için package’ı AspNetCore.HealthChecks namespace altında arayarak bulabilirsiniz.
Sanırım yazıyı bitirmek için bir noktayız. Projenin kodlarina buradan ulaşabilirsiniz. Umarım keyif aldığınız bilgilendirici bir yazı olmuştur. Sağlıkcakla kalın.
