Po co używać HealthChecks z .NET Core?

0

Czytam książkę "ASP.NET Core 3 and Angular 9" i jest tam pokazane użycie Health Check z .NET Core (https://docs.microsoft.com/en[...]th-checks?view=aspnetcore-3.0). Przykładowy kod z książki tworzy route /hc po którego wywołaniu zostają zapingowane 3 adresy i jest zwracany json z wynikami - które adresy odpowiedziały szybko, a które wolno, albo wcale. Nie za bardzo rozumiem po co do tego celu używać tych Health Checków, skoro można stworzyć sobie controller z routem i tam zapingować co trzeba bez zaciągania jakichś dodatkowych namespace'ów. Ogólnie nie wiem jakie są plusy stosowania Microsoft.AspNetCore.Diagnostics.HealthChecks. Czy mógłby ktoś podać jakieś zalety? A może ten przykład jest słaby?

Oto kod z książki"
Dodać do metody Configure (Startup.cs):

app.UseHealthChecks("/hc", new CustomHealthCheckOptions());

Dodać do metody ConfigureServices (Startup.cs):

services.AddHealthChecks()
    .AddCheck("ICMP_01", new ICMPHealthCheck("www.ryadel.com", 100))
    .AddCheck("ICMP_02", new ICMPHealthCheck("www.google.com", 100))
    .AddCheck("ICMP_03", new ICMPHealthCheck("www.does-notexist.com", 100));

Nowy plik ICMPHealthCheck.cs:

using Microsoft.Extensions.Diagnostics.HealthChecks;
using System;
using System.Net.NetworkInformation;
using System.Threading;
using System.Threading.Tasks;

namespace HealthCheck
{
    public class ICMPHealthCheck : IHealthCheck
    {
        private string Host { get; set; }
        private int Timeout { get; set; }

        public ICMPHealthCheck(string host, int timeout)
        {
            Host = host;
            Timeout = timeout;
        }

        public async Task<HealthCheckResult> CheckHealthAsync(
            HealthCheckContext context,
            CancellationToken cancellationToken = default)
        {
            try
            {
                using (var ping = new Ping())
                {
                    var reply = await ping.SendPingAsync(Host);

                    switch (reply.Status)
                    {
                        case IPStatus.Success:
                            var msg = String.Format(
                                "IMCP to {0} took {1} ms.",
                                Host,
                                reply.RoundtripTime);

                            return (reply.RoundtripTime > Timeout)
                            ? HealthCheckResult.Degraded(msg)
                            : HealthCheckResult.Healthy(msg);
                        default:
                            var err = String.Format(
                                "IMCP to {0} failed: {1}",
                                Host,
                                reply.Status);

                            return HealthCheckResult.Unhealthy(err);
                    }
                }
            }
            catch (Exception e)
            {
                var err = String.Format(
                    "IMCP to {0} failed: {1}",
                    Host,
                    e.Message);
                return HealthCheckResult.Unhealthy(err);
            }
        }
    }
}

Nowy plik CustomHealthCheckOptions.cs:

using Microsoft.AspNetCore.Diagnostics.HealthChecks;
using Microsoft.AspNetCore.Http;
using System.Linq;
using System.Net.Mime;
using System.Text.Json;
namespace HealthCheck
{
    public class CustomHealthCheckOptions : HealthCheckOptions
    {
        public CustomHealthCheckOptions() : base()
        {
            var jsonSerializerOptions = new JsonSerializerOptions()
            {
                WriteIndented = true
            };
            ResponseWriter = async (c, r) =>
            {
                c.Response.ContentType =
                MediaTypeNames.Application.Json;
                c.Response.StatusCode = StatusCodes.Status200OK;
                var result = JsonSerializer.Serialize(new
                {
                    checks = r.Entries.Select(e => new
                    {
                        name = e.Key,
                        responseTime = e.Value.Duration.TotalMilliseconds,
                        status = e.Value.Status.ToString(),
                        description = e.Value.Description
                    }),
                    totalStatus = r.Status,
                    totalResponseTime =
                    r.TotalDuration.TotalMilliseconds,
                }, jsonSerializerOptions);
                await c.Response.WriteAsync(result);
            };
        }
    }
}
2

Witam,

Zainstaluj sobie Seq, dodaj wysyłanie logów z aplikacji ASP.NET Core, doinstaluj Seq.Input.HealthCheck i pobaw się tym narzędziem. Zobaczysz że możesz w jednym miejscu oglądać kondycję swojej aplikacji i budować dashboard który pozwala Ci na szybkie rozeznanie się gdy coś jest nie tak. HC pozwala Ci na to byś takie dane wysyłał jako osobna informacja.

Pozdrawiam,
mr-owl

P.S. To jest tylko uproszczone rozwiązanie, zawsze można bazować na czymś innym ale koncept jest ten sam

5

Nie za bardzo rozumiem po co do tego celu używać tych Health Checków, skoro można stworzyć sobie controller z routem i tam zapingować co trzeba bez zaciągania jakichś dodatkowych namespace'ów

Tak na moje oko i bardziej ogólnie niż konkretnie o health checkach, to wszystko mógłbyś sam od ręki sobie napisać, ale gdy stosujesz istniejące mechanizmy, to łatwiej będzie komuś innemu w to wejść.

Dodatkowo może integracja z innymi bibliotekami - np. do twojego kodu raczej nie będą powstawać biblioteki, a do tych standardowych już jakieś rozszerzenia mogą się pojawiać.

Jeżeli już kwestia monitorowania, jakbyście zbierali dane do wykresów czasu wykonywania requestów? myślałem aby do middleware wstrzykiwać jakiś singleton z kolekcją <endpoint, duration> i ładować do niego te czasy, a później to wystawiać w healthchecku, ale zastanawiam się nad czymś lepszym

0
WeiXiao napisał(a):

Tak na moje oko i bardziej ogólnie niż konkretnie o health checkach, to wszystko mógłbyś sam od ręki sobie napisać, ale gdy stosujesz istniejące mechanizmy, to łatwiej będzie komuś innemu w to wejść.

Hmm, pod warunkiem, że ktoś zna te Health Checki i wie do czego służą metody AddHealthChecks, AddCheck, UseHealthChecks itd. Gdybym się wbił do projektu to łatwiej byłoby mi zrozumieć prosty route, bo nie byłoby w nim nic nowego.

Dodatkowo może integracja z innymi bibliotekami - np. do twojego kodu raczej nie będą powstawać biblioteki, a do tych standardowych już jakieś rozszerzenia mogą się pojawiać.

Jeżeli już kwestia monitorowania, jakbyście zbierali dane do wykresów czasu wykonywania requestów? myślałem aby do middleware wstrzykiwać jakiś singleton z kolekcją <endpoint, duration> i ładować do niego te czasy, a później to wystawiać w healthchecku, ale zastanawiam się nad czymś lepszym

Może tak być, że dopiero przy zaawansowanym użyciu dostrzeże się zalety i będzie potrzebować właśnie dodatkowych bibliotek.

2

Po to zeby kube wiedzial kiedy poda ubic

0

Nie wiem tez po co tez healthchecki.Kupa roboty i po co?
U nas healthcheckiem są użytkownicy i robią to za darmo.

1
nowyworek napisał(a):

U nas healthcheckiem są użytkownicy i robią to za darmo.

  • jeśli user ma kontakt z trzecią uS, zależąca od pierwszej i drugiej, co o nich wiesz?
  • ma kontakt z wybraną instancją usłgi -.> nie nie wiesz, jak pracują inne
  • zdecydowanie ma problem z ustawieniem limitów. Inne ma wq manago, któremu odebrano urlop - a inny szara myszka z księgowości

W ogóle pytanie jest źle postawione, ma być po co healthchecki w ogóle, idea uS jest "polyglot".

Sądzę (bo nie praktykuję) że są KONIECZNE dla hordy automatycznie zarządzanych instancji uS, ale mogą być pozytywne nawet dla niemal-monilitów, dadzą stałą (tzn jak awaria nam nie świta, human healthchecki nie reagują) i automatyczną jednolitą 1) formalnie informację.
Choć zdecydowanie, jeśli to nie są prawidłowo użyte Us, tylko "banalne" endpointy, wymóg jest oczywiście mniejszy

