0

[Article] Nueva herramienta en .Net “dotnet-monitor”

Desde algunas versiones previas de .Net 5, venimos escuchando de esta nueva herramienta, ya esta disponible de forma experimental y se llama “donet-monitor”. En esta publicación veremos de qué trata y cómo nos ayudará en el diagnóstico de nuestras aplicaciones.

La mayoría de nosotros ejecutamos aplicaciones en varios entornos, desde locales hasta producción, recolectando de componentes información de registro, seguimiento, volcado de procesos, etc. Recolectar tanta cantidad de información nos dificulta, en muchos casos, el análisis de estos. Aquí es donde aparece dotnet-monitor con el objetivo de simplificar este proceso de exponer una API-REST independiente de la aplicación que se ejecuta.

Veremos los siguientes puntos:

  • Cómo configurar dotnet-monitor.
  • Qué artefactos de diagnóstico se pueden recopilar.
  • Cómo recolectar cada uno de los artefactos.

Configurar

dotnet-monitor tenemos 2 caminos para configurar la herramienta:

  1. Como una herramienta global
  2. Como una imagen docker que es posible obtener desde Microsoft Conteiner Reistry (MCR)

Debemos tener en cuenta que dependiendo del entorno al cual apuntamos, tendremos diferentes pasos de configuración. De forma predeterminada, dotnet-monitor se une a 2 diferentes grupos de URL.  Podemos configurarla por medio de parámetros 

Localmente

Para comenzar a utilizar dotnet-monitor debemos tener instalada .Net es nuestra máquina. Para instalarlo de manera global debemos ejecutar el siguiente comando:

dotnet tool install -g dotnet-monitor --add-source https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet5-transport/nuget/v3/index.json --version 5.0.0-preview.*

Una vez instalado podemos poner manos a la obra. Para comenzar a recolectar información ejecutaremos el siguiente comando desde una consola:

dotnet monitor collect

Docker

Si deseamos utilizar docker, poder tomar la imagen desde Microsoft Container Registry usando los comando de docker:

docker pull mcr.microsoft.com/dotnet/nightly/monitor

Una vez descargada la imagen y disponible en nuestro equipo, ejecutaremos los comandos para crear una instancia de esta y configurar un volumen:

docker volume create diagnosticserver
docker run -d --rm -p 8000:80 -v diagnosticsserver:/tmp mcr.microsoft.com/dotnet/core/samples:aspnetapp
docker run -it --rm -p 52323:52323 -v diagnosticsserver:/tmp mcr.microsoft.com/dotnet/nightly/monitor:5.0.0-preview.1 --urls http://*:52323

Endpoint / Punto de entrada

Ahora que tenemos todo listo y funcionando, donet-monitor expone en su api las siguientes url para que consultemos:

  • /processes
  • /dump/{pid?}
  • /gcdump/{pid?}
  • /trace/{pid?}
  • /logs/{pid?}
  • /metrics

Veamos a continuación cada una para que la podemos utilizarlas:

/Processes

Este endpoint devuelve una lista de procesos de destino que son accesibles de dotnet-monitor, podemos consultarla de la siguiente manera:

Powershell

PS> Invoke-RestMethod http://localhost:52323/processes

Bash

$ curl -s http://localhost:52323/processes | jq
[
  {
    "pid": 1
  }
]

Si tenemos un solo proceso accesible, y sabemos esto, no es necesario especificar el ID del proceso, automáticamente devolverá el único que posee.

/Dump

Devuelve el volcado de la información del proceso destino. Para ejecutarlo debemos utilizar el siguiente comando.

Powershell

PS> Start-Process http://localhost:52323/dump

Bash

$ wget --content-disposition http://localhost:52323/dump

No olvidar que el volcado debe ser utilizado o analizado en el mismo entorno en cual fue realizado. Por ejemplo, si nuestro volcado fue generado desde un linux no será posible leerlo con Windows o macOS, pero si, si fue generado en un docker, podemos utilizar la herramienta dotnet-dump.

/GCDump

Devuelve el volcado de GC del proceso destino, para recolectar usaremos los siguientes comandos:

Powershell

PS> Start-Process http://localhost:52323/dump

Bash

$ wget --content-disposition http://localhost:52323/dump

Una gran diferencia de los anteriores este formato es bastante portátil y podemos analizarlos con Visual Studio sin importar de qué plataforma ha sido recolectada. Creo que este es el mejor camino, sobre todo, cuando tenemos diferentes sistemas operativos.

/Trace

Devuelve el trace del proceso que se está analizando. Por default en el perfil de ejecución, se incluyen trazas de CPU, eventos de solicitudes HTTP y métricas de la duración con un límite de 30 segundos. Este último parámetro es posible configurar un nuevo tiempo. También es posible configurar el perfil por medio de parámetros querystring para que sólo devuelva los que indiquemos, por ejemplo:

 /trace?profile=cpu,logs 

Para consultar usaremos los siguientes comandos:

Powershell

PS> Start-Process http://localhost:52323/trace
PS> Start-Process http://localhost:52323/trace

Bash

$ wget --content-disposition http://localhost:52323/trace

Por último, el archivo resultante .nettrace, es posible analizarlo con Visual Studio sin ningún problema.

/Logs

Este transmitirá los registros de los procesos de destino durante 30 segundos. Nuevamente, este tiempo es configurable, podemos cambiar el tiempo de duración de la transmisión. Este devuelve un objeto del tipo JSON, o bien, un formato de eventos de text como text/eventstream basadas en la especificación Accept header en la solicitud HTTP.

Para comenzar el stream podemos hacerlo de la siguiente forma:

Powershell

PS> Start-Process http://localhost:52323/logs

Bash

$ curl -H "Accept:application/x-ndjson" http://localhost:52323/logs --no-buffer

/Metrics

Este devolverá una foto de tiempos de ejecución y las métricas de ASP.Net en el formato prometheus. A diferencia de los otros, este, no está disponible si dotnet-trace tiene más de un objetivo o proceso.

Como en el caso de otros endpoints de diagnóstico, también es posible ver una foto de las métricas actuales ejecutando el siguiente comando:

Powershell

PS> Invoke-RestMethod http://localhost:52323/metrics

Bash

$ curl -S http://localhost:52323/metrics

Conclusión

Este es un simple acercamiento a esta herramienta. Recordemos que todavía se encuentra en una fase experimental, esto quiere decir que tal vez no esté disponible en .Net 5 final, aunque pienso que sí estará. De ser así, será una herramienta que nos ayudará a que nuestras aplicaciones sean más fáciles de diagnosticar cuando tienen un problema. Pueden seguir todas las novedades desde el GitHub https://github.com/dotnet/diagnostics. Nos vemos en próximos posts.

Referencias

Fernando Sonego

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *