Comparteix a través de


Registro y seguimiento de .NET

El código se puede instrumentar para generar un registro, que sirve para tener constancia de eventos interesantes que se han producido mientras se ejecutaba el programa. Para comprender el comportamiento de la aplicación, se pueden revisar los registros. .NET ha acumulado varias API de registro diferentes a lo largo de su historia, y este artículo le ayudará a comprender qué opciones están disponibles.

Nota:

A veces, el registro también se conoce como "seguimiento", así como en algunas de las API anteriores de Windows y .NET. En los últimos años, "seguimiento" se usaba con más frecuencia como abreviatura del seguimiento distribuido, pero eso no es el significado que se da en este artículo.

API de registro de .NET

ILogger

En la mayoría de los casos, tanto si se agrega el registro a un proyecto existente como si se crea un proyecto, la infraestructura ILogger es una buena opción predeterminada. ILogger admite un registro estructurado, rápido, una configuración flexible y un conjunto de receptores comunes, incluida la consola, que es lo que se ve al ejecutar una aplicación de ASP.NET. Además, la interfaz ILogger puede servir como fachada en muchas implementaciones de registro de terceros que ofrecen funcionalidad y extensibilidad enriquecidas.

ILogger proporciona el artículo de registro de la implementación de OpenTelemetry para .NET, que permite la salida de registros de la aplicación a una variedad de sistemas APM para su análisis posterior.

EventSource

EventSource es una API antigua y de alto rendimiento con registro estructurado. Originalmente, se diseñó para integrarse correctamente en el seguimiento de eventos para Windows (ETW), pero terminó ampliándose para admitir el seguimiento multiplataforma de EventPipe y EventListener para receptores personalizados. En comparación con ILogger, EventSource cuenta con relativamente pocos receptores de registro creados previamente y no ofrece ninguna opción integrada para configurar mediante archivos de configuración independientes. EventSource es una opción excelente si busca un control más estricto de la integración de ETW o EventPipe. Para el registro de uso general, ILogger es más flexible y fácil de usar.

Seguimiento

System.Diagnostics.Trace y System.Diagnostics.Debug son las API de registro más antiguas de NET. Estas clases tienen API de configuración flexibles y un gran ecosistema de receptores, pero solo admiten registro no estructurado. En .NET Framework, se pueden configurar mediante un archivo app.config. En .NET Core, no hay ningún mecanismo de configuración integrado que se base en archivos. Normalmente se usan para generar la salida de diagnóstico para el desarrollador mientras se ejecuta en el depurador. El equipo de .NET sigue admitiendo estas API con fines de compatibilidad con versiones anteriores, pero no se agregará ninguna función nueva. Estas API son una opción adecuada para las aplicaciones que ya las usan. En el caso de las aplicaciones más recientes que todavía no usen ninguna API de registro, ILogger puede ofrecer mejores funciones.

API de registro especializadas

Consola

La clase System.Console tiene los métodos Write y WriteLine, que se pueden usar en escenarios de registro sencillos. Estas API son muy fáciles de poner en marcha, pero la solución no será tan flexible como una API de registro de uso general. La consola solo permite el registro no estructurado y no hay opciones de configuración para elegir qué mensajes de registro se habilitan ni para cambiar el destino a otro receptor. El uso de las API ILogger o Trace con un receptor de consola no conlleva un gran esfuerzo adicional y mantiene el registro configurable.

DiagnosticSource

System.Diagnostics.DiagnosticSource está pensado para un registro en el que los mensajes de registro se analicen sincrónicamente durante el proceso en lugar de serializarse en cualquier almacenamiento. Así se permite que el origen y el agente de escucha intercambien objetos de .NET arbitrarios como mensajes, mientras que la mayoría de las API de registro requieren que el evento de registro sea serializable. Esta técnica también puede resultar muy ágil; si el agente de escucha se implementa de forma eficiente, los eventos de registro se podrán controlar en decenas de nanosegundos. Las herramientas que usan estas API suelen funcionar más bien como los generadores de perfiles en proceso, aunque las API no imponen ninguna restricción de ese tipo.

EventLog

System.Diagnostics.EventLog es una API exclusiva de Windows que permite escribir mensajes en el registro de eventos de Windows. En muchos casos, el uso de ILogger con un receptor de EventLog opcional mientras se ejecuta en Windows puede incluir funciones similares sin acoplar la aplicación estrictamente al sistema operativo Windows.

Terminología sobre registros

Registro estructurado y no estructurado

El registro pueden ser estructurado o no estructurado:

  • No estructurados: las entradas de registro se codifican en forma de texto libre que los usuarios pueden leer, pero son difíciles analizar y consultar mediante programación.
  • Estructuradas: las entradas de registro tienen un esquema bien definido y se pueden codificar en diferentes formatos binarios y textuales. Estos registros están diseñados para ser traducibles y consultables automáticamente con el objetivo de que los usuarios y los sistemas automatizados puedan trabajar con ellos fácilmente.

Las buenas API de registro estructurado pueden ofrecer más funcionalidades y rendimiento al aumentar un poco su complejidad de uso.

Receptores

La mayoría de las API de registro permiten enviar mensajes de registro a diferentes destinos denominados receptores. Algunas API tienen un gran número de receptores predefinidos; otras solo tienen unos pocos. Si no existe ningún receptor creado previamente, suele haber una API de extensibilidad que permite crear un receptor personalizado, aunque esto conlleva escribir un poco más de código.