Los registros son una parte importante del sistema, lo que le permite comprender si funciona (o no funciona) como se esperaba. Bajo las condiciones de la arquitectura de microservicios, trabajar con registros se convierte en una disciplina separada de la Olimpiada Especial. Hay muchos problemas que deben abordarse:
- cómo escribir registros desde la aplicación;
- dónde escribir registros;
- cómo entregar registros para almacenamiento y procesamiento;
- cómo procesar y almacenar registros.
El uso de las tecnologías de contenedorización actualmente populares agrega arena en la parte superior del rastrillo en el campo de las opciones de resolución de problemas.
Justo sobre esto es la transcripción del informe de Yuri Bushmelev "Mapa de un rastrillo en el campo de la recolección y entrega de troncos".
A quién le importa, por favor debajo del gato.
Mi nombre es Yuri Bushmelev. Trabajo para Lazada. Hoy hablaré sobre cómo hicimos nuestros registros, cómo los recopilamos y qué escribimos allí.
¿De donde somos? ¿Quienes somos? Lazada es el minorista en línea número 1 en seis países del sudeste asiático. Todos estos países están distribuidos entre centros de datos. Ahora hay 4 centros de datos en total. ¿Por qué es importante? Porque algunas decisiones se debieron a que hay un vínculo muy débil entre los centros. Tenemos una arquitectura de microservicios. Me sorprendió descubrir que ya tenemos 80 microservicios. Cuando comencé la tarea con los registros, solo había 20. Además, hay una parte bastante grande del legado de PHP, con el que también tengo que vivir y soportar. Todo esto nos genera en este momento más de 6 millones de mensajes por minuto para el sistema en su conjunto. Además, mostraré cómo estamos tratando de vivir con esto y por qué es así.
Tienes que vivir con estos 6 millones de mensajes de alguna manera. ¿Qué debemos hacer con ellos? 6 millones de mensajes necesarios:
- enviar desde la aplicación
- aceptar para la entrega
- entregar para su análisis y almacenamiento.
- para analizar
- almacenar de alguna manera.
Cuando había tres millones de mensajes, tenía más o menos el mismo aspecto. Porque comenzamos con algunos centavos. Está claro que los registros de la aplicación se escriben allí. Por ejemplo, no pudo conectarse a la base de datos, pudo conectarse a la base de datos, pero no pudo leer algo. Pero además de esto, cada uno de nuestros microservicios también escribe un registro de acceso. Cada solicitud que llega al microservicio cae en el registro. ¿Por qué estamos haciendo esto? Los desarrolladores quieren poder rastrear. Cada registro de acceso contiene el campo traceid, según el cual una interfaz especial desenrolla toda la cadena y muestra bellamente el seguimiento. El seguimiento muestra cómo fue la solicitud, y esto ayuda a nuestros desarrolladores a lidiar con cualquier basura desconocida más rápido.
¿Cómo vivir con eso? Ahora describiré brevemente el campo de opciones: cómo se resuelve generalmente este problema. Cómo resolver el problema de recopilar, transferir y almacenar registros.
¿Cómo escribir desde la aplicación? Está claro que hay diferentes formas. En particular, hay mejores prácticas, como nos dicen los camaradas de moda. Hay dos tipos de vieja escuela, como decían los abuelos. Hay otras formas.
Con la recopilación de registros, la situación es aproximadamente la misma. No hay tantas opciones para resolver esta parte en particular. Hay más de ellos, pero no tantos todavía.
Pero con la entrega y el análisis posterior, la cantidad de variaciones comienza a explotar. No describiré cada opción ahora. Creo que las principales opciones son bien conocidas por todos los interesados en el tema.
Te mostraré cómo lo hicimos en Lazada y cómo empezó todo.
Hace un año vine a Lazada y me enviaron al proyecto de troncos. Allí estaba así. El registro de la aplicación se escribió en stdout y stderr. Todo se hizo a la moda. Pero luego los desarrolladores lo eliminaron de los flujos estándar, y luego los especialistas en infraestructura lo resolverán de alguna manera. Entre los especialistas en infraestructura y los desarrolladores, también hay liberadores que dijeron: "eh... bueno, envolvámoslos en un archivo con un caparazón, y eso es todo". Y dado que todo esto está en un contenedor, lo envolvieron directamente en el contenedor mismo, mapearon el directorio dentro y lo pusieron allí. Creo que es bastante obvio para todos lo que sucedió.
Veamos un poco más. Cómo entregamos estos registros. Alguien eligió td-agent, que en realidad es fluido pero no del todo fluido. Todavía no entiendo la relación de estos dos proyectos, pero parecen tratarse de lo mismo. Y este fluido, escrito en Ruby, lee archivos de registro, los analiza en JSON usando algunas expresiones regulares. Luego fueron enviados a Kafka. Además, en Kafka, teníamos 4 temas separados para cada API. ¿Por qué 4? Porque hay directo, hay puesta en escena, y porque hay stdout y stderr. Los desarrolladores los producen y los trabajadores de la infraestructura deben crearlos en Kafka. Además, Kafka estaba controlado por otro departamento. Por lo tanto, era necesario crear un ticket para que allí crearan 4 temas para cada api. Todos se olvidaron de eso. En general, era basura y desechos.
¿Qué hicimos después con él? Lo enviamos a kafka. Más allá de Kafka, la mitad de los troncos volaron a Logstash. La otra mitad de los registros fueron compartidos. Algunos volaron a un Graylog, algunos a otro Graylog. Como resultado, todo esto voló a un clúster de Elasticsearch. Es decir, todo este lío cayó al final ahí. ¡No tienes que hacer eso!
Así es como se ve cuando se ve desde arriba. ¡No tienes que hacer eso! Aquí, las áreas problemáticas se marcan inmediatamente con números. En realidad, hay más de ellos, pero 6 son realmente problemáticos, con los que hay que hacer algo. Hablaré de ellos por separado ahora.
Aquí (1,2,3) escribimos archivos y, en consecuencia, aquí hay tres rastrillos a la vez.
El primero (1) es que necesitamos escribirlos en alguna parte. No siempre es deseable darle a una API la capacidad de escribir directamente en un archivo. Es deseable que la API esté aislada en un contenedor, y mejor aún, que sea de solo lectura. Soy administrador de sistemas, por lo que tengo una visión ligeramente alternativa de estas cosas.
El segundo punto (2,3) es que tenemos muchas solicitudes que llegan a la API. La API escribe una gran cantidad de datos en un archivo. Los archivos están creciendo. Tenemos que rotarlos. Porque de lo contrario no podrá guardar ningún disco allí. Rotarlos es malo porque son redirigidos a través del shell a un directorio. No hay manera de que podamos rotarlo. No puede decirle a la aplicación que vuelva a abrir los identificadores. Porque los desarrolladores te mirarán como un tonto: “¿Qué descriptores? Generalmente escribimos a stdout. Los marcos hicieron copytruncate en logrotate, que solo hace una copia del archivo y tronca el original. En consecuencia, entre estos procesos de copia, generalmente se agota el espacio en disco.
(4) Teníamos diferentes formatos en diferentes API. Eran ligeramente diferentes, pero las expresiones regulares tenían que escribirse de manera diferente. Como todo estaba a cargo de Puppet, había un montón de clases con sus propias cucarachas. Además, td-agent la mayor parte del tiempo podía comerse la memoria, ser estúpido, podía fingir que estaba trabajando y no hacer nada. Exteriormente, era imposible entender que no estaba haciendo nada. En el mejor de los casos, se caerá y alguien lo recogerá más tarde. Más precisamente, una alerta volará y alguien irá y la levantará con las manos.
(6) Y la mayor cantidad de basura y desechos: fue elasticsearch. Porque era una versión antigua. Porque no teníamos maestros dedicados en ese momento. Teníamos registros heterogéneos cuyos campos podían superponerse. Se pueden escribir diferentes registros de diferentes aplicaciones con los mismos nombres de campo, pero al mismo tiempo puede haber diferentes datos dentro. Es decir, un registro viene con un número entero en un campo, por ejemplo, nivel. Otro registro viene con una cadena en el campo de nivel. En ausencia de mapeo estático, resulta algo tan maravilloso. Si, después de la rotación del índice, un mensaje con una cadena llegó primero a elasticsearch, entonces vivimos normalmente. Y si el primero llegó con Integer, todos los mensajes subsiguientes que llegaron con String simplemente se descartan. Porque el tipo de campo no coincide.
Empezamos a hacer estas preguntas. Decidimos no buscar a los culpables.
¡Pero hay que hacer algo! Lo obvio es que necesitamos establecer estándares. Ya teníamos algunos estándares. Algunos los trajimos un poco más tarde. Afortunadamente, en ese momento ya se aprobó un formato de registro único para todas las API. Está escrito directamente en los estándares de interacción de servicios. En consecuencia, aquellos que deseen recibir registros deben escribirlos en este formato. Si alguien no escribe registros en este formato, no garantizamos nada.
Además, me gustaría tener un estándar único para los métodos de registro, entrega y recopilación de registros. En realidad, dónde escribirlos y cómo entregarlos. La situación ideal es cuando los proyectos utilizan la misma biblioteca. Hay una biblioteca de registro separada para Go, hay una biblioteca separada para PHP. Todos los que tenemos, todos deberían usarlos. Por el momento, diría que lo estamos logrando en un 80 por ciento. Pero algunos continúan comiendo cactus.
Y allí (en la diapositiva) apenas comienza a aparecer el “SLA para la entrega de registros”. Todavía no está allí, pero estamos trabajando en ello. Porque es muy conveniente cuando infra dice que si escribes en tal formato a tal lugar y no más de N mensajes por segundo, lo más probable es que lo entreguemos allí. Te quita muchos dolores de cabeza. Si hay un SLA, ¡entonces es genial!
¿Cómo empezamos a resolver el problema? El rake principal fue con td-agent. No estaba claro a dónde van nuestros registros. ¿Se entregan? ¿Se van? ¿Dónde están de todos modos? Por lo tanto, se decidió reemplazar td-agent con el primer elemento. Las opciones para reemplazarlo, las describí brevemente aquí.
fluido En primer lugar, lo conocí en un trabajo anterior, y también cayó allí periódicamente. En segundo lugar, esto es lo mismo, solo de perfil.
latido de archivo ¿Cómo fue bueno para nosotros? El hecho de que él está en Go, y tenemos una gran experiencia en Go. En consecuencia, en todo caso, podríamos agregarlo de alguna manera a nosotros mismos. Por eso no lo tomamos. Para que ni siquiera haya ninguna tentación de empezar a reescribirlo por ti mismo.
La solución obvia para el administrador del sistema es todo tipo de syslogs en esta cantidad (syslog-ng/rsyslog/nxlog).
O escribe algo propio, pero lo descartamos, así como filebeat. Si escribe algo, entonces es mejor escribir algo útil para los negocios. Para entregar registros, es mejor tomar algo ya hecho.
Por lo tanto, la elección en realidad se redujo a elegir entre syslog-ng y rsyslog. Me incliné por rsyslog simplemente porque ya teníamos clases para rsyslog en Puppet y no encontré una diferencia obvia entre ellas. Qué es syslog, qué es syslog. Sí, alguna documentación es peor, otra mejor. Él sabe de esta manera, y lo hace de otra manera.
Y un poco sobre rsyslog. Primero, es genial porque tiene muchos módulos. Tiene un RainerScript legible por humanos (lenguaje de configuración moderno). Una ventaja increíble es que pudimos emular el comportamiento de td-agent con sus herramientas estándar y nada ha cambiado para las aplicaciones. Es decir, cambiamos td-agent a rsyslog y no tocamos todo lo demás todavía. E inmediatamente recibimos una entrega de trabajo. A continuación, mmnormalize es lo bueno de rsyslog. Le permite analizar registros, pero no con Grok y regexp. Hace un árbol de sintaxis abstracta. Analiza los registros de la misma manera que un compilador analiza el código fuente. Esto le permite trabajar muy rápido, consumir poca CPU y, en general, es algo muy bueno. Hay un montón de otros bonos. No me detendré en ellos.
rsyslog tiene muchas más desventajas. Son casi lo mismo que los bonos. Los principales problemas son que necesita poder cocinarlo y debe seleccionar una versión.
Decidimos que escribiríamos registros en un socket de Unix. Y no en /dev/log, porque ahí tenemos un lío de registros del sistema, hay diarios en esta canalización. Así que escribamos en un socket personalizado. Lo adjuntaremos a un conjunto de reglas separado. No interfiramos en nada. Todo será transparente y comprensible. Así que en realidad lo hicimos. El directorio con estos sockets está estandarizado y reenviado a todos los contenedores. Los contenedores pueden ver el socket que necesitan, abrirlo y escribir en él.
¿Por qué no un archivo? porque todo el mundo ha leído , que intentó reenviar el archivo a la ventana acoplable y descubrió que después de reiniciar rsyslog, el descriptor del archivo cambia y la ventana acoplable pierde este archivo. Mantiene abierto algo más, pero no el mismo zócalo donde escriben. Decidimos que evitaríamos este problema y, al mismo tiempo, evitaríamos el problema del bloqueo.
Rsyslog realiza las acciones indicadas en la diapositiva y envía registros a Relay o Kafka. Kafka sigue el camino antiguo. Rayleigh: traté de usar rsyslog puro para entregar registros. Sin Message Queue, utilizando herramientas rsyslog estándar. Básicamente, funciona.
Pero hay matices con respecto a cómo introducirlos más adelante en esta parte (Logstash/Graylog/ES). Esta parte (rsyslog-rsyslog) se usa entre centros de datos. Aquí hay un enlace tcp comprimido, que le permite ahorrar ancho de banda y, en consecuencia, aumentar de alguna manera la probabilidad de que recibamos algunos registros de otro centro de datos cuando el canal esté lleno. Porque tenemos Indonesia, donde todo es malo. Ahí es donde radica el problema constante.
Pensamos en cómo monitoreamos realmente, ¿con qué probabilidad los registros que grabamos desde la aplicación llegan a ese fin? Decidimos empezar con las métricas. Rsyslog tiene su propio módulo de recopilación de estadísticas, que tiene algún tipo de contadores. Por ejemplo, puede mostrarle el tamaño de la cola o cuántos mensajes entraron para tal o cual acción. Ya puedes tomar algo de ellos. Además, tiene contadores personalizados que puedes configurar y te mostrará, por ejemplo, la cantidad de mensajes que ha registrado alguna API. A continuación, escribí rsyslog_exporter en Python, lo enviamos todo a Prometheus y lo trazamos. Realmente queríamos las métricas de Graylog, pero hasta ahora no hemos tenido tiempo de configurarlas.
¿Cuáles son los problemas? El problema surgió con el hecho de que descubrimos (¡DE REPENTE!) que nuestras API en vivo escriben 50k mensajes por segundo. Esto es solo Live API sin preparación. Y Graylog solo nos muestra 12 mil mensajes por segundo. Y surgió una pregunta razonable, ¿dónde están los restos? De lo cual llegamos a la conclusión de que Graylog simplemente no puede hacer frente. Buscamos y, de hecho, Graylog con Elasticsearch no dominó este flujo.
A continuación, otros descubrimientos que hemos hecho en el camino.
Las escrituras en el socket están bloqueadas. ¿Cómo ha ocurrido? Cuando usé rsyslog para la entrega, en algún momento rompimos el canal entre los centros de datos. La entrega se levantó en un lugar, la entrega se levantó en otro lugar. Todo esto se ha reducido a una máquina con API que escriben en el socket rsyslog. Había una cola. Luego se llenó la cola para escribir en el socket de Unix, que por defecto es de 128 paquetes. Y el próximo write() en los bloques de aplicación. Cuando observamos la biblioteca que usamos en las aplicaciones Go, allí estaba escrito que la escritura en el socket ocurre en modo sin bloqueo. Estábamos seguros de que nada estaba bloqueado. porque hemos leído quien escribió sobre eso. Pero hay un momento. También hubo un ciclo infinito alrededor de esta llamada, en el que hubo un intento constante de insertar un mensaje en el socket. No lo notamos. Tuve que reescribir la biblioteca. Desde entonces, ha cambiado varias veces, pero ahora nos hemos deshecho de los bloqueos en todos los subsistemas. Por lo tanto, puede detener rsyslog y nada caerá.
Es necesario vigilar el tamaño de las colas, lo que ayuda a no pisar este rastrillo. Primero, podemos monitorear cuando comenzamos a perder mensajes. En segundo lugar, podemos monitorear que básicamente tenemos problemas con la entrega.
Y otro momento desagradable: la amplificación 10 veces en una arquitectura de microservicio es muy fácil. No tenemos tantas solicitudes entrantes, pero debido al gráfico en el que se ejecutan más estos mensajes, debido a los registros de acceso, en realidad aumentamos la carga en los registros unas diez veces. Desafortunadamente, no tuve tiempo de calcular los números exactos, pero los microservicios son lo que son. Esto debe tenerse en cuenta. Resulta que por el momento el subsistema de recolección de logs es el más cargado en Lazada.
¿Cómo resolver el problema de búsqueda elástica? Si necesita obtener registros rápidamente en un solo lugar, para no ejecutarlos en todas las máquinas y recopilarlos allí, use el almacenamiento de archivos. Esto está garantizado para trabajar. Se hace desde cualquier servidor. Solo necesita pegar discos allí y poner syslog. Después de eso, tiene la garantía de tener todos los registros en un solo lugar. Entonces será posible configurar lentamente elasticsearch, graylog u otra cosa. Pero ya tendrá todos los registros y, además, podrá almacenarlos, siempre que haya suficientes matrices de discos.
En el momento de mi informe, el esquema comenzó a verse así. Prácticamente dejamos de escribir en el archivo. Ahora, lo más probable, apagaremos los restos. En las máquinas locales que ejecutan la API, dejaremos de escribir en los archivos. En primer lugar, está el almacenamiento de archivos, que funciona muy bien. En segundo lugar, estas máquinas se quedan constantemente sin espacio, debe monitorearlas constantemente.
Esta parte con Logstash y Graylog, realmente se dispara. Por lo tanto, necesitas deshacerte de él. Tienes que elegir uno.
Decidimos dejar Logstash y Kibana. Porque tenemos un departamento de seguridad. ¿Cuál es la conexión? La conexión es que Kibana sin X-Pack y sin Shield no te permite diferenciar los derechos de acceso a los registros. Por lo tanto, se llevaron a Graylog. Lo tiene todo. No me gusta, pero funciona. Compramos hardware nuevo, instalamos un Graylog nuevo allí y movimos todos los registros con formatos estrictos a un Graylog separado. Hemos resuelto el problema con diferentes tipos de los mismos campos organizativamente.
Qué se incluye exactamente en el nuevo Graylog. Acabamos de escribir todo en la ventana acoplable. Tomamos un montón de servidores, implementamos tres instancias de Kafka, 7 servidores Graylog versión 2.3 (porque quería la versión 5 de Elasticsearch). Todo esto se planteó sobre incursiones desde el HDD. Vimos una tasa de indexación de hasta 100 mil mensajes por segundo. Vimos la cifra de 140 terabytes de datos por semana.
¡Y de nuevo un rastrillo! Tenemos dos ventas próximas. Hemos superado los 6 millones de publicaciones. Graylog no tiene tiempo para masticar. De alguna manera tienes que sobrevivir de nuevo.
Así es como sobrevivimos. Se agregaron algunos servidores y SSD más. En este momento vivimos así. Ahora ya estamos masticando 160k mensajes por segundo. Todavía no hemos alcanzado el límite, por lo que no está claro cuánto podemos obtener de manera realista.
Estos son nuestros planes para el futuro. De estos, realmente, el más importante es probablemente la alta disponibilidad. Aún no lo tenemos. Varios autos están configurados de la misma manera, pero hasta ahora todo pasa por un solo auto. Es necesario dedicar tiempo a configurar una conmutación por error entre ellos.
Recopile métricas de Graylog.
Establezca un límite de velocidad para que tengamos una API loca que no nos quite el ancho de banda y todo lo demás.
Y finalmente, firmar algún tipo de SLA con los desarrolladores para que podamos servir tanto. Si escribes más, lo siento.
Y escribir documentación.
Brevemente, los resultados de todo lo que hemos vivido. Primero, las normas. En segundo lugar, syslog es pan comido. En tercer lugar, rsyslog funciona exactamente como está escrito en la diapositiva. Y vamos a las preguntas.
preguntas.
pregunta: ¿Por qué decidieron no llevar... (filebeat?)
respuesta: Necesidad de escribir en un archivo. Realmente no quería. Cuando su API escribe miles de mensajes por segundo, incluso si rota una vez por hora, todavía no es una opción. Puede escribir en la tubería. A lo que los desarrolladores me preguntaron: “¿Qué pasará si se cae el proceso en el que escribimos”? Simplemente no encontré qué responderles y dije: "Bueno, está bien, no hagamos eso".
pregunta: ¿Por qué no escribes registros en HDFS?
respuestaR: Esta es la siguiente etapa. Pensamos en ello desde el principio, pero dado que no hay recursos para manejarlo en este momento, depende de nuestra solución a largo plazo.
pregunta: Un formato de columna sería más apropiado.
respuesta: Entiendo. Estamos "a favor" con ambas manos.
pregunta: escribes en rsyslog. Tanto TCP como UDP están disponibles allí. Pero si es UDP, ¿cómo garantiza la entrega?
respuestaR: Hay dos puntos. Primero, inmediatamente les digo a todos que no garantizamos la entrega de registros. Porque cuando los desarrolladores vienen y dicen: “Empecemos a escribir datos financieros allí, y los pondrás en algún lugar para nosotros en caso de que suceda algo”, les respondemos: “¡Genial! Comencemos a bloquear al escribir en el socket y hagámoslo en transacciones, de modo que tenga la garantía de colocarlo en el socket por nosotros y asegurarse de que lo recibimos del otro lado. Y en este momento, todos se vuelven inmediatamente innecesarios. Y si no, ¿qué preguntas tenemos? Si no desea garantizar una escritura en el socket, ¿por qué garantizaríamos la entrega? Estamos haciendo el mejor esfuerzo. Realmente tratamos de entregar tanto como sea posible y lo mejor posible, pero no damos una garantía del 100%. Por lo tanto, no necesita escribir datos financieros allí. Hay bases de datos transaccionales para esto.
pregunta: Cuando la API genera algún mensaje en el registro y transfiere el control a los microservicios, ¿ha encontrado el problema de que los mensajes de diferentes microservicios llegan en el orden incorrecto? Debido a esto, surge la confusión.
respuestaR: Es normal que vengan en un orden diferente. Tienes que estar preparado para esto. Porque cualquier entrega de la red no le garantiza el pedido, o necesita gastar recursos especiales en esto. Si tomamos almacenamientos de archivos, cada API guarda registros en su propio archivo. Más bien, rsyslog los descompone en directorios allí. Cada API tiene sus propios registros allí, donde puede ir y mirar, y luego puede compararlos usando la marca de tiempo en este registro. Si van a buscar en Graylog, allí se ordenarán por marca de tiempo. Todo estará bien allí.
pregunta: La marca de tiempo puede variar en milisegundos.
respuesta: La marca de tiempo la genera la propia API. Esto, de hecho, es todo el punto. Tenemos NTP. La API genera una marca de tiempo ya en el propio mensaje. No es agregado por rsyslog.
pregunta: La interacción entre los centros de datos no está muy clara. En el marco del centro de datos, está claro cómo se recopilaron y procesaron los registros. ¿Cómo es la interacción entre los centros de datos? ¿O cada centro de datos vive su propia vida?
respuesta: Casi. Tenemos cada país ubicado en un centro de datos. Actualmente no tenemos difusión, por lo que un país se coloca en diferentes centros de datos. Por lo tanto, no hay necesidad de combinarlos. Dentro de cada centro hay un Log Relay. Este es un servidor Rsyslog. De hecho, dos máquinas de gestión. Se configuran de la misma manera. Pero por ahora, el tráfico solo pasa por uno de ellos. Ella registra todos los agregados. Tiene una cola de disco por si acaso. Ella presiona los registros y los envía al centro de datos central (Singapur), donde además ya están envenenados en Graylog. Y cada centro de datos tiene su propio almacenamiento de archivos. En caso de que perdamos la conexión, tenemos todos los registros allí. Se quedarán allí. Se almacenarán allí.
pregunta: ¿Obtiene registros de allí durante situaciones anormales?
respuesta: Puede ir allí (al almacenamiento de archivos) y mirar.
pregunta: ¿Cómo supervisa que no pierda registros?
respuesta: De hecho, los estamos perdiendo y lo estamos monitoreando. El seguimiento comenzó hace un mes. La biblioteca que usan las API de Go tiene métricas. Puede contar cuántas veces falló al escribir en el socket. Allí, en este momento, hay una heurística engañosa. Hay un amortiguador allí. Intenta escribir un mensaje desde él al socket. Si el búfer se desborda, comienza a descartarlos. Y cuenta cuántos los dejó caer. Si los contadores comienzan a desbordarse allí, lo sabremos. Ahora también están llegando a Prometheus, y puedes ver los gráficos en Grafana. Puede configurar alertas. Pero aún no está claro a quién enviarlos.
pregunta: En elasticsearch, almacena registros con redundancia. ¿Cuántas réplicas tienes?
respuesta: Una réplica.
pregunta: ¿Es sólo una línea?
respuesta: Este es el maestro y la réplica. Los datos se almacenan por duplicado.
pregunta: ¿Modificaste el tamaño del búfer rsyslog de alguna manera?
respuesta: Escribimos datagramas en un socket Unix personalizado. Esto nos impone inmediatamente una limitación de 128 kilobytes. No podemos escribir más en él. Hemos escrito esto en el estándar. Quién quiere entrar en el almacenamiento, escriben 128 kilobytes. Las bibliotecas, además, cortan, y ponen una bandera de que el mensaje está cortado. Tenemos un campo especial en el estándar del propio mensaje, que muestra si se cortó durante la grabación o no. Entonces tenemos la oportunidad de rastrear este momento.
Pregunta: ¿Escribes JSON roto?
respuesta: El JSON roto se descartará durante la retransmisión porque el paquete es demasiado grande. O se eliminará Graylog, porque no podrá analizar JSON. Pero aquí hay matices que deben corregirse, y en su mayoría están vinculados a rsyslog. Ya he completado algunos problemas allí, que aún necesitan ser trabajados.
Pregunta: ¿Por qué Kafka? ¿Has probado RabbitMQ? ¿Graylog no se suma bajo tales cargas?
respuesta: No funciona con Graylog. Y Graylog está tomando forma. Es realmente problemático para él. Él es una especie de cosa. Y, de hecho, no es necesario. Prefiero escribir desde rsyslog directamente a elasticsearch y luego ver Kibana. Pero tenemos que resolver el problema con los guardias de seguridad. Esta es una posible variante de nuestro desarrollo cuando descartamos Graylog y usamos Kibana. Logstash no tendrá sentido. Porque puedo hacer lo mismo con rsyslog. Y tiene un módulo para escribir en elasticsearch. Con Graylog estamos tratando de vivir de alguna manera. Incluso lo modificamos un poco. Pero todavía hay margen de mejora.
Sobre Kafka. Así sucedió históricamente. Cuando llegué, ya estaba allí y ya se estaban escribiendo registros. Simplemente levantamos nuestro clúster y movimos registros en él. Lo manejamos, sabemos cómo se siente. En cuanto a RabbitMQ... estamos teniendo problemas con RabbitMQ. Y RabbitMQ se está desarrollando para nosotros. Lo tenemos en producción, y hubo problemas con él. Ahora, antes de la venta, sería chamanizado y comenzaría a trabajar normalmente. Pero antes de eso, no estaba listo para lanzarlo a producción. Hay una cosa más. Graylog puede leer la versión AMQP 0.9 y rsyslog puede escribir la versión AMQP 1.0. Y no hay una sola solución que pueda hacer ambas cosas en el medio. Hay uno o el otro. Así que por ahora solo Kafka. Pero también hay matices. Porque omkafka de la versión de rsyslog que usamos puede perder todo el búfer de mensajes que obtuvo de rsyslog. Mientras nos aguantemos.
Pregunta: ¿Estás usando Kafka porque lo tenías? ¿No se usa para ningún otro propósito?
respuesta: Kafka, que fue utilizado por el equipo de Data Science. Este es un proyecto completamente separado, sobre el cual, lamentablemente, no puedo decir nada. No lo sé. Fue dirigida por el equipo de Data Science. Cuando comenzaron los registros, decidieron usarlo, para no poner los suyos. Ahora hemos actualizado Graylog y hemos perdido compatibilidad, porque hay una versión antigua de Kafka. Tuvimos que hacer el nuestro. Al mismo tiempo, nos deshicimos de estos cuatro temas para cada API. Hicimos una parte superior ancha para todos los directos, una parte superior ancha para todas las puestas en escena y filmamos todo allí. Graylog analiza todo esto en paralelo.
Pregunta: ¿Por qué necesitamos este chamanismo con enchufes? ¿Ha intentado usar el controlador de registro de syslog para contenedores?
respuesta: En el momento en que hicimos esta pregunta, teníamos relaciones tensas con el docker. Era docker 1.0 o 0.9. Docker en sí era extraño. En segundo lugar, si también inserta registros en él... Tengo una sospecha no verificada de que pasa todos los registros a través de sí mismo, a través del demonio docker. Si tenemos una API que se vuelve loca, entonces el resto de las API se encontrarán con el hecho de que no pueden enviar stdout y stderr. No sé a dónde llevará esto. Tengo una sospecha a nivel de sentir que no es necesario usar el controlador docker syslog en este lugar. Nuestro departamento de pruebas funcionales tiene su propio clúster Graylog con registros. Usan controladores de registro de ventana acoplable y todo parece estar bien allí. Pero inmediatamente le escriben GELF a Graylog. En el momento en que empezamos todo esto, necesitábamos que simplemente funcionara. Quizá más adelante, cuando venga alguien y diga que lleva cien años funcionando con normalidad, lo intentaremos.
Pregunta: realiza entregas entre centros de datos mediante rsyslog. ¿Por qué no en Kafka?
respuesta: Hacemos esto, y así es como realmente es. Por dos razones. Si el canal está completamente muerto, todos nuestros registros, incluso en forma comprimida, no subirán a través de él. Y kafka les permite simplemente perder en el proceso. De esta forma, nos deshacemos del pegado de estos troncos. Solo estamos usando Kafka en este caso directamente. Si tenemos un buen canal y queremos liberarlo, entonces usamos su rsyslog. Pero, de hecho, puede configurarlo para que suelte lo que no pasó. Por el momento, solo estamos usando la entrega de rsyslog directamente en algún lugar, en algún lugar de Kafka.
Fuente: habr.com