Bir web uygulamasını dağıtan bir sistem için sağlık kontrolünün kapsamı ne olmalıdır?

Bugün bir web uygulamasını dağıtmak için bir düzenleme sistemi olan uzun süredir devam eden bir hizmet için "bir sağlık kontrolü yazma" görevim vardı.

Böyle bir sağlık kontrolünün kapsamının ne olacağını belirlemeye çalışıyorum ve sağlık kontrolünün kapsamıyla ilgili şu soruları buldum:

1. Düzenleme sistemi görevin yürütüldüğünü bildiriyorsa hizmeti sağlıklı saymak yeterince iyi mi?
2. Yoksa her servise manuel olarak ping atmalı mıyız?
3. Yoksa daha ileri gitmeli ve bir web sayfasını göstermek gibi web uygulamasının yapması gereken şeyi yapmasını sağlamaya mı çalışmalı?
4. Sağlık kontrolü bazı bağımlı hizmetlerin de çalışıp çalışmadığını kontrol etmek zorunda mı? Bir veritabanı veya düzenleme sisteminin kendisi gibi. Yoksa başka bir sağlık kontrolünün sorumluluğu mu?
5. Ve son olarak, bağımlı hizmetlerden biri ölmüşse ve web uygulaması daha sonra başarısız olursa, web uygulaması kötü bir sağlık rapor etmeli mi yoksa sağlık durumu iyi mi, çünkü web uygulamaları hatası değil mi?

Bunların 5 ayrı soru olduğunu biliyorum, ancak hepsi bir web uygulamasını dağıtan uzun süreli bir hizmet için sağlık kontrolü kapsamıyla ilgilidir, bu yüzden onları tek bir soruda gruplandırmanın daha mantıklı olacağını düşündüm.

Bunu benim için uygulamak zor çünkü sağlıklı olanın tanımının veya bunun gibi bir şey için standart bir sağlık kontrolünün nasıl olması gerektiğinden emin değilim.

Bu özel hizmet için bir sağlık kontrolü ne içermelidir?

Sağlıklı olanın tanımı nedeniyle bunu uygulamak zordur

Burada kendi sorunuzu cevapladınız. Sağlık kontrolünün tanımı değişecektir, çünkü sağlıklı olan şey değişir. Aynı zamanda sağlık kontrolünü neyin verdiğine de bağlıdır.

Kendinize sormak için iyi bir soru, "askerin bakış açısıyla, kontrol edilen hizmet beklendiği gibi çalışıyor mu?" Bu sizseniz, onu tanımlayabilirsiniz. Başka bir ekip / hizmetse, sağlık kontrolleri için standart / spesifikasyonun ne olduğunu tanımlamanız gerekir.

Büyük bir organizasyonda, bir sağlık kontrolünün ne yapması gerektiği konusunda bir çeşit standardınız olacaktır. Anlamak.

Özellikle burada, webapp örneğiniz, webapp sağlıklı olmadığı için sağlıklı dönmemesi gerektiği anlamına gelir. Ama belki de "sağlıklı" tanımınız bunu "tamam" olarak içerir. Bu, yukarıdaki gereksinimler tartışmasının bir parçasıdır (yine yalnızca kendi kodunuz olsa bile).

Başka bir yerde belirtilmediğini varsayan tavsiyem, farklı hatalarla ilişkili bir tür durum koduna sahip olmak olacaktır. Webapp'ı sorguladığınızda, "bağımlı hizmet öldü" yazan bir hata döndürebilir ve böylece istemciniz (veya sağlık denetimini gerçekleştiren her ne olursa olsun) istemcinin neden öldüğünü bilebilir .

Düzenlenen sorular için:

Düzenleme sistemi görevin yürütüldüğünü bildiriyorsa hizmeti sağlıklı saymak yeterince iyi mi?

Hayır, sadece bir işlemin yürütülmesi, bunun askıda kalmadığı, tamamen işlevsel olmadığı veya çok çeşitli başka olasılıklar olmadığı anlamına gelmez.

Yoksa her servise manuel olarak ping atmalı mıyız?

Bu, uygulama işlevselliğinizin kapsamına bağlı olarak işe yarayabilir. Hizmetin doğrulanması "yaşıyor musunuz?" ping o zaman tüm gereken bu olabilir. Ancak hizmet kolayca "canlı ve duyarlı ama aslında çalışmıyor" o zaman belki de diğer şeyleri kontrol etmek gerekir.

Yoksa daha ileri gitmeli ve bir web sayfasını göstermek gibi web uygulamasının yapması gereken şeyi yapmasını sağlamaya mı çalışmalı?

Sağlığınız, beklenen işlevselliğin beklendiği gibi çalıştığından emin olmalıdır.

Siz de o yanlış pozitif verecek şekilde tüm Healthcheck kurtulmak olabilir, uygulama döner "sağlıklı" ve ne yapması gerektiğini yapamıyorsan (şaşırtmak saymıyorum halt sorunu tamir etmeye çalışan kişiden - 'hey web sunucumuz sağlıklı gösteriyor, neden sayfayı göremiyoruz? ').

