logging - que - ¿Cuál es la mejor práctica para el registro centralizado?
log management open source (9)
Mi equipo ha heredado el soporte para más de 100 aplicaciones. Las aplicaciones no tienen ningún tipo de arquitectura común, por lo que las que realizan el registro normalmente lo hacen con un código personalizado para archivos locales o una base de datos local, y todo está sin administrar. Queremos cambiar eso.
Estamos migrando lentamente las aplicaciones para usar log4net y estandarizar los tipos de cosas que se registran. La siguiente pregunta es: ¿dónde debemos enviar los registros?
Pensaba que sería bueno usar un servidor central de SQL dedicado a recibir todos los registros, lo que proporcionaría un fácil mantenimiento (un lugar para copias de seguridad / archivo) y ofrecería la posibilidad futura de algunos análisis de tendencias y extracción de datos.
¿Es esa la mejor práctica para este tipo de cosas, o hay algún servidor de registro de aplicaciones dedicado que deberíamos estar considerando?
Actualización: Debería haber sido más claro que solo mencionar casualmente log4net y SQL Server: somos una casa de Microsoft, con la mayoría de las cosas escritas en .NET. Las soluciones UNIX no son buenas para nosotros.
Como han señalado las otras respuestas, lo más parecido a un estándar de la industria es syslog . Pero no desesperes porque estás viviendo en un mundo de Windows. Kiwi tiene un daemaon syslog que se ejecuta en Windows, y es gratis. Entérate más .
actualizar
Como @MichaelFreidgeim señala, Kiwi ahora cobra por su daemon de syslog. Sin embargo, hay otras alternativas gratuitas disponibles. Esta otra respuesta SO se enlaza con un par de ellos.
Como ya han dicho otros, no es una buena idea dirigir los registros de la magnitud de las aplicaciones y los hosts directamente a la base de datos. Solo quería agregar una ventaja más a favor del uso del servidor de registro centralizado dedicado: el desacoplamiento de sus aplicaciones de la infraestructura de registro. Ya que estás en .Net, hay un par de buenas opciones: log4net y NLog . Ambos son productos muy buenos, pero particularmente me gusta el NLog, demostró tener un mejor desempeño con cargas más pesadas, tiene mejores opciones de configuración y un mantenimiento activo. Log4Net, que yo sepa, no se ha modificado durante algunos años y tiene algunos problemas, pero también es una solución muy sólida. Entonces, una vez que usa dicho marco, usted controla a nivel de la aplicación cómo, qué y cuándo transmite sus registros al servidor centralizado. Como mucho.
Eche un vistazo a los logFaces que se crearon específicamente para las situaciones que describe, para agregar registros de la magnitud de las aplicaciones y los hosts que proporcionan almacenamiento centralizado y fuentes de análisis y monitoreo. Y haciendo todo esto de manera no intrusiva con cero cambios en su base de código existente. Manejará la carga masiva de aplicaciones y hosts y le permitirá especificar qué desea hacer con los datos. Por otro lado, tienes una GUI muy buena para monitorear en tiempo real o profundizar en los datos. No tienes que tratar con bases de datos directamente. Hay muchas bases de datos para elegir, tanto SQL como NoSQL. BTW, RDBS no son los que tienen mejores resultados con almacenes de datos muy grandes. logFaces puede funcionar con MongoDB : esta configuración normalmente supera las mejores marcas tradicionales de RDBS diez veces. Particularmente cuando se utiliza con colecciones limitadas.
(Para la divulgación, soy el autor de logFaces)
El límite de longitud de mensajes de Syslog de 1024 bytes mencionado hasta ahora es engañoso y sesga incorrectamente contra las soluciones basadas en Syslog para el problema.
El límite para el obsoleto "BSD Syslog Protocol" es de hecho 1024 bytes.
El protocolo BSD syslog - 4.1 partes del mensaje syslog
El límite para el "Protocolo de Syslog" moderno depende de la implementación, pero DEBE ser de al menos 480 bytes, DEBE ser de al menos 2048 bytes, y PUEDE ser incluso mayor.
El protocolo BSD syslog - 6.1. Longitud del mensaje
Como ejemplo, la configuración de configuración de Rsyslog se llama MaxMessageSize , que la documentación sugiere que se puede establecer al menos tan alto como 64kb.
rsyslog - Directivas de configuración
Que la organización del solicitante sea "una casa de Microsoft" donde "las soluciones UNIX no son buenas" no debería impedir que los lectores menos discriminatorios obtengan información precisa.
En Unix, hay syslog .
Además, es posible que desee ver este estudio de caso .
Logstash + Elasticsearch + Kibana + Redis o RabbitMQ + NLog o Log4net
Almacenamiento + Búsqueda y Análisis: Elasticsearch
Recopilación y análisis: Logstash
Visualizar: Kibana
Queue & Buffer: Redis
En aplicación: NLog
SQL funcionaría, pero he usado Splunk para agregar registros. Pude encontrar información sorprendente basada en la forma en que Splunk le permite configurar índices en sus datos y luego usar sus herramientas de consulta para hacer algunos gráficos agradables. Puedes descargar una versión básica de forma gratuita también.
Si está ejecutando en máquinas * nix, la solución tradicional es syslog .
Si tiene el registro log4net en el EventViewer local, puede extraer estos registros en un cuadro de Windows 2008, consulte este artículo de auditoría centralizada .
En ese cuadro, puede importar fácilmente estos eventos y proporcionar algunas herramientas de administración y minería además de eso.
Un mundo de precaución: con más de 100 aplicaciones en una gran tienda, con cientos o quizás miles de hosts ejecutando esas aplicaciones, evite cualquier cosa que induzca un acoplamiento apretado. Esto prácticamente descarta conectarse directamente a SQL Server o cualquier solución de base de datos, ya que el registro de su aplicación dependerá de la disponibilidad del repositorio de registros.
La disponibilidad del repositorio central es un poco más complicada que solo ''si no puede conectarse, no lo registre'' porque generalmente los eventos más interesantes ocurren cuando hay problemas, no cuando las cosas van bien. Si su registro elimina las entradas exactamente cuando las cosas se vuelven interesantes, nunca se confiará en resolver los incidentes y, como tal, no logrará ganar tracción y apoyo para otros interesados (es decir, los propietarios de la aplicación).
Si decide que puede implementar la retención y reintentar la entrega de información de registro fallida por su cuenta, se enfrenta a una ardua batalla: no es una tarea trivial y es mucho más compleja de lo que parece, a partir de un almacenamiento eficiente y confiable de la información retenida. y terminando con poner en marcha un buen reintento y una lógica de respaldo inteligente.
También debe tener una respuesta a los problemas de autenticación y seguridad. Las grandes organizaciones tienen múltiples dominios con varias relaciones de confianza, los empleados se aventuran a través de VPN o acceso directo desde el hogar, algunas aplicaciones se ejecutan de forma desatendida, algunos servicios están configurados para ejecutarse como usuarios locales, algunas máquinas no están unidas al dominio, etc. una respuesta a la pregunta de cómo se implementa el módulo de registro de cada aplicación, en todas partes, para autenticarse con el repositorio central (y qué situaciones no se admitirán).
Lo ideal sería utilizar un mecanismo de entrega listo para usar para su módulo de registro. MSMQ es probablemente el ajuste más apropiado: entrega confiable asíncrona robusta (al menos en la medida de la mayoría de los casos de uso), disponible en cada host de Windows cuando se instala (opcional). Este es el principal punto negativo, sus aplicaciones dependerán de un componente del sistema operativo no predeterminado.
El almacenamiento central del repositorio debe poder entregar la información solicitada, tal vez:
- Los desarrolladores de aplicaciones investigan incidentes.
- equipo de atención al cliente que investiga una transacción perdida reportada por una queja del cliente
- la organización de seguridad haciendo análisis forense
- Los gerentes de empresas demandan estadísticas, tendencias e información agregada (BI).
El único almacenamiento capaz de entregar esto para una organización seria (tamaño, vida útil) es un motor relacional, por lo que probablemente SQL Server. Hacer análisis sobre archivos de texto realmente no va a ir a la distancia.
Por lo tanto, recomendaría un envío / envío de registro basado en mensajería (MSMQ) y un repositorio central relacional (SQL Server) tal vez con un componente aalcalal encima (Analysis Services Data Mining). Como puede ver, esto claramente no es una hazaña pequeña y cubre un poco más que solo configurar log4net.
En cuanto a lo que se debe registrar, usted dice que ya ha pensado, pero me gustaría agregar mi 2c extra: muchas veces, especialmente en la investigación de incidentes, le gustaría poder solicitar información adicional. Esto significa que le gustaría conocer el contenido de ciertos archivos de la máquina incidente, o algunas claves de registro, o algunos valores de contador de rendimiento, o un volcado de proceso completo. Es muy útil poder solicitar esta información desde la interfaz del repositorio central, pero no es práctico recopilar siempre esta información, en caso de que sea necesario. Lo que implica que tiene que haber algún tipo de comunicación bidireccional entre la aplicación y el repositorio central, cuando la aplicación informa de un incidente, se le puede pedir que agregue información adicional (por ejemplo, un volcado del proceso en el que falla). Tiene que haber una gran cantidad de infraestructura para que algo como esto ocurra, desde el protocolo entre el registro de aplicaciones y el repositorio central, hasta la capacidad del repositorio central para reconocer una repetición del incidente, hasta la capacidad de la biblioteca loggin para recopilar la información adicional requerida y, no menos importante, la capacidad de un operador para marcar incidentes que necesitan información adicional en la próxima aparición.
Entiendo que esta respuesta probablemente parece una exageración en este momento, pero estuve involucrado con este espacio problemático durante bastante tiempo, había visto muchos informes de fallos en línea del Dr. Watson en el día en que estaba con EM, y puedo le dice que estos requisitos existen, son preocupaciones válidas y cuando se implementa la solución ayuda enormemente. En última instancia, no puedes arreglar lo que no puedes medir. Una organización grande depende de una buena gestión y supervisión de su stock de aplicaciones, incluido el registro y la auditoría.
Hay algunos proveedores externos que ofrecen soluciones, algunas incluso integradas con log4net, como bugcollect.com (revelación completa: es mi propia compañía), Error Traffic Controller o Exceptioneer y otras.