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:
- Como una herramienta global
- 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
- –url (por default http://localhost:52323) que expone las colecciones de nuestros endpoints.
- –metricUrls (por default http://localhost:52325) expone el punto final
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.