Sağlık kontrolü bazı bağımlı hizmetlerin de çalışıp çalışmadığını kontrol etmek zorunda mı? Bir veritabanı veya düzenleme sisteminin kendisi gibi. Yoksa başka bir sağlık kontrolünün sorumluluğu mu?

Bu biraz değişiyor. Hizmetiniz başka bir hizmete bağlıysa, söz konusu etkileşimin niteliği uygulamanızda kendisine gönderilen ve sağlık kontrolüne dahil edilen API / ağ çağrılarına yansıtılmalıdır.

Örneğin, bir veritabanından okuma yapan bir web sunucusunun veritabanında yerleşik durum bilgisi olması gerekir - yoksa API çağrıları başarısız olursa web uygulaması kilitlenir. Sağlık kontrolünüze dahil etmek için bu çağrıları önemsiz bir şekilde değiştirebilirsiniz.

Ancak, hizmetiniz herhangi bir doğrulama yapmadan dinleyen tüketicilere etkinlik gönderiyorsa , uygulamanızın işlevselliği açısından tüketicilerin canlı olması daha az önemlidir . Uygulamanıza "Sağlıklı" iletileri gerçekten almıyor, gönderiyor.

Temel olarak, hizmetinizin diğer hizmetlerle konuşması ve sağlığını yine de doğrulaması gerekiyorsa, hizmetinizin sağlık kontrolü için en azından temel bir kontrol düzeyine sahip olmak mantıklıdır. Uygulamanız bunu zaten ele alacağı için (ya da rastgele çöküyor, sanırım) bu, söylediklerimi kavramsal olarak anlamalıdır.

Ve son olarak, bağımlı hizmetlerden biri ölmüşse ve web uygulaması daha sonra başarısız olursa, web uygulaması kötü bir sağlık rapor etmeli mi yoksa sağlık durumu iyi mi, çünkü web uygulamaları hatası değil mi?

Bu temel olarak yukarıda cevaplanmıştır. Benim tavsiyem, sağlık kontrolünüzün bu bilgiyi veren bir kodu / mesajı / her şeyi iade etmesini sağlamaktır. Her iki bilgi de önemlidir: hizmetinizin ihtiyaç duyduğu bağımlı hizmetin öldüğü ve sonuç olarak hizmetinizin beklendiği gibi çalışmadığı.

Genel olarak bir sağlık kontrolü sadece "canlı mı ve yanıt veriyor mu?" Bundan daha ileri kontroller son derece uzmanlaşmıştır ve tamamen sistemin kullanımına bağlıdır. Bir sistemin istekleri doğru bir şekilde işlediğini kontrol etmek için ekstra mil gidip gitmediğiniz size kalmış, ancak önce temelleri yapmanız gerekir - orada olup olmadığını kontrol edin, istekleri alabildiğini kontrol edin ve bir yanıt döndürür.

Bir sağlık kontrolü yapmanın en kolay yolu, hizmetin diğer komutların kullandığı mekanizmayı kullanarak işlediği, bir onay döndürmekten başka bir şey yapmayan bir komut yazmaktır. Bu, canlılığı gösterecek ve sistemin yanıtları alıp işleyeceğini gösterecektir.

Bağımlı sistemleri kontrol etmek sağlık kontrolünün bir parçası değildir, basit ve bağımsız olmasını sağlamanız gerekir. Her bağımlı servise bir sağlık kontrolü ekleyin. Bu şekilde çalışan, sağlıklı sistemlerin bir listesini alabilir ve birinin ne zaman kötü gittiğini kolayca anlayabilirsiniz, hangisinin olduğunu!

Deneyimlerime göre, kritik hizmetler aşağıdaki özelliklere sahip olma eğilimindedir:

Kalp atışı

Hizmet düzenli olarak çalışıyorsa, bu, hizmet gövdesinin belirli bir zamanda başladığını belirtmek için bir zaman damgasıyla birlikte bir günlük dosyasına veya benzerine bir satır yazar.

Galeta unu

Yukarıdakine benzer şekilde, ekmek kırıntıları genellikle hizmetin hizmet gövdesini beklendiği gibi ve akışta nerede olduğunu işlediğini göstermek için yöntem adının (ve bazen parametrelerin) bir dökümüdür. Bunlar daha fazla çıktı üretebildiklerinden, bunlar genellikle yapılandırma dosyaları veya benzeri birimler tarafından kontrol edilir, böylece hizmet bir kez oturduktan sonra kapatılabilirler.

Çeşitli sunucuların, hizmetlerin ve veritabanlarının durumu ve benzerleri gibi birçok başka şey eklemek cazip gelebilir. Bu hiç şüphesiz değerli olsa da, çok kapsamlı bir şey yazmamanızı tavsiye ederim. Bunlar kendi huzurunuz için yararlı olabilir, ancak çeşitli temas noktalarından sorumlu taraflar orada olduklarını bildiğinde bu tür güvenceler istismar edilir. Bunu bilmeden önce, tüm şirket için bir teşhis uygulaması yazıyor olabilirsiniz.