La próxima conferencia HighLoad++ se llevará a cabo los días 6 y 7 de abril de 2020 en San Petersburgo Detalles y entradas . HighLoad++ Moscú 2018. Salón “Moscú”. 9 de noviembre, 15:00 horas. Tesis y .
* Monitoreo: en línea y análisis.
* Limitaciones básicas de la plataforma ZABBIX.
* Solución para escalar el almacenamiento de análisis.
* Optimización del servidor ZABBIX.
* Optimización de la interfaz de usuario.
* Experiencia operando el sistema bajo cargas de más de 40k NVPS.
* Breves conclusiones.
Mikhail Makurov (en adelante – MM): - ¡Hola a todos!
Maxim Chernetsov (en adelante – MCH): - ¡Buenas tardes!
mm: – Déjame presentarte a Maxim. Max es un ingeniero talentoso, el mejor networker que conozco. Maxim participa en redes y servicios, su desarrollo y operación.
MCH: – Y me gustaría hablarte de Mikhail. Mikhail es desarrollador de C. Escribió varias soluciones de procesamiento de tráfico de alta carga para nuestra empresa. Vivimos y trabajamos en los Urales, en la ciudad de los hombres duros Chelyabinsk, en la empresa Intersvyaz. Nuestra empresa es proveedora de servicios de Internet y televisión por cable para un millón de personas en 16 ciudades.
mm: – Y vale la pena decir que Intersvyaz es mucho más que un simple proveedor, es una empresa de TI. La mayoría de nuestras soluciones son realizadas por nuestro departamento de TI.
A: desde servidores que procesan el tráfico hasta un centro de llamadas y una aplicación móvil. El departamento de TI cuenta ahora con unas 80 personas con competencias muy, muy diversas.
Sobre Zabbix y su arquitectura
MCH: – Y ahora intentaré establecer un récord personal y decir en un minuto qué es Zabbix (en adelante, “Zabbix”).
Zabbix se posiciona como un sistema de monitoreo listo para usar a nivel empresarial. Tiene muchas características que hacen la vida más fácil: reglas de escalamiento avanzadas, API para integración, agrupación y detección automática de hosts y métricas. Zabbix tiene las llamadas herramientas de escalamiento: proxies. Zabbix es un sistema de código abierto.
Brevemente sobre arquitectura. Podemos decir que consta de tres componentes:
- Servidor. Escrito en c. Con procesamiento y transferencia de información bastante complejo entre hilos. En él se realiza todo el procesamiento: desde la recepción hasta el almacenamiento en la base de datos.
- Todos los datos se almacenan en la base de datos. Zabbix es compatible con MySQL, PostreSQL y Oracle.
- La interfaz web está escrita en PHP. En la mayoría de los sistemas viene con un servidor Apache, pero funciona de manera más eficiente en combinación con nginx + php.
Hoy nos gustaría contar una historia de la vida de nuestra empresa relacionada con Zabbix...
Una historia de la vida de la empresa Intersvyaz. ¿Qué tenemos y qué necesitamos?
Hace 5 o 6 meses. Un día después del trabajo...
MCH: - ¡Misha, hola! Me alegro de haber logrado atraparte: hay una conversación. Nuevamente tuvimos problemas con el seguimiento. Durante un accidente importante, todo iba lento y no había información sobre el estado de la red. Desafortunadamente, esta no es la primera vez que esto sucede. Necesito tu ayuda. ¡Hagamos que nuestro seguimiento funcione bajo cualquier circunstancia!
mm: - Pero sincronicemos primero. No he mirado allí en un par de años. Hasta donde recuerdo, abandonamos Nagios y cambiamos a Zabbix hace unos 8 años. Y ahora parece que tenemos 6 servidores potentes y alrededor de una docena de servidores proxy. ¿Estoy confundiendo algo?
MCH: - Casi. 15 servidores, algunos de los cuales son máquinas virtuales. Lo más importante es que no nos salva en el momento en que más lo necesitamos. Como un accidente: los servidores se ralentizan y no puedes ver nada. Intentamos optimizar la configuración, pero esto no proporcionó el aumento óptimo del rendimiento.
mm: - Está vacío. ¿Miraste algo? ¿Ya desenterraste algo de los diagnósticos?
MCH: – Lo primero con lo que tienes que lidiar es con la base de datos. MySQL se carga constantemente, almacena nuevas métricas, y cuando Zabbix comienza a generar un montón de eventos, la base de datos se acelera durante literalmente unas horas. Ya les hablé de optimizar la configuración, pero literalmente este año actualizaron el hardware: los servidores tienen más de cien gigabytes de memoria y matrices de discos en RAID SSD; no tiene sentido crecer linealmente a largo plazo. qué hacemos?
mm: - Está vacío. En general, MySQL es una base de datos LTP. Al parecer, ya no es adecuado para almacenar un archivo de métricas de nuestro tamaño. Vamos a resolverlo.
MCH: - ¡Vamos!
Integración de Zabbix y Clickhouse como resultado del hackathon
Después de un tiempo recibimos datos interesantes:
La mayor parte del espacio de nuestra base de datos estaba ocupado por el archivo de métricas y menos del 1% se utilizaba para configuración, plantillas y ajustes. En ese momento, llevábamos más de un año operando la solución Big data basada en Clickhouse. La dirección del movimiento era obvia para nosotros. En nuestro Hackathon de primavera, escribí la integración de Zabbix con Clickhouse para el servidor y el frontend. En ese momento, Zabbix ya tenía soporte para ElasticSearch y decidimos compararlos.
Comparación de Clickhouse y Elasticsearch
mm: – A modo de comparación, generamos la misma carga que proporciona el servidor Zabbix y observamos cómo se comportarían los sistemas. Escribimos datos en lotes de 1000 líneas, usando CURL. Supusimos de antemano que Clickhouse sería más eficiente para el perfil de carga que Zabbix. Los resultados incluso superaron nuestras expectativas:
En las mismas condiciones de prueba, Clickhouse escribió tres veces más datos. Al mismo tiempo, ambos sistemas consumieron de manera muy eficiente (una pequeña cantidad de recursos) al leer datos. Pero Elastics requirió una gran cantidad de procesador al grabar:
En total, Clickhouse superó significativamente a Elastix en términos de consumo y velocidad del procesador. Al mismo tiempo, debido a la compresión de datos, Clickhouse utiliza 11 veces menos disco duro y realiza aproximadamente 30 veces menos operaciones en el disco:
MCH: – Sí, el trabajo de Clickhouse con el subsistema de disco se implementa de manera muy eficiente. Puede utilizar enormes discos SATA para bases de datos y obtener velocidades de escritura de cientos de miles de líneas por segundo. El sistema listo para usar admite fragmentación, replicación y es muy fácil de configurar. Estamos más que satisfechos con su uso durante todo el año.
Para optimizar los recursos, puede instalar Clickhouse junto a su base de datos principal existente y así ahorrar mucho tiempo de CPU y operaciones de disco. Hemos trasladado el archivo de métricas a los clústeres de Clickhouse existentes:
Aliviamos tanto la base de datos MySQL principal que pudimos combinarla en una máquina con el servidor Zabbix y abandonar el servidor dedicado para MySQL.
¿Cómo funcionan las encuestas en Zabbix?
Hace meses 4
mm: – Bueno, ¿podemos olvidarnos de los problemas con la base?
MCH: - ¡Eso es seguro! Otro problema que debemos resolver es la lentitud en la recopilación de datos. Ahora nuestros 15 servidores proxy están sobrecargados con SNMP y procesos de sondeo. Y no hay otra manera que instalar servidores nuevos y nuevos.
mm: - Excelente. Pero primero, cuéntanos cómo funcionan las encuestas en Zabbix.
MCH: – En definitiva, existen 20 tipos de métricas y una docena de formas de obtenerlas. Zabbix puede recopilar datos en el modo "solicitud-respuesta" o esperar nuevos datos a través de la "Interfaz Trapper".
Vale la pena señalar que en el Zabbix original este método (Trapper) es el más rápido.
Existen servidores proxy para distribución de carga:
Los proxy pueden realizar las mismas funciones de recopilación que el servidor Zabbix, recibiendo tareas de él y enviando las métricas recopiladas a través de la interfaz Trapper. Esta es la forma oficialmente recomendada de distribuir la carga. Los proxy también son útiles para monitorear infraestructura remota que opera a través de NAT o un canal lento:
mm: – Con la arquitectura todo está claro. Tenemos que mirar las fuentes...
Un par de días después
La historia de cómo ganó nmap fping
mm: "Creo que desenterré algo".
MCH: - ¡Dime!
mm: – Descubrí que al verificar la disponibilidad, Zabbix verifica un máximo de 128 hosts a la vez. Intenté aumentar este número a 500 y eliminar el intervalo entre paquetes en su ping (ping); esto duplicó el rendimiento. Pero me gustaría números más grandes.
MCH: – En mi práctica, a veces tengo que verificar la disponibilidad de miles de hosts y nunca he visto nada más rápido que nmap para esto. Estoy seguro de que esta es la forma más rápida. ¡Vamos a intentarlo! Necesitamos aumentar significativamente la cantidad de hosts por iteración.
mm: – ¿Verificar más de quinientos? 600?
MCH: - Al menos un par de miles.
mm: - DE ACUERDO. Lo más importante que quería decir es que descubrí que la mayoría de las encuestas en Zabbix se realizan de forma sincrónica. Definitivamente necesitamos cambiarlo al modo asíncrono. Entonces podemos aumentar drásticamente la cantidad de métricas recopiladas por los encuestadores, especialmente si aumentamos la cantidad de métricas por iteración.
MCH: - ¡Excelente! ¿Y cuando?
mm: – Como siempre, ayer.
MCH: – Comparamos ambas versiones de fping y nmap:
En una gran cantidad de hosts, se esperaba que nmap fuera hasta cinco veces más efectivo. Dado que nmap solo verifica la disponibilidad y el tiempo de respuesta, trasladamos el cálculo de pérdidas a los activadores y reducimos significativamente los intervalos de verificación de disponibilidad. Descubrimos que la cantidad óptima de hosts para nmap es de alrededor de 4 mil por iteración. Nmap nos permitió reducir tres veces el costo de CPU de las comprobaciones de disponibilidad y reducir el intervalo de 120 segundos a 10.
Optimización de encuestas
mm: “Entonces empezamos a hacer encuestas. Estábamos interesados principalmente en la detección y los agentes SNMP. En Zabbix, las encuestas se realizan de forma sincrónica y se han tomado medidas especiales para aumentar la eficiencia del sistema. En modo síncrono, la falta de disponibilidad del host provoca una degradación significativa del sondeo. Hay todo un sistema de estados, hay procesos especiales, los llamados encuestadores inalcanzables, que funcionan solo con hosts inalcanzables:
Este es un comentario que demuestra la matriz de estado, toda la complejidad del sistema de transiciones que se requieren para que el sistema siga siendo efectivo. Además, el sondeo sincrónico en sí es bastante lento:
Es por eso que miles de flujos de encuestas en docenas de proxies no pudieron recopilar la cantidad de datos necesaria para nosotros. La implementación asincrónica resolvió no solo los problemas con la cantidad de subprocesos, sino que también simplificó significativamente el sistema de estado de hosts no disponibles, porque para cualquier número verificado en una iteración de sondeo, el tiempo de espera máximo fue 1 tiempo de espera:
Además, modificamos y mejoramos el sistema de sondeo para solicitudes SNMP. El hecho es que la mayoría de las personas no pueden responder a múltiples solicitudes SNMP al mismo tiempo. Por lo tanto, creamos un modo híbrido, cuando el sondeo SNMP del mismo host se realiza de forma asincrónica:
Esto se hace para todo el paquete de hosts. En última instancia, este modo no es más lento que uno completamente asíncrono, ya que sondear cien valores SNMP sigue siendo mucho más rápido que 1 tiempo de espera.
Nuestros experimentos han demostrado que la cantidad óptima de solicitudes en una iteración es aproximadamente 8 mil con sondeo SNMP. En total, la transición al modo asíncrono nos permitió acelerar el rendimiento del sondeo 200 veces, varios cientos de veces.
MCH: – Las optimizaciones de sondeo resultantes mostraron que no solo podemos deshacernos de todos los proxies, sino también reducir los intervalos para muchas comprobaciones, y los proxies ya no serán necesarios como forma de compartir la carga.
Hace unos tres meses
Cambie la arquitectura: ¡aumente la carga!
mm: - Bueno, Max, ¿es hora de ser productivo? Necesito un servidor potente y un buen ingeniero.
MCH: - Está bien, planeémoslo. Ya es hora de salir del punto muerto de 5 mil métricas por segundo.
La mañana después de la actualización
MCH: - Misha, nos actualizamos, pero por la mañana retrocedimos... ¿Adivina qué velocidad logramos alcanzar?
mm: – 20 mil máximo.
MCH: - ¡Sí, 25! Desafortunadamente, estamos justo donde empezamos.
mm: - ¿Por qué? ¿Hiciste algún diagnóstico?
MCH: - ¡Si seguro! Aquí, por ejemplo, hay un top interesante:
mm: - Vamos a mirar. Veo que hemos probado una gran cantidad de hilos de votación:
Pero al mismo tiempo no pudieron reciclar el sistema ni siquiera a la mitad:
Y el rendimiento general es bastante pequeño, alrededor de 4 mil métricas por segundo:
¿Hay algo mas?
MCH: – Sí, rastro de uno de los encuestadores:
mm: – Aquí se puede ver claramente que el proceso de votación está esperando “semáforos”. Estas son las cerraduras:
MCH: - Poco claro.
mm: – Mira, esto es similar a una situación en la que un grupo de subprocesos intentan trabajar con recursos con los que solo uno puede trabajar a la vez. Entonces todo lo que pueden hacer es compartir este recurso a lo largo del tiempo:
Y el rendimiento total de trabajar con dicho recurso está limitado por la velocidad de un núcleo:
Hay dos formas de resolver este problema.
Actualice el hardware de la máquina, cambie a núcleos más rápidos:
O cambiar la arquitectura y al mismo tiempo cambiar la carga:
MCH: – Por cierto, en la máquina de prueba usaremos menos núcleos que en la de combate, ¡pero son 1,5 veces más rápidos en frecuencia por núcleo!
mm: - ¿Claro? Debes mirar el código del servidor.
Ruta de datos en el servidor Zabbix
MCH: – Para resolverlo, comenzamos a analizar cómo se transfieren los datos dentro del servidor Zabbix:
Imagen genial, ¿verdad? Vayamos paso a paso para que quede más o menos claro. Existen hilos y servicios encargados de recopilar datos:
Transmiten las métricas recopiladas a través de un socket al administrador del preprocesador, donde se guardan en una cola:
El "administrador de preprocesador" transmite datos a sus trabajadores, quienes ejecutan instrucciones de preprocesamiento y las devuelven a través del mismo socket:
Después de esto, el administrador del preprocesador los almacena en la memoria caché del historial:
De ahí son tomados por los receptores de historial, que realizan muchas funciones: por ejemplo, calcular activadores, llenar el caché de valores y, lo más importante, guardar métricas en el almacenamiento del historial. En general, el proceso es complejo y muy confuso.
mm: – Lo primero que vimos fue que la mayoría de los hilos compiten por la llamada “caché de configuración” (el área de memoria donde se almacenan todas las configuraciones del servidor). Los hilos responsables de recopilar datos bloquean especialmente:
...ya que la configuración almacena no sólo métricas con sus parámetros, sino también colas de las cuales los encuestadores toman información sobre qué hacer a continuación. Cuando hay muchos pollers y uno bloquea la configuración, los demás esperan solicitudes:
Los encuestadores no deberían entrar en conflicto
Por lo tanto, lo primero que hicimos fue dividir la cola en 4 partes y permitir que los encuestadores bloquearan estas colas, estas partes al mismo tiempo, en condiciones seguras:
Esto eliminó la competencia por el caché de configuración y la velocidad de los encuestadores aumentó significativamente. Pero luego nos encontramos con el hecho de que el administrador del preprocesador comenzó a acumular una cola de trabajos:
El administrador del preprocesador debe poder priorizar
Esto sucedió en los casos en los que le faltó rendimiento. Luego, todo lo que pudo hacer fue acumular solicitudes de los procesos de recopilación de datos y sumar su búfer hasta que consumió toda la memoria y falló:
Para resolver este problema, agregamos un segundo socket dedicado específicamente a los trabajadores:
Así, el administrador del preprocesador tuvo la oportunidad de priorizar su trabajo y, si el buffer crece, la tarea es ralentizar la eliminación, dando a los trabajadores la oportunidad de tomar este buffer:
Luego descubrimos que una de las razones de la desaceleración eran los propios trabajadores, ya que competían por un recurso que carecía por completo de importancia para su trabajo. Documentamos este problema como una corrección de errores y ya se resolvió en las nuevas versiones de Zabbix:
Aumentamos el número de enchufes y obtenemos el resultado.
Además, el propio administrador del preprocesador se convirtió en un cuello de botella, ya que es un hilo. Se basaba en la velocidad central, dando una velocidad máxima de aproximadamente 70 mil métricas por segundo:
Por lo tanto, hicimos cuatro, con cuatro juegos de basas, trabajadores:
Y esto nos permitió aumentar la velocidad a aproximadamente 130 mil métricas:
La no linealidad del crecimiento se explica por el hecho de que ha aparecido competencia por el caché histórico. Por él compitieron 4 administradores de preprocesadores y receptores de historia. En este punto, estábamos recibiendo aproximadamente 130 mil métricas por segundo en la máquina de prueba, utilizándolas aproximadamente el 95% del procesador:
Hace aproximadamente 2,5 meses
El rechazo de la comunidad snmp aumentó los NVP una vez y media
mm: – ¡Max, necesito un nuevo auto de prueba! Ya no encajamos en el actual.
MCH: - ¿Qué tienes ahora?
mm: – Ahora – 130 NVP y un procesador listo para usar.
MCH: - ¡Guau! ¡Fresco! Espera, tengo dos preguntas. Según mis cálculos, nuestra necesidad ronda entre 15 y 20 mil métricas por segundo. ¿Por qué necesitamos más?
mm: "Quiero terminar el trabajo". Me gustaría ver cuánto podemos sacar de este sistema.
MCH: - Pero ...
mm: "Pero es inútil para los negocios".
MCH: - Está vacío. Y la segunda pregunta: ¿podemos soportar lo que tenemos ahora nosotros solos, sin la ayuda de un desarrollador?
mm: - No lo creo. Cambiar el funcionamiento del caché de configuración es un problema. Afecta los cambios en la mayoría de los subprocesos y es bastante difícil de mantener. Lo más probable es que sea muy difícil mantenerlo.
MCH: "Entonces necesitamos algún tipo de alternativa".
mm: - Existe esa opción. Podemos cambiar a núcleos rápidos, abandonando el nuevo sistema de bloqueo. Aún obtendremos un rendimiento de 60 a 80 mil métricas. Al mismo tiempo podemos dejar todo el resto del código. Clickhouse y el sondeo asincrónico funcionarán. Y será fácil de mantener.
MCH: - ¡Asombroso! Sugiero que paremos aquí.
Después de optimizar el lado del servidor, finalmente pudimos lanzar el nuevo código a producción. Abandonamos algunos de los cambios a favor de cambiar a una máquina con núcleos rápidos y minimizar la cantidad de cambios de código. También hemos simplificado la configuración y eliminado las macros en los elementos de datos siempre que sea posible, ya que introducen bloqueos adicionales.
Por ejemplo, abandonar la macro snmp-community, que se encuentra a menudo en la documentación y los ejemplos, en nuestro caso hizo posible acelerar aún más los NVP en aproximadamente 1,5 veces.
Después de dos días en producción.
Eliminar ventanas emergentes del historial de incidentes
MCH: – Misha, llevamos dos días usando el sistema y todo funciona. ¡Pero sólo cuando todo funcione! Habíamos planeado trabajar con la transferencia de un segmento bastante grande de la red y nuevamente comprobamos con nuestras manos qué subía y qué no.
mm: - ¡No puede ser! Revisamos todo 10 veces. El servidor maneja instantáneamente incluso la indisponibilidad total de la red.
MCH: - Sí, lo entiendo todo: servidor, base de datos, top, austat, registros - todo es rápido... Pero miramos la interfaz web, y hay un procesador "en el estante" en el servidor y esto:
mm: - Está vacío. Miremos la web. Descubrimos que en una situación en la que había una gran cantidad de incidentes activos, la mayoría de los widgets en vivo comenzaron a funcionar muy lentamente:
El motivo de esto fue la generación de ventanas emergentes del historial de incidentes que se generan para cada elemento de la lista. Por lo tanto, abandonamos la generación de estas ventanas (comentamos 5 líneas en el código), y esto resolvió nuestros problemas.
El tiempo de carga de los widgets, incluso cuando no están completamente disponibles, se ha reducido de varios minutos a los aceptables 10-15 segundos para nosotros, y el historial aún se puede ver haciendo clic en el tiempo:
Después del trabajo. Hace 2 meses
MCH: - Misha, ¿te vas? Tenemos que hablar.
mm: - No era mi intención. ¿Algo con Zabbix otra vez?
MCH: - ¡No, relájate! Solo quería decir: todo funciona, ¡gracias! Tengo una cerveza.
Zabbix es eficiente
Zabbix es un sistema y una función bastante universal y rico. Se puede utilizar para instalaciones pequeñas listas para usar, pero a medida que crecen las necesidades, debe optimizarse. Para almacenar un archivo grande de métricas, utilice un almacenamiento adecuado:
- puede utilizar herramientas integradas en forma de integración con Elasticsearch o cargar el historial en archivos de texto (disponible a partir de la versión XNUMX);
- Puedes aprovechar nuestra experiencia e integración con Clickhouse.
Para aumentar drásticamente la velocidad de recopilación de métricas, recójalas utilizando métodos asincrónicos y transmítalas a través de la interfaz Trapper al servidor Zabbix; o puede usar un parche para hacer que los encuestadores de Zabbix sean asincrónicos.
Zabbix está escrito en C y es bastante eficiente. Resolver varios cuellos de botella arquitectónicos permite aumentar aún más su rendimiento y, según nuestra experiencia, obtener más de 100 mil métricas en una máquina de un solo procesador.
El mismo parche de Zabbix
mm: – Quiero añadir un par de puntos. Se proporciona el informe actual completo, todas las pruebas y los números para la configuración que utilizamos. Ahora estamos tomando aproximadamente 20 mil métricas por segundo. Si está tratando de comprender si esto funcionará para usted, puede comparar. Lo que se discutió hoy se publica en GitHub en forma de parche:
El parche incluye:
- integración total con Clickhouse (tanto el servidor Zabbix como el frontend);
- resolver problemas con el administrador del preprocesador;
- sondeo asincrónico.
El parche es compatible con todas las versiones 4, incluida lts. Lo más probable es que con cambios mínimos funcione en la versión 3.4.
Gracias por su atención.
preguntas
Pregunta del público (en adelante – A): – ¡Buenas tardes! Por favor, dígame, ¿tiene planes para una interacción intensiva con el equipo de Zabbix o con ellos con usted, para que esto no sea un parche, sino un comportamiento normal de Zabbix?
mm: – Sí, definitivamente realizaremos algunos de los cambios. Algo pasará, algo quedará en el parche.
A: – ¡Muchas gracias por el excelente informe! Por favor, dígame, después de aplicar el parche, el soporte de Zabbix permanecerá y cómo continuar actualizando a versiones superiores. ¿Será posible actualizar Zabbix después de su parche a 4.2, 5.0?
mm: – No puedo decir nada sobre el apoyo. Si yo fuera el soporte técnico de Zabbix, probablemente diría que no, porque este es el código de otra persona. En cuanto al código base 4.2, nuestra posición es: "Avanzaremos con el tiempo y nos actualizaremos en la próxima versión". Por lo tanto, desde hace algún tiempo publicaremos un parche para versiones actualizadas. Ya lo dije en el informe: el número de cambios con las versiones es todavía bastante pequeño. Creo que la transición del 3.4 al 4 nos llevó unos 15 minutos, algo cambió ahí, pero no muy importante.
A: – Entonces, ¿planea respaldar su parche y puede instalarlo de manera segura en producción y recibir actualizaciones de alguna manera en el futuro?
mm: – Lo recomendamos encarecidamente. Esto nos resuelve muchos problemas.
MCH: – Una vez más, me gustaría llamar la atención sobre el hecho de que los cambios que no afectan a la arquitectura y no afectan al bloqueo o las colas son modulares, están en módulos separados. Incluso con cambios menores puedes mantenerlos con bastante facilidad.
mm: – Si está interesado en los detalles, “Clickhouse” utiliza la llamada biblioteca histórica. Está desatado: es una copia del soporte de Elastics, es decir, es configurable. Las encuestas sólo cambian a los encuestadores. Creemos que esto funcionará durante mucho tiempo.
A: - Muchas gracias. Dime, ¿hay alguna documentación de los cambios realizados?
mm: – La documentación es un parche. Evidentemente, con la introducción de Clickhouse, con la introducción de nuevos tipos de encuestadores, surgen nuevas opciones de configuración. El enlace de la última diapositiva tiene una breve descripción de cómo usarlo.
Acerca de reemplazar fping con nmap
A: – ¿Cómo implementaste finalmente esto? ¿Puede dar ejemplos específicos: ¿tiene correas y un script externo? ¿Qué termina comprobando una cantidad tan grande de hosts tan rápidamente? ¿Cómo se extraen estos hosts? ¿Necesitamos alimentarlos a nmap de alguna manera, obtenerlos de algún lugar, insertarlos, ejecutar algo?
mm: - Fresco. ¡Una pregunta muy correcta! El punto es este. Modificamos la biblioteca (ICMP ping, parte de Zabbix) para verificaciones ICMP, que indican la cantidad de paquetes: uno (1), y el código intenta usar nmap. Es decir, este es el trabajo interno de Zabbix, que se ha convertido en el trabajo interno del pinger. En consecuencia, no se requiere sincronización ni uso de un trampero. Esto se hizo deliberadamente para dejar el sistema intacto y no tener que lidiar con la sincronización de dos sistemas de bases de datos: qué verificar, cargar a través del sondeador y ¿nuestra carga está rota? Esto es mucho más simple.
A: – ¿Funciona también para proxies?
mm: – Sí, pero no lo comprobamos. El código de sondeo es el mismo tanto en Zabbix como en el servidor. Deberia trabajar. Permítanme enfatizar una vez más: el rendimiento del sistema es tal que no necesitamos un proxy.
MCH: – La respuesta correcta a la pregunta es: “¿Por qué se necesita un proxy con un sistema así?” Sólo por NAT o monitorización a través de algún tipo de canal lento...
A: – Y usas Zabbix como alertor, si entendí correctamente. ¿O se han movido sus gráficos (donde está la capa de archivo) a otro sistema, como Grafana? ¿O no estás utilizando esta funcionalidad?
mm: – Lo enfatizaré una vez más: hemos logrado una integración completa. Estamos vertiendo historia en Clickhouse, pero al mismo tiempo hemos cambiado la interfaz de PHP. La interfaz de PHP va a Clickhouse y realiza todos los gráficos desde allí. Al mismo tiempo, para ser honesto, tenemos una parte que genera datos en otros sistemas de visualización gráfica del mismo Clickhouse, a partir de los mismos datos de Zabbix.
MCH: – En “Grafan” también.
¿Cómo se tomaron las decisiones sobre la asignación de recursos?
A: – Comparte un poco de tu cocina interior. ¿Cómo se decidió que era necesario destinar recursos para un procesamiento serio del producto? Estos son, en general, ciertos riesgos. Y por favor dígame, en el contexto del hecho de que va a admitir nuevas versiones: ¿cómo se justifica esta decisión desde el punto de vista de la gestión?
mm: – Al parecer, no contamos muy bien el drama de la historia. Nos encontramos en una situación en la que había que hacer algo y básicamente optamos por dos equipos paralelos:
- Uno fue lanzar un sistema de monitoreo utilizando nuevos métodos: monitoreo como servicio, un conjunto estándar de soluciones de código abierto que combinamos y luego intentamos cambiar el proceso comercial para trabajar con el nuevo sistema de monitoreo.
- Al mismo tiempo, teníamos un programador entusiasta que estaba haciendo esto (sobre sí mismo). Dio la casualidad de que ganó.
A: – ¿Y cuál es el tamaño del equipo?
MCH: - Ella está frente a ti.
A: – Entonces, como siempre, ¿necesitas un apasionado?
mm: – No sé lo que es un apasionado.
A: - En este caso, aparentemente, tú. Muchas gracias, eres increíble.
mm: Gracias
Acerca de los parches para Zabbix
A: – Para un sistema que utiliza proxies (por ejemplo, en algunos sistemas distribuidos), ¿es posible adaptar y parchear, por ejemplo, los pollers, los proxies y parcialmente el preprocesador del propio Zabbix? y su interacción? ¿Es posible optimizar los desarrollos existentes para un sistema con múltiples proxies?
mm: – Sé que el servidor Zabbix se ensambla mediante un proxy (el código se compila y se obtiene). No hemos probado esto en producción. No estoy seguro de esto, pero creo que el administrador de preprocesador no se usa en el proxy. La tarea del proxy es tomar un conjunto de métricas de Zabbix, fusionarlas (también registra la configuración, la base de datos local) y devolverlas al servidor de Zabbix. El propio servidor realizará el preprocesamiento cuando lo reciba.
El interés en los apoderados es comprensible. Lo comprobaremos. Este es un tema interesante.
A: – La idea era esta: si puedes parchear los encuestadores, puedes parchearlos en el proxy y parchear la interacción con el servidor, y adaptar el preprocesador para estos propósitos solo en el servidor.
mm: – Creo que es aún más sencillo. Usted toma el código, aplica un parche y luego lo configura de la manera que necesita: recopila servidores proxy (por ejemplo, con ODBC) y distribuye el código parcheado entre los sistemas. Cuando sea necesario, recopile un proxy, cuando sea necesario, un servidor.
A: – ¿Lo más probable es que no tengas que parchear adicionalmente la transmisión del proxy al servidor?
MCH: - No, es estándar.
mm: – De hecho, una de las ideas no sonó. Siempre hemos mantenido un equilibrio entre la explosión de ideas y la cantidad de cambios y facilidad de soporte.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com