Algunas reflexiones sobre la plataforma de registro
Los registros son en realidad un concepto relativamente amplio. Los registros del servidor de impresión de aplicaciones, los syslogs del sistema de archivos de Linux, /var/messages, etc. pertenecen a registros que son esencialmente una serie de datos de tiempo, similar a los campos de monitoreo. Indicadores métricos, pero los indicadores de medición generalmente están muy estructurados y la longitud de los datos de cada campo es relativamente pequeña. Por lo general, son series de tiempo y la longitud de los datos de cada campo es relativamente pequeña. La longitud de los datos de cada campo es relativamente pequeña, generalmente tiempo + etiqueta + valor, y los registros también están relacionados con el tiempo, pero un solo registro puede ser más largo (a veces más de una línea) y la mayoría de ellos son datos de texto no estructurados, que están relacionados con** ** Los datos generados tienen las mismas características y no serán actualizados.
En pocas palabras, la plataforma de registros debe tener funciones de almacenamiento y computación.
Funcionalmente, la plataforma de registros debe tener los siguientes puntos de funciones básicas
1. Recopilación de registros
2. Almacenamiento de datos de registro
3. Recuperación y análisis rápidos de datos de registro
Para recuperar registros, es necesario almacenarlos de forma centralizada. La recopilación de registros anteriores se dividió en dos tipos. Hay dos tipos de recopilación de registros en el pasado, uno es el método del agente y el otro es el método sin agente. El primero consiste en implementar un agente en el servidor que recopila registros y el agente enviará los registros al registro continuamente. servidor sin ningún problema. El método proxy es similar a iniciar sesión en el servidor de forma remota a través de ssh para capturar registros.
El método sin agente no requiere la implementación de un agente. Generalmente, los registros se recuperan de manera programada. Este método tiene poca puntualidad y no puede monitorear el sistema de archivos en tiempo real para obtener los datos de registro más recientes. Básicamente, pocas personas en la industria lo usan, y TLog de Alibaba parece haber usado este método en el pasado.
Hoy en día, la mayoría de ellos utilizan el método del agente de implementación para obtener registros. Los más famosos incluyen flume, logstash, filebeat, etc. Cuando se utilizan flume y logstash, es inconveniente controlar la ocupación de la CPU. y recursos de memoria, en un entorno de arquitectura de servicios, la recopilación de registros tiene requisitos de rendimiento cada vez mayores para los agentes. En un entorno de arquitectura de microservicio, la recopilación de registros tiene requisitos de rendimiento cada vez mayores para los agentes, mientras que el consumo de recursos debe ser tan bajo. lo más posible. Filebeat es relativamente liviano y muy poderoso, y cada vez más personas lo usan.
El método proxy esencialmente llama a la interfaz API del servidor para enviar datos al servidor de registro. Por lo tanto, otra forma de usar la aplicación es llamar directamente a la API del servidor de registro, como convertir esta función en un complemento de log4j. en. O escriba otros componentes de registro de uso común, de modo que el costo de la recopilación de registros se minimice, pero cuando el servicio de registro no esté disponible, el servicio de registro tampoco estará disponible. Cuando el servicio de registro no está disponible, la recuperación de datos de registro se vuelve algo problemática.
Por lo general, en las grandes empresas, también es un problema utilizar agentes para recopilar registros y administrar agentes. Por ejemplo, Alibaba actualmente afirma que su agente SLS ha implementado más de 2 millones de nodos. , es 200 Es imposible para nosotros iniciar sesión uno por uno para cambiar el archivo de configuración del agente. Por lo tanto, la automatización de las tareas de recopilación, envío, entrada en vigor y cambio también es muy importante. gestionar el estado del agente, actualizar el agente, etc.
Anteriormente, TT de Alibaba también tenía una colección de proxy y la escala de implementación también era grande. En términos de implementación, en algunos escenarios, el proxy solicitará la API del cliente del servidor. 11 degradación y recuperación. Esto ejerce mucha presión sobre la API del cliente. Por lo tanto, este problema debe considerarse al diseñar escenarios para la implementación de agentes a gran escala. Por lo tanto, estas cuestiones deben considerarse al diseñar aplicaciones para escenarios de implementación de agentes a gran escala.
El propósito de escribir es leer. Para leer mejor, necesitamos diseñar una solución de almacenamiento más razonable. Para satisfacer tanto la recuperación como las estadísticas y el análisis, ¿parece que solo el índice invertido es la solución? Cuando la comunidad de código abierto menciona el almacenamiento de registros, generalmente eligen elasticsearch. Algunas empresas de nueva creación también crearán soluciones de almacenamiento basadas en es o aprenderán de él. De hecho, esto está disponible de inmediato. Y los registros fluirán y el efecto de búsqueda será excelente. Parece bueno, kibana también puede realizar análisis, pero cuando realmente implementemos la aplicación, encontraremos que usar es para almacenar registros es una solución muy costosa.
En una empresa un poco más grande, es fácil escribir datos de registro a 10 w/s por segundo, indexarlos en tiempo real y luego descargarlos en la memoria caché del sistema de archivos para que sean visibles. método de implementación., en sí mismo no es adecuado para escritura de tps tan altos, y su lectura y escritura no están separadas. En términos generales, el diseño de Lucene necesita una optimización especial en escenarios de registro, como LRU para el procesamiento y cierre de datos residentes en la memoria. índices utilizados con poca frecuencia, evitando IO repetidas durante la fusión, optimización de la memoria de mapeo de relaciones de segmentos, etc. Cuanto más aprendo sobre esto, más encuentro que esta solución es demasiado lujosa. La mayoría de las personas que usan es para el almacenamiento de registros en la industria son magnates. A menudo apilan cientos de miles de servidores + operación y mantenimiento refinados. ¡rentable, de verdad! No importa cuán grande sea el tamaño del tronco, sigue siendo un desperdicio. Las empresas con recursos financieros promedio no deberían considerar esta solución.
El almacenamiento de registros en realidad requiere rendimiento en tiempo real y la solución de almacenamiento debe diseñarse de manera flexible de acuerdo con las características de los registros.
La recuperación de registros también es un escenario de consulta interactiva típico. Por supuesto, cuanto más rápido, mejor es ideal devolver resultados en 1 a 3 segundos. Los usuarios tardan más de diez segundos en aceptar No, lo más lento para consultas a gran escala no es más de 30 segundos, etc. En términos de recuperación, además de la entrada de palabras clave, también esperamos admitir potentes análisis de funciones, filtrado. y estadísticas. En realidad, esta característica deja un espacio de diseño muy grande para el almacenamiento y también es un gran desafío.
El almacenamiento primero debe distribuirse y expandirse fácilmente horizontalmente, mientras se realiza una pequeña cantidad de índices necesarios según las características del registro. Por ejemplo, los registros generalmente se buscan y analizan según el rango de tiempo, por lo que el tiempo es obviamente el índice más importante. Al mismo tiempo, de qué máquina proviene el registro, a qué aplicación pertenece y qué sala de computadoras debe tener algunas etiquetas. Entonces, ¿son suficientes algunos índices basados en etiquetas, pero se pueden utilizar directamente algunos sistemas de almacenamiento existentes?
Como se mencionó anteriormente, los registros son un tipo de datos temporales, por lo que opentsdb no puede almacenar registros. opentsdb se basa en hdfs y hbase. Desde una perspectiva de implementación, es demasiado complejo. Al mismo tiempo, almacena una hora de datos en una fila y cada fila es una métrica. En este caso, ¿cómo se almacenan los registros? Obviamente no es razonable.
Kafka también agrega información de marca de tiempo a cada mensaje y admite el direccionamiento según marcas de tiempo. El diseño arquitectónico de Kafka en realidad me dio mucha inspiración para diseñar el almacenamiento de registros, pero el tiempo de indexación no es suficiente. Quizás quieras poder armar un escándalo por el nombre del tema. Creo que es imposible porque todavía tenemos muchas cosas por indexar. No lo creo, porque tenemos que indexar muchas cosas y el rendimiento de Kafka se degrada significativamente cuando la cantidad de temas es muy alta.
Las estadísticas y el análisis de registros SLS de Alibaba se completan a través de SQL estándar, pero prefiero el estilo y método de línea de comando similar a un shell. El cambio en el pensamiento de SQL requiere una cierta cantidad de tiempo y los usuarios no deben hacerlo. como SQL, pero pase lo que pase, si desea analizar y contar registros, debe crear un motor de análisis DSL sobre el sistema de almacenamiento de registros. Debe poder agregar operadores de uso común y crear un conjunto de operadores de uso común. Ejecute estas operaciones de manera distribuida y devuelva resultados rápidamente. Alguien alguna vez pensó en usar MLSQL para cargar datos de registro y luego usar SQL para analizar y recuperar los resultados. En realidad, esta es una muy buena idea, aunque no es necesario usarla. MLSQL siempre envía trabajos de chispa cada vez, pero el procesamiento de datos aún sacrificará algo de puntualidad y separará los beneficios del cálculo y el almacenamiento. Al mismo tiempo, también espero que la plataforma de registro pueda monitorear algunos eventos de registro que me interesan. en tiempo real y luego mostrarlos en paneles personalizables con soporte para alertas y más.
En los últimos 1 o 2 años, he estado investigando y explorando plataformas de administración de registros más rentables. Compartiré algunas experiencias y soluciones con ustedes en el futuro.