Las aplicaciones que se han implementado en la producción deben ser monitoreadas. Una de las mejores formas de monitorear el comportamiento de las aplicaciones es emitiendo, guardando e indexando datos de registro. Los registros se pueden enviar a una variedad de aplicaciones para indexación, donde se pueden buscar cuando surgen problemas.
Saber qué herramientas usar y cómo escribir el código de registro hace que el registro sea mucho más efectivo para monitorear aplicaciones y diagnosticar fallas.
La metodología de Twelve Factor-App ha ganado popularidad como un conjunto de pautas para la creación de software-como-servicio moderno. Uno de los doce factores es el registro.
De acuerdo con la metodología de la aplicación de doce factores, los datos de registro deben tratarse como un flujo de eventos. Los flujos de datos se envían como una especie de "transmisión" a los oyentes, sin tener en cuenta lo que sucederá con los datos recibidos. De acuerdo con el método de registro de doce factores:
"Una aplicación de doce factores nunca se preocupa por el enrutamiento o almacenamiento de su flujo de salida".
El propósito de esta recomendación es separar las inquietudes de la función de la aplicación y registrar la recopilación de datos y la indexación . El método de los doce factores va tan lejos como para recomendar que todos los datos de registro se envíen a
stdout(también conocida como 'consola'). Esta es una de las varias formas de mantener la aplicación distinta de su registro. Independientemente del método utilizado, separar estas preocupaciones simplifica el código de la aplicación. Los desarrolladores pueden centrarse en los datos que desean registrar, sin tener que preocuparse por dónde van los datos de registro o cómo se administran.Los marcos de registro populares para el marco .NET ayudan a los desarrolladores a mantener esta separación de preocupaciones. También proporcionan opciones de configuración para modificar los niveles de registro y los destinos de salida, de modo que el registro se pueda modificar en cualquier entorno, desde el desarrollo hasta la producción, sin tener que actualizar el código.
Marcos de registro
Los marcos de registro típicamente soportan características que incluyen:
- Niveles de registro
- Objetivos de registro
- Registro estructurado (también llamado "semántico")
NLog
NLog es uno de los marcos de registro más populares y de mejor rendimiento para .NET. La configuración de NLog es bastante simple. Los desarrolladores pueden usar Nuget para descargar la dependencia y luego editar el
NLog.configarchivo para configurar los objetivos . Los objetivos son como receptores de datos de registro. NLog puede apuntar a la consola, que es el método de doce factores. Otros objetivos incluyen Archivo y Correo. Los envoltorios modifican y mejoran los comportamientos de destino. AsyncWrapper, por ejemplo, mejora el rendimiento al enviar registros de forma asíncrona. La configuración de destino se puede modificar actualizando el NLog.configarchivo, y no requiere un cambio de código o recompilación.NLog soporta los siguientes niveles de registro :
- DEBUG: Información adicional sobre el comportamiento de la aplicación para casos en que esa información es necesaria para diagnosticar problemas
- INFO: Eventos de aplicación para fines generales.
- WARN: eventos de aplicación que pueden ser una indicación de un problema
- ERROR: Normalmente se registra en el
catchbloque un bloque try / catch, incluye la excepción y los datos contextuales - FATAL: Un error crítico que resulta en la terminación de una aplicación.
- RASTREO: se utiliza para marcar la entrada y salida de funciones, para fines de perfilado de rendimiento
Los niveles de registro se utilizan para filtrar los datos de registro. Un entorno de producción típico puede configurarse para registrar solo los niveles ERROR y FATAL. Si surgen problemas, se puede aumentar el nivel de registro para incluir eventos DEBUG y WARN. El contexto adicional proporcionado por estos registros puede ayudar a diagnosticar fallas.
Aquí hay un ejemplo de código que se registra usando NLog:
namespace MyNamespace
{
public class MyClass
{
//NLog recommends using a static variable for the logger object
private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();
//NLog supports several logging levels, including INFO
logger.Info("Hello {0}", "Earth");
try
{
//Do something
}
catch (Exception ex)
{
//Exceptions are typically logged at the ERROR level
logger.Error(ex, "Something bad happened");
}
}
}Log4NET
Log4NET es un puerto del popular y poderoso marco de registro Log4J para Java. La configuración y configuración de Log4NET es similar a NLog, donde un archivo de configuración contiene configuraciones que determinan cómo y dónde Log4NET envía los datos de registro. La configuración se puede configurar para volver a cargar automáticamente las configuraciones si se cambia el archivo.
Log4NET utiliza agregadores para enviar datos de registro a una variedad de destinos. Se pueden configurar varios agregadores para enviar datos de registro a múltiples destinos de datos. Los apéndices se pueden combinar con la configuración para establecer el nivel de detalle , o la cantidad de salida de datos, por nivel de registro. Log4NET admite el mismo conjunto de niveles de registro que NLog, excepto que no tiene un nivel TRACE incorporado.
La sintaxis de registro en Log4NET también es similar a NLog:
private static readonly ILog log = LogManager.GetLogger(typeof(MyApp));
log.Info("Starting application.");
log.Debug("DoTheThing method returned X");ELMAH (Módulos y controladores de registro de errores)
ELMAH está diseñado específicamente para aplicaciones ASP.NET. Es bastante fácil de configurar e incluye una aplicación de panel que se puede usar para ver errores. ELMAH es popular y ha estado disponible durante mucho tiempo, sin embargo, realmente no sigue el método de los doce factores. ELMAH guarda los datos en bases de datos, incluyendo MySQL, SQL Server, Postgres y otros. Este método combina las preocupaciones de registro con las preocupaciones sobre la persistencia de registro. Los datos de registro se almacenan en una base de datos relacional, que no es el método de almacenamiento óptimo para los registros (hablaré de una manera mejor en un momento).
Qué y cómo iniciar sesión.
Separar las preocupaciones de la administración de registros del registro simplifica el código de la aplicación. Sin embargo, los desarrolladores todavía deben escribir el código de registro. El registro efectivo puede hacer que una aplicación sea altamente compatible. La falta de registro puede hacer que sea una pesadilla para los equipos de operaciones. Es importante para los desarrolladores saber qué datos registrar y usar patrones para el registro que se pueden aplicar en una aplicación.
Niveles de registro
En términos generales, cuanto más se registre, mejor estará cuando surjan problemas. Registrar todo es bueno para solucionar problemas, pero puede llevar a problemas de uso del disco. Los registros grandes pueden ser difíciles de buscar. Los niveles de registro se utilizan para filtrar la salida del registro, adaptando la cantidad de salida de datos a la situación en cuestión.
Cada nivel de registro está asociado con el tipo de datos registrados. Los eventos DEBUG, INFO y TRACE suelen ser condiciones sin error que informan sobre el comportamiento de una aplicación.
Dependiendo de cómo se utilicen, generalmente se habilitan entornos de no producción y se deshabilitan en producción. Los entornos de producción normalmente tienen niveles de ERROR y WARN habilitados para informar problemas. Esto limita el registro de producción a solo datos críticos y sensibles al tiempo que afectan la disponibilidad de la aplicación.
Los desarrolladores tienen cierta libertad precisamente en cómo usar cada nivel de registro proporcionado por un marco dado. Los equipos de desarrollo deben establecer un patrón consistente para lo que se registra y en qué nivel. Esto puede variar de una aplicación a otra, pero debe ser coherente dentro de una sola aplicación.
Buenas prácticas de registro
Los registros de depuración generalmente informan eventos de la aplicación que son útiles al diagnosticar un problema. Las investigaciones sobre fallas en las aplicaciones necesitan las palabras “W”: Quién, Qué, Cuándo, Dónde y Por qué:
- ¿Quién estaba usando el sistema cuando falló?
- ¿En qué parte del código falló la aplicación?
- ¿Qué estaba haciendo el sistema cuando falló?
- ¿Cuándo ocurrió la falla?
- ¿Por qué falló la aplicación?
"¿Por qué falló la aplicación?" Es el resultado de una investigación de fallas y el propósito del registro. Los destinos de registro generalmente manejan el "cuándo" con marcas de tiempo agregadas a las entradas del registro. El resto de las "W" provienen de las declaraciones de registro agregadas al código.
Hay dos prácticas que ayudarán a que el registro sea más efectivo: el contexto de registro y el registro estructurado .
Contexto de registro significa agregar la "W" para registrar las entradas. Sin contexto, puede ser difícil relacionar las fallas de las aplicaciones con los registros.
Esta es una declaración de registro común:
try {
//Do something
}
catch(ex as Exception) {
logger.Error(ex);
throw ex;
}El objeto de excepción en este ejemplo se envía como una entrada de registro a los destinos de registro. Esto es necesario, pero hay cero contexto. ¿Qué método se estaba ejecutando (dónde falló la aplicación)? ¿Qué estaba haciendo la aplicación? ¿Quién estaba usando la aplicación?
Tanto NLog como Log4NET tienen características que ayudan a agregar esta información contextual a los registros, lo que los hace mucho más útiles. Los datos contextuales se agregan como metadatos a las entradas del registro.
El registro estructurado significa formatear los datos que se registran de una manera consistente. NLog y Log4NET ambos soportan diseños . Estas son clases y otras utilidades que formatean registros y serializan objetos en un formato común. Los registros estructurados se pueden indexar de manera mucho más efectiva, lo que facilita su búsqueda.
Donde enviar datos de registro
Anteriormente, mencioné que las bases de datos relacionales no son el mejor lugar para enviar datos de registro. Las bases de datos de series cronológicas (TSDB) son mucho más eficientes para almacenar datos de registro. Las TSDB requieren menos espacio en el disco para almacenar eventos que llegan en forma ordenada por el tiempo, como lo hacen los eventos de registro. Las TSDB de código abierto, como InfluxDB, son mucho más adecuadas para almacenar datos de registro que las bases de datos relacionales.
La pila ELK es una solución popular para la agregación de registros. ELK es un acrónimo que significa Elasticsearch, Logstash y Kibana.
Elasticsearch es un motor de búsqueda rápida que se utiliza para encontrar datos en grandes conjuntos de datos.
Logstash es una plataforma de canalización de datos que recopilará datos de registro de muchos orígenes y los enviará a un único objetivo de persistencia.
Kibana es un visualizador de datos basado en web y un motor de búsqueda que se integra con Elasticsearch.
Estas y otras soluciones de código abierto y pagas permiten a los desarrolladores reunir todo el registro en un sistema central. Una vez almacenado, es importante poder buscar en los registros la información necesaria para resolver las interrupciones y monitorear el comportamiento de la aplicación. El registro puede producir una gran cantidad de datos, por lo que la velocidad es importante en una función de búsqueda.
Informe de bloqueos frente a registro de errores
Las herramientas de registro e informes de errores son diferentes y deben utilizarse como parte de un flujo de trabajo de depuración.
Las herramientas de registro dedicadas le brindan un historial de eventos que han ocurrido en su aplicación. Cuando un usuario informa un problema específico, esto puede ser bastante inútil, ya que tiene que buscar manualmente a través de los archivos de registro.
Las herramientas dedicadas de informe de errores y fallas, como Raygun , se enfocan en los problemas que enfrentan los usuarios que ocurren cuando su aplicación está en producción. Registran los detalles de diagnóstico que rodean el problema que le ocurrió al usuario, para que pueda solucionarlo rápidamente con una interrupción mínima.
Reflexiones finales sobre el registro de mejores prácticas
El registro efectivo hace una gran diferencia en la compatibilidad de una aplicación. Es importante no mezclar las preocupaciones de registro y almacenamiento de registro. Los marcos de registro populares para .NET proporcionan esta separación de preocupaciones. También proporcionan características que facilitan el registro constante y el filtrado de datos de registro.
Las soluciones de código abierto y de pago para la agregación de registros son herramientas importantes, especialmente si tiene muchas aplicaciones que registran un gran volumen de datos. Con las herramientas y habilidades adecuadas, sus desarrolladores pueden producir aplicaciones que ellos y sus equipos de operaciones pueden admitir con relativa facilidad.
El registro puede llevar mucho tiempo y ser impreciso cuando necesita resolver un problema rápidamente
0 Comentarios