el art\u00edculo sobre Badushka<\/a><\/noindex>, que escribi\u00f3 sobre esto. Pero hay un detalle. Alrededor de esta llamada hab\u00eda un ciclo infinito, donde constantemente se intentaba enviar un mensaje al socket. Eso no lo notamos. Tuvimos que reescribir la biblioteca. Desde entonces ha cambiado varias veces, pero ahora hemos eliminado los bloqueos en todos los subsistemas. Por lo tanto, se puede detener rsyslog y no fallar\u00e1 nada.<\/p>\n<\/p>\n
Es necesario monitorear el tama\u00f1o de las colas, lo que ayuda a evitar cometer estos errores. En primer lugar, podemos monitorear cu\u00e1ndo comenzamos a perder mensajes. En segundo lugar, podemos monitorear si en general tenemos problemas con la entrega.<\/p>\n
<\/p>\n
Y hay otro punto desagradable: la amplificaci\u00f3n de 10 veces en una arquitectura de microservicios es muy f\u00e1cil. No tenemos muchas solicitudes entrantes, pero debido al grafo por el que circulan estos mensajes, debido a los registros de acceso, realmente aumentamos la carga en los registros aproximadamente diez veces. Lamentablemente, no tuve tiempo de calcular cifras exactas, pero los microservicios son as\u00ed. Hay que tenerlo en cuenta. Por lo tanto, en este momento, el subsistema de recopilaci\u00f3n de registros es el m\u00e1s sobrecargado en Lazada. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfC\u00f3mo solucionar el problema de elasticsearch? Si necesita obtener r\u00e1pidamente los registros en un solo lugar, para no tener que ir a todas las m\u00e1quinas y recogerlos all\u00ed, use un almacenamiento de archivos. Eso funciona garantizado. Se puede hacer desde cualquier servidor. Solo necesita colocar discos all\u00ed y configurar syslog. Despu\u00e9s de eso, tendr\u00e1 todos los registros garantizados en un solo lugar. Luego podr\u00e1 configurar elasticsearch, graylog o algo m\u00e1s a su ritmo. Pero ya tendr\u00e1 todos los registros y, de hecho, podr\u00e1 almacenarlos tanto como los arrays de disco lo permitan.<\/p>\n
<\/p>\n
<\/p>\n
En el momento de mi presentaci\u00f3n, el esquema se ve\u00eda as\u00ed. Pr\u00e1cticamente hemos dejado de escribir en archivos. Ahora, probablemente, desconectaremos los remanentes. En las m\u00e1quinas locales donde se ejecutan las API, dejaremos de escribir en archivos. En primer lugar, hay un almacenamiento de archivos que funciona muy bien. En segundo lugar, en estas m\u00e1quinas, el espacio se llena constantemente, hay que monitorearlo continuamente.<\/p>\n
<\/p>\n
Esta parte con Logstash y Graylog realmente est\u00e1 generando problemas. Por eso hay que deshacerse de ella. Hay que elegir una de las dos.<\/p>\n
<\/p>\n
<\/p>\n
Decidimos dejar de lado Logstash y Kibana. Porque tenemos un departamento de seguridad. \u00bfCu\u00e1l es la conexi\u00f3n? La conexi\u00f3n es que Kibana, sin X-Pack y sin Shield, no permite diferenciar los derechos de acceso a los registros. Por eso optamos por Graylog. Tiene todo esto. No me gusta, pero funciona. Compramos nuevo hardware, instalamos Graylog fresco y trasladamos todos los registros con formatos estrictos a un Graylog separado. Resolv\u00edmos el problema de diferentes tipos de campos iguales de manera organizativa.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 incluye realmente el nuevo Graylog? Simplemente lo grabamos todo en Docker. Tomamos un mont\u00f3n de servidores, desplegamos tres instancias de Kafka y 7 servidores de Graylog versi\u00f3n 2.3 (porque quer\u00edamos Elasticsearch versi\u00f3n 5). Todo esto lo levantamos en RAID de HDD. Vimos una tasa de indexaci\u00f3n de hasta 100 mil mensajes por segundo. Vimos la cifra de que 140 terabytes de datos por semana. <\/p>\n
<\/p>\n
<\/p>\n
\u00a1Y nuevamente tropiezos! Se avecinan dos ventas. Nos mudamos por 6 millones de mensajes. Graylog no logra procesar todo. De alguna manera, tenemos que sobrevivir nuevamente. <\/p>\n
<\/p>\n
<\/p>\n
Sobrevivimos de esta manera. Agregamos un poco m\u00e1s de servidores y SSD. En este momento, vivimos de esta forma. Ahora procesamos ya 160 mil mensajes por segundo. A\u00fan no hemos llegado al l\u00edmite, por lo que por ahora no est\u00e1 claro cu\u00e1nto realmente podremos extraer de esto. <\/p>\n
<\/p>\n
<\/p>\n
Estos son nuestros planes para el futuro. De ellos, realmente, lo m\u00e1s importante, probablemente, sea la alta disponibilidad. A\u00fan no la tenemos. Algunas m\u00e1quinas est\u00e1n configuradas de la misma manera, pero todo pasa por una sola m\u00e1quina. Necesitamos dedicar tiempo a configurar el failover entre ellas.<\/p>\n
<\/p>\n
Recoger m\u00e9tricas de Graylog.<\/p>\n
<\/p>\n
Hacer un rate limit para que nuestra API, que se volvi\u00f3 loca, no nos destruya el bandwidth y todo lo dem\u00e1s.<\/p>\n
<\/p>\n
Y finalmente, firmar alg\u00fan SLA con los desarrolladores, indicando que podemos atender hasta esta cantidad. Si ustedes escriben m\u00e1s, lo sentimos.<\/p>\n
<\/p>\n
Y escribir documentaci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
En resumen, los resultados de todo lo que hemos vivido. Primero, est\u00e1ndares. Segundo, syslog \u2014 una delicia. Tercero, rsyslog funciona exactamente como se indica en la diapositiva. Y pasemos a las preguntas.<\/p>\n
<\/p>\n
Preguntas<\/strong>.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfPor qu\u00e9 decidieron no usar\u2026 (filebeat?)<\/p>\n<\/p>\n
Respuesta<\/strong>: Necesitamos escribir en un archivo. No quer\u00eda hacerlo en absoluto. Cuando tu API escribe miles de mensajes por segundo, incluso si rotas una vez por hora, sigue sin ser una opci\u00f3n. Se puede escribir en un pipe. A lo que los desarrolladores me preguntaron: \u00ab\u00bfQu\u00e9 pasar\u00e1 si el proceso al que estamos escribiendo se cae?\u00bb Simplemente no encontr\u00e9 qu\u00e9 responderles y dije: \u00abBueno, est\u00e1 bien, no lo hagamos\u00bb.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfPor qu\u00e9 no escriben los registros directamente en HDFS?<\/p>\n<\/p>\n
Respuesta<\/strong>: Este es el siguiente paso. Lo pensamos desde un principio, pero, como en este momento no hay recursos para trabajar en ello, queda como una soluci\u00f3n a largo plazo.<\/p>\n<\/p>\n
Pregunta<\/strong>: Un formato columnar ser\u00eda m\u00e1s adecuado.<\/p>\n<\/p>\n
Respuesta<\/strong>: Entiendo todo. Estamos \"a favor\" con ambas manos. <\/p>\n<\/p>\n
Pregunta<\/strong>: Escriben en rsyslog. Ah\u00ed se puede usar TCP y UDP. Pero si es UDP, \u00bfc\u00f3mo garantizan la entrega?<\/p>\n<\/p>\n
Respuesta<\/strong>: Hay dos puntos. Primero, les digo desde el principio que no garantizamos la entrega de los registros. Porque cuando los desarrolladores vienen y dicen: 'Vamos a empezar a escribir datos financieros ah\u00ed, y ustedes los almacenar\u00e1n en alg\u00fan lugar por si algo sucede', nosotros les respondemos '\u00a1Genial! Vamos a hacer que se bloqueen en la escritura en el socket y a hacer esto en transacciones, para que nos aseguren que lo han puesto en el socket y verifiquen que lo recibimos por el otro lado.' En ese momento, a todos se les quita el inter\u00e9s. Y si no est\u00e1n interesados, \u00bfcu\u00e1les son nuestras preguntas? Si no quieren garantizar la escritura en el socket, \u00bfpor qu\u00e9 debemos garantizar la entrega? Hacemos un esfuerzo m\u00e1ximo. Realmente intentamos entregar tanto como sea posible y lo mejor que podamos, pero no damos garant\u00edas del 100%. As\u00ed que no deben escribir datos financieros ah\u00ed. Para eso hay bases de datos con transacciones.<\/p>\n<\/p>\n
Pregunta<\/strong>: Cuando una API genera alg\u00fan mensaje en el registro y pasa el control a los microservicios, \u00bfno han tenido el problema de que los mensajes de diferentes microservicios llegan en un orden incorrecto? Esto causa confusi\u00f3n.<\/p>\n<\/p>\n
Respuesta<\/strong>: Es normal que lleguen en diferente orden. Hay que estar preparados para ello. Porque cualquier entrega a trav\u00e9s de la red no garantiza el orden, o hay que gastar recursos espec\u00edficamente para eso. Si tomamos los almacenes de archivos, cada API guarda los registros en su propio archivo. M\u00e1s bien, rsyslog los distribuye en carpetas. Cada API tiene sus propios registros a los que se puede acceder y luego se pueden correlacionar por timestamp en ese registro. Si van a ver en Graylog, all\u00ed est\u00e1n ordenados por timestamp. Todo estar\u00e1 bien.<\/p>\n<\/p>\n
Pregunta<\/strong>: El timestamp puede diferir en milisegundos.<\/p>\n<\/p>\n
Respuesta<\/strong>: El timestamp lo genera la API misma. Esa es la esencia. Nosotros tenemos NTP. La API genera el timestamp ya en el propio mensaje. No lo agrega rsyslog.<\/p>\n<\/p>\n
Pregunta<\/strong>: No est\u00e1 muy claro c\u00f3mo interact\u00faan los centros de datos. Dentro de un centro de datos se entiende c\u00f3mo se recopilan y procesan los logs. \u00bfC\u00f3mo se produce la interacci\u00f3n entre los centros de datos? \u00bfO cada centro de datos vive su propia vida?<\/p>\n<\/p>\n
Respuesta<\/strong>: Casi. Cada pa\u00eds est\u00e1 en alg\u00fan centro de datos espec\u00edfico. No tenemos, en este momento, una dispersi\u00f3n de un pa\u00eds a varios centros de datos. As\u00ed que no es necesario fusionarlos. Dentro de cada centro hay un Log Relay. Es un servidor Rsyslog. En realidad, hay dos m\u00e1quinas de gesti\u00f3n. Est\u00e1n configuradas de la misma manera. Pero, por ahora, el tr\u00e1fico solo pasa por una de ellas. Esta agrega todos los logs. Tiene una cola en disco por si acaso. Comprime los logs y los env\u00eda al centro de datos central (el de Singapur), donde luego se env\u00edan a Graylog. Y en cada centro de datos hay su propio almacenamiento de archivos. En caso de que perdamos la conexi\u00f3n, tenemos todos los logs ah\u00ed. Permanecer\u00e1n all\u00ed. Ser\u00e1n guardados.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfRecibes logs de ah\u00ed en situaciones excepcionales?<\/p>\n<\/p>\n
Respuesta<\/strong>: Se puede ir all\u00ed (al almacenamiento de archivos) y revisar.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfC\u00f3mo monitorean para asegurarse de que no pierden logs?<\/p>\n<\/p>\n
Respuesta<\/strong>: En realidad, los perdemos, y lo estamos monitoreando. Iniciamos el monitoreo hace un mes. En la biblioteca que utiliza la API de Go, hay m\u00e9tricas. Puede contar cu\u00e1ntas veces no pudo escribir en el socket. Actualmente, hay una heur\u00edstica inteligente. Hay un b\u00fafer. Intenta escribir mensajes en el socket desde \u00e9l. Si el b\u00fafer se llena, comienza a descartarlos. Y cuenta cu\u00e1ntos ha descartado. Si los contadores comienzan a llenarse, nos enteramos. Ahora llegan a Prometheus y se pueden ver gr\u00e1ficos en Grafana. Se pueden configurar alertas. Pero por ahora no est\u00e1 claro a qui\u00e9n enviarlas.<\/p>\n<\/p>\n
Pregunta<\/strong>: En Elasticsearch almacenar logs con redundancia. \u00bfCu\u00e1ntas r\u00e9plicas tienen?<\/p>\n<\/p>\n
Respuesta<\/strong>: Una r\u00e9plica.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfEs solo una r\u00e9plica?<\/p>\n<\/p>\n
Respuesta<\/strong>: Es un maestro y una r\u00e9plica. Los datos se almacenan en dos instancias.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfHas ajustado de alguna manera el tama\u00f1o del b\u00fafer de rsyslog? <\/p>\n<\/p>\n
Respuesta<\/strong>: Estamos escribiendo datagramas en un socket unix personalizado. Esto nos impone de inmediato una limitaci\u00f3n de 128 kilobytes. No podemos escribir m\u00e1s que eso. Lo hemos establecido en el est\u00e1ndar. Aquellos que quieren acceder a los storages, escriben 128 kilobytes. Las bibliotecas, de hecho, recortan y colocan una bandera indicando que el mensaje fue recortado. En nuestro est\u00e1ndar del propio mensaje hay un campo especial que muestra si fue recortado al escribir o no. As\u00ed que tenemos la capacidad de rastrear ese aspecto.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfEscriben JSON da\u00f1ados? <\/p>\n<\/p>\n
Respuesta<\/strong>: El JSON da\u00f1ado ser\u00e1 descartado ya sea durante el relay, porque el paquete es demasiado grande, o ser\u00e1 descartado por Graylog, ya que no podr\u00e1 parsear el JSON. Pero aqu\u00ed hay matices que deben corregirse, y la mayor\u00eda de ellos est\u00e1n relacionados con rsyslog. Ya he registrado all\u00ed varios problemas que a\u00fan debemos abordar.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfPor qu\u00e9 Kafka? \u00bfHan probado RabbitMQ? \u00bfGraylog no se desempe\u00f1a bien bajo tales cargas?<\/p>\n<\/p>\n
Respuesta<\/strong>: No tenemos buena experiencia con Graylog. Con \u00e9l realmente es problem\u00e1tico. Es una cosa peculiar. Y, en realidad, no lo necesitamos. Preferir\u00eda escribir directamente desde rsyslog a Elasticsearch y luego ver en Kibana. Pero necesitamos resolver el tema con los de seguridad. Esta es una posible direcci\u00f3n de nuestro desarrollo, cuando desecharemos Graylog y usaremos Kibana. No tiene sentido usar Logstash. Porque puedo hacer exactamente lo mismo con rsyslog. Y tiene un m\u00f3dulo para escribir en Elasticsearch. Estamos tratando de lidiar con Graylog. Incluso lo hemos afinado un poco. Pero a\u00fan hay espacio para mejoras.<\/p>\n<\/p>\n
Sobre Kafka. Hist\u00f3ricamente, as\u00ed ha sido. Cuando llegu\u00e9, ya exist\u00eda y se estaban registrando logs en ella. Simplemente levantamos nuestro cl\u00faster y trasladamos los logs a \u00e9l. Lo gestionamos, sabemos c\u00f3mo est\u00e1 funcionando. En cuanto a RabbitMQ... no nos llevamos bien con RabbitMQ. Pero con RabbitMQ tenemos una buena relaci\u00f3n. Lo tenemos en producci\u00f3n y tuvimos problemas con \u00e9l. Poco antes de las rebajas le hicimos ajustes y empez\u00f3 a funcionar bien. Pero antes de eso, no estaba listo para ponerlo en producci\u00f3n. Hay otro aspecto. Graylog puede leer la versi\u00f3n AMQP 0.9, mientras que rsyslog puede escribir la versi\u00f3n AMQP 1.0. No hay soluci\u00f3n alguna que maneje ambos. Solo hay una o la otra. Por lo tanto, por el momento, solo Kafka. Pero tambi\u00e9n tiene sus matices. Porque omkafka de la versi\u00f3n de rsyslog que usamos puede perder todo el buffer de mensajes que ha recopilado de rsyslog. Por ahora, tenemos que vivir con eso. <\/p>\n
<\/p>\n
Pregunta<\/strong>: \u00bfUtilizan Kafka porque ya la ten\u00edan? \u00bfNo se utiliza para otros prop\u00f3sitos?<\/p>\n<\/p>\n
Respuesta<\/strong>: La Kafka que ten\u00edan est\u00e1 siendo utilizada por el equipo de Data Science. Es un proyecto completamente separado, del que, lamentablemente, no puedo decir mucho. No estoy al tanto. Estaba bajo la responsabilidad del equipo de Data Science. Decidieron usarla al empezar a registrar logs, para no instalar otra. Ahora hemos actualizado Graylog y hemos perdido la compatibilidad porque hay una versi\u00f3n antigua de Kafka. Tuvimos que establecer la nuestra. Adem\u00e1s, nos deshicimos de esos cuatro t\u00f3picos para cada API. Creamos un \u00fanico t\u00f3pico ancho para todos los live, un t\u00f3pico ancho para todos los staging y simple y sencillamente estamos enviando todos los logs all\u00ed. Graylog est\u00e1 recogiendo todo eso en paralelo.<\/p>\n<\/p>\n
Pregunta<\/strong>: \u00bfPor qu\u00e9 es necesario este tipo de ajustes con los sockets? \u00bfHan probado utilizar el controlador de logs syslog para los contenedores?<\/p>\n<\/p>\n
Respuesta<\/strong>: En el momento en que est\u00e1bamos abordando este tema, nuestra relaci\u00f3n con Docker era tensa. Era Docker 1.0 o 0.9. Docker en s\u00ed era extra\u00f1o. En segundo lugar, si encima se intentaban meter los logs... Tengo una sospecha no comprobada de que pasa todos los logs a trav\u00e9s de su demonio. Si una de nuestras APIs se vuelve loca, las otras APIs se atascan porque no pueden enviar stdout y stderr. No s\u00e9 a d\u00f3nde conducir\u00e1 esto. Tengo una sospecha, a nivel de intuici\u00f3n, de que no deber\u00edamos usar el controlador syslog de Docker en este lugar. Nuestro departamento de pruebas funcionales tiene su propio peque\u00f1o cl\u00faster de Graylog para los logs. Ellos usan los controladores de logs de Docker y, al parecer, les va bastante bien. Pero ellos escriben directamente en Graylog utilizando GELF. En ese momento, cuando comenzamos con todo esto, solo necesit\u00e1bamos que funcionara. Quiz\u00e1s m\u00e1s adelante, cuando alguien venga y diga que ya lleva funcionando bien un tiempo, lo intentaremos.<\/p>\n<\/p>\n
Pregunta<\/strong>: Hacen la entrega entre centros de datos con rsyslog. \u00bfPor qu\u00e9 no con Kafka?<\/p>\n<\/p>\n
Respuesta<\/strong>: Hacemos ambas cosas, en realidad. Por dos razones. Si el canal est\u00e1 completamente da\u00f1ado, ni siquiera todos nuestros logs en versi\u00f3n comprimida pasan a trav\u00e9s de \u00e9l. Kafka nos permite simplemente perderlos en el proceso. De esta manera, evitamos que esos logs se queden atascados. En este caso, usamos Kafka directamente. Si el canal es bueno y queremos liberarlo, utilizamos rsyslog. Pero en realidad, podr\u00eda configurarse para que eliminara autom\u00e1ticamente lo que no pudo pasar. Actualmente, usamos rsyslog directamente en algunos lugares y Kafka en otros.<\/p>\nFuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041b\u043e\u0433\u0438 \u2014 \u0432\u0430\u0436\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u043e\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 (\u043b\u0438\u0431\u043e \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u043a\u0430\u043a \u043e\u0436\u0438\u0434\u0430\u0435\u0442\u0441\u044f. \u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043b\u043e\u0433\u0430\u043c\u0438 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u043e\u0439 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u043e\u043b\u0438\u043c\u043f\u0438\u0430\u0434\u044b. \u041d\u0443\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u0441\u0440\u0430\u0437\u0443 \u043a\u0443\u0447\u0443 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432: \u043a\u0430\u043a \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438 \u0438\u0437 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f; \u043a\u0443\u0434\u0430 \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438; \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438; \u043a\u0430\u043a \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u0438 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438. \u041f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043d\u044b\u043d\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Reproducir](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n