Najnowsze wydania Javy EE w wersji uS nie odchodzą od klasycznych definicji w API "podstawowym", ale mocno wspierają właśnie hchk i podobne.

Zawsze mi czegoś podobnego brakowało, np do backendu pracującego pod aplikacją tabletową dodałem znaczne logowanie, nie tylko śmiertelnych przypadków, a np czasy wszystkich ważniejszych endpointów
Ale ponieważ nie jest zestandaryzowane, analiza tylko ręcznie. marzył by się budzik "hej chłopy, czasy urosły o 50% od poprzedniego tygodnia"

1) nie będę używał słowa Kibana, bo jeszcze jeden kolega to znajdzie, i będzie syf w wątku.

1

W ogóle pytanie jest źle postawione, ma być po co healthchecki w ogóle, idea uS jest "polyglot".
Ja chciałem się dowiedzieć po co używać biblioteki Health Checkowej w .NET Core, a nie po co są healthchecki w ogóle. - piotrevic dziś, 14:08

"Po co" w sensie czy w ogóle, czy po co w sensie konkurencyjne do własnych rozwiązań?

Wróć do mojej wypowiedzi, że do własnego wynalazku mi brakuje łatwej do podpięcia analizy / wczesnego ostrzegania / whatever itd..
Nad uznanymi standardami na to można liczyć.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0