In passato ci siamo occupati della funzionalità di HealthCheck di ASP.NET Core 2.2 (https://www.aspitalia.com/script/1316/Verificare-Funzionamento-Applicazione-ASP.NET-Core-2.2.aspx) e abbiamo visto come, in uno scenario di produzione, sia indispensabile avere a disposizione un endpoint che possiamo invocare per stabilire se l'applicazione sia in uno stato "healthy" o no.

Spesso le nostre applicazioni non sono isolate, ma si collegano ad ulteriori servizi, che a loro volta potrebbero essere non disponibili. In questo scenario, possiamo monitorare anche la disponibilità di queste dipendenze tramite il pacchetto NuGet AspNetCore.HealthChecks.Uris. Un tipo di controllo di questo tipo acquista particolare importanza nelle casistiche in cui abbiamo uno scenario di rete complesso, come quello di una Azure Web App che debba connettersi in VPN con una rete on-premise. Effettuare un "ping" verso un servizio interno è il modo più semplice di verificare che la configurazione di rete sia corretta e la VPN stia funzionando come previsto.

Il primo passo, allora, è quello di installare il package che abbiamo menzionato:

Install-Package AspNetCore.HealthChecks.Uris

Successivamente, nel nostro metodo ConfigureServices di Startup possiamo scrivere qualcosa simile al codice in basso:

public void ConfigureServices(IServiceCollection services)
{
  // .. altro codice qui ..

  services.AddHealthChecks()
    .AddUrlGroup(config => 
    {
      config.AddUri(new Uri("http://requestbin.fullcontact.com/1klkxaz1"))
        .UsePost();
    });
}

Nell'esempio abbiamo configurato lo URI del servizio che vogliamo testare, specificando che vogliamo effettuare una chiamata in POST. Per default, questo health check ha successo se la risposta ha uno status code che indica successo. Se necessario, possiamo usare i metodi ExpectHttpCode o ExpectHttpCodes per indicare altre tipologie di risposte HTTP che possiamo accettare.