Controllare la telemetria con .NET Aspire

di Morgan Pizzini, in ASP.NET Core,

Dopo che abbiamo capito come gestire un portale frontend, un servizio backend e varie risorse come la cache e il database, tocchiamo ora la funzionalità per cui la dashboard di .NET Aspire eccelle: la telemetria.

Controllare i log applicativi di un'applicazione .NET è sempre un'operazione difficoltosa: prevede la ricerca, all'interno di una console, di un testo, che se la memoria non ci inganna, dovremmo aver scritto come una stringa in due pezzi con una pipe (|) nel mezzo. Questo è solo un esempio, ma rende bene l'idea del disordine e la mancanza di immediatezza visuale quando si va alla ricerca di un'informazione. Esistono sì strumenti alternativi, che permettono di salvare i log su database o su file, per poi comunque analizzare le informazioni tramite query o ricerca testuale.

Con .NET ASPIRE abbiamo un cambio che potremmo definire epocale. Dal momento zero viene inizializzata una comunicazione (REST o gRPC) tra l'host e l'applicazione, utilizzando un protocollo OTPL (OpenTelemetry protocol), attraverso il quale, tutti i log, le metriche e il tracing vengono condivisi e immagazzinati in memoria per essere mostrati in una dashboard interattiva in tempo reale.

Le modalità pratiche di utilizzo sono demandate al progetto: non vi sono delle regole precise, ogni sviluppatore decide dove ha valore loggare un'informazione e dove invece risulta superfluo.

Nei seguenti frammenti di codice si possono trovare alcune implementazioni basilari, da cui partire per poi sviluppare soluzioni più complesse e adattarle alle specifiche esigenze del progetto.

In una chiamata API possiamo vedere: momento della richiesta, durata, stato della risposta, eccezioni

public class TestController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new { Name = "Morgan" });
    }

    [HttpPost()]
    public IActionResult Post()
    {
        throw new Exception("Errore non previsto!");
    }
}

Se utilizziamo Entity Framework, e quindi un DBContext, il log ci consentirà di sapere i tempi di risposta e tutta la traccia che parte dalla chiamata fino alla query, permettendoci di trovare i colli di bottiglia.

public class ApplicationDbContext : DbContext
{
    public DbSet<User> Users { get; set; }

    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { }
}

// Controller
[HttpGet]
public async Task<IActionResult> Get()
{
    var users = await _dbContext.Users.ToListAsync();
    return Ok(users);
}

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

I più letti di oggi