A próxima conferencia HighLoad++ celebrarase os días 6 e 7 de abril de 2020 en San Petersburgo Detalles e entradas . HighLoad++ Moscow 2018. Salón “Moscova”. 9 de novembro, 15:00 h. Teses e .
* Seguimento - en liña e análise.
* Limitacións básicas da plataforma ZABBIX.
* Solución para escalar o almacenamento de análises.
* Optimización do servidor ZABBIX.
* Optimización da interface de usuario.
* Experiencia operando o sistema con cargas de máis de 40k NVPS.
* Breves conclusións.
Mikhail Makurov (en diante - MM): - Ola a todos!
Maxim Chernetsov (en diante - MCH): - Boas tardes!
MM: – Déixame presentar a Maxim. Max é un enxeñeiro talentoso, o mellor networker que coñezo. Maxim está implicado en redes e servizos, o seu desenvolvemento e funcionamento.
MCH: – E gustaríame falarche de Mikhail. Mikhail é un programador C. Escribiu varias solucións de procesamento de tráfico de alta carga para a nosa empresa. Vivimos e traballamos nos Urais, na cidade dos homes duros Chelyabinsk, na empresa Intersvyaz. A nosa empresa é un provedor de servizos de Internet e televisión por cable para un millón de persoas en 16 cidades.
MM: – E paga a pena dicir que Intersvyaz é moito máis que un provedor, é unha empresa de TI. A maioría das nosas solucións están feitas polo noso departamento de TI.
R: desde servidores que procesan tráfico ata un centro de chamadas e unha aplicación móbil. O departamento de informática conta agora cunhas 80 persoas con competencias moi, moi diversas.
Sobre Zabbix e a súa arquitectura
MCH: – E agora tentarei establecer un rexistro persoal e dicir nun minuto o que é Zabbix (en adiante denominado "Zabbix").
Zabbix sitúase como un sistema de monitorización listo para usar a nivel empresarial. Ten moitas funcións que facilitan a vida: regras de escalada avanzadas, API para integración, agrupación e detección automática de hosts e métricas. Zabbix ten as chamadas ferramentas de escalado: proxies. Zabbix é un sistema de código aberto.
Brevemente sobre arquitectura. Podemos dicir que consta de tres compoñentes:
- Servidor. Escrito en C. Cun procesamento bastante complexo e transferencia de información entre fíos. Nel ten lugar todo o procesamento: dende a recepción ata o gardado na base de datos.
- Todos os datos almacénanse na base de datos. Zabbix admite MySQL, PostreSQL e Oracle.
- A interface web está escrita en PHP. Na maioría dos sistemas vén cun servidor Apache, pero funciona de forma máis eficiente en combinación con nginx + php.
Hoxe gustaríanos contar unha historia da vida da nosa empresa relacionada con Zabbix...
Unha historia da vida da empresa Intersvyaz. Que temos e que necesitamos?
hai 5 ou 6 meses. Un día despois do traballo...
MCH: - Misha, ola! Alégrome de collerte: hai unha conversación. Volvemos a ter problemas coa vixilancia. Durante un accidente importante, todo foi lento e non había información sobre o estado da rede. Desafortunadamente, esta non é a primeira vez que ocorre. Preciso a túa axuda. Fagamos que o noso seguimento funcione en calquera circunstancia!
MM: - Pero sincronicemos primeiro. Hai un par de anos que non miro alí. Polo que recordo, abandonamos Nagios e cambiamos a Zabbix hai uns 8 anos. E agora parece que temos 6 servidores potentes e preto dunha ducia de proxies. Confundo algo?
MCH: - Case. 15 servidores, algúns dos cales son máquinas virtuais. O máis importante é que non nos salva no momento no que máis o necesitamos. Como un accidente: os servidores ralentizan e non podes ver nada. Tentamos optimizar a configuración, pero isto non proporcionou o aumento óptimo do rendemento.
MM: - Está claro. Miraches algo, xa desenterraches algo do diagnóstico?
MCH: – O primeiro que tes que tratar é a base de datos. MySQL cárgase constantemente, almacenando novas métricas, e cando Zabbix comeza a xerar unha morea de eventos, a base de datos entra en exceso durante literalmente unhas horas. Xa vos falei sobre a optimización da configuración, pero literalmente este ano actualizaron o hardware: os servidores teñen máis de cen gigabytes de memoria e matrices de discos en SSD RAID - non ten sentido crecer linealmente a longo prazo. Que facemos?
MM: - Está claro. En xeral, MySQL é unha base de datos LTP. Ao parecer, xa non é axeitado para almacenar un arquivo de métricas do noso tamaño. Imos descubrir.
MCH: - Imos!
Integración de Zabbix e Clickhouse como resultado do hackathon
Despois dun tempo recibimos datos interesantes:
A maior parte do espazo da nosa base de datos estaba ocupado polo arquivo de métricas e menos do 1 % utilizouse para a configuración, os modelos e os axustes. Nese momento, levabamos máis dun ano operando a solución Big data baseada en Clickhouse. A dirección do movemento era obvia para nós. No noso Hackathon de primavera, escribín a integración de Zabbix con Clickhouse para o servidor e a interface. Nese momento, Zabbix xa tiña soporte para ElasticSearch e decidimos comparalos.
Comparación de Clickhouse e Elasticsearch
MM: – A modo de comparación, xeramos a mesma carga que proporciona o servidor Zabbix e analizamos como se comportarían os sistemas. Escribimos datos en lotes de 1000 liñas, usando CURL. Supuxemos de antemán que Clickhouse sería máis eficiente para o perfil de carga que fai Zabbix. Os resultados incluso superaron as nosas expectativas:
Nas mesmas condicións de proba, Clickhouse escribiu tres veces máis datos. Ao mesmo tempo, ambos sistemas consumían de forma moi eficiente (unha pequena cantidade de recursos) ao ler os datos. Pero Elastics requiriu unha gran cantidade de procesador ao gravar:
En total, Clickhouse foi significativamente superior a Elastix en termos de consumo de procesador e velocidade. Ao mesmo tempo, debido á compresión de datos, Clickhouse usa 11 veces menos no disco duro e realiza aproximadamente 30 veces menos operacións de disco:
MCH: - Si, o traballo de Clickhouse co subsistema de discos está implementado de forma moi eficiente. Podes usar enormes discos SATA para bases de datos e obter velocidades de escritura de centos de miles de liñas por segundo. O sistema listo para usar admite a fragmentación, a replicación e é moi sinxelo de configurar. Estamos máis que satisfeitos co seu uso durante todo o ano.
Para optimizar os recursos, pode instalar Clickhouse xunto á súa base de datos principal existente e, así, aforrar moito tempo de CPU e operacións de disco. Movemos o arquivo de métricas aos clústeres de Clickhouse existentes:
Aliviamos tanto a base de datos MySQL principal que puidemos combinala nunha máquina co servidor Zabbix e abandonar o servidor dedicado para MySQL.
Como funcionan as enquisas en Zabbix?
Hai 4 meses
MM: – Pois podemos esquecernos dos problemas coa base?
MCH: - Iso é seguro! Outro problema que debemos resolver é a lenta recollida de datos. Agora todos os nosos 15 servidores proxy están sobrecargados con SNMP e procesos de votación. E non hai outra forma que instalar servidores novos e novos.
MM: - Xenial. Pero primeiro, cóntanos como funcionan as enquisas en Zabbix?
MCH: – En resumo, hai 20 tipos de métricas e unha ducia de formas de obtelas. Zabbix pode recoller datos no modo "solicitude-resposta" ou esperar novos datos a través da "Interface Trapper".
Paga a pena notar que no Zabbix orixinal este método (Trapper) é o máis rápido.
Hai servidores proxy para a distribución de carga:
Os proxies poden realizar as mesmas funcións de recollida que o servidor Zabbix, recibindo tarefas del e enviando as métricas recollidas a través da interface Trapper. Esta é a forma oficialmente recomendada de distribuír a carga. Os proxies tamén son útiles para supervisar a infraestrutura remota que opera a través de NAT ou unha canle lenta:
MM: – Todo está claro coa arquitectura. Temos que mirar as fontes...
Un par de días despois
A historia de como gañou nmap fping
MM: "Creo que desenterrei algo".
MCH: - Dime!
MM: – Descubrín que ao comprobar a dispoñibilidade, Zabbix comproba un máximo de 128 hosts á vez. Tentei aumentar este número a 500 e eliminar o intervalo entre paquetes no seu ping (ping) - isto duplicou o rendemento. Pero gustaríame números máis grandes.
MCH: – Na miña práctica, ás veces teño que comprobar a dispoñibilidade de miles de hosts, e nunca vin nada máis rápido que nmap para iso. Estou seguro de que este é o camiño máis rápido. Imos probalo! Necesitamos aumentar significativamente o número de hosts por iteración.
MM: – Comprobar máis de cincocentos? 600?
MCH: - Polo menos un par de miles.
MM: - OK. O máis importante que quería dicir é que descubrín que a maioría das enquisas en Zabbix fanse de forma sincronizada. Definitivamente necesitamos cambialo ao modo asíncrono. Entón podemos aumentar drasticamente o número de métricas recollidas polos enquisadores, especialmente se aumentamos o número de métricas por iteración.
MCH: - Xenial! E cando?
MM: –Como de costume, onte.
MCH: – Comparamos as dúas versións de fping e nmap:
Nunha gran cantidade de servidores, agardaba que nmap fose ata cinco veces máis eficaz. Dado que nmap só verifica a dispoñibilidade e o tempo de resposta, movemos o cálculo das perdas aos disparadores e reducimos significativamente os intervalos de verificación de dispoñibilidade. Descubrimos que o número óptimo de anfitrións para nmap é de aproximadamente 4 mil por iteración. Nmap permitiunos reducir o custo da CPU das comprobacións de dispoñibilidade en tres veces e reducir o intervalo de 120 segundos a 10.
Optimización da votación
MM: “Entón comezamos a facer enquisas. Interesábanos principalmente a detección e os axentes SNMP. En Zabbix, as votacións realízanse de forma sincronizada e tomáronse medidas especiais para aumentar a eficiencia do sistema. No modo síncrono, a indisponibilidade do host provoca unha degradación significativa da votación. Hai todo un sistema de estados, hai procesos especiais: os chamados enquisadores inalcanzables, que só funcionan con hosts inalcanzables:
Este é un comentario que demostra a matriz de estado, toda a complexidade do sistema de transicións que son necesarias para que o sistema siga sendo efectivo. Ademais, a votación síncrona é bastante lenta:
É por iso que miles de sondaxes en decenas de proxies non puideron recoller a cantidade necesaria de datos para nós. A implementación asíncrona resolveu non só os problemas co número de fíos, senón que tamén simplificou significativamente o sistema de estado dos anfitrións non dispoñibles, porque para calquera número verificado nunha iteración de votación, o tempo de espera máximo foi de 1 tempo de espera:
Ademais, modificamos e melloramos o sistema de votación para as solicitudes SNMP. O feito é que a maioría da xente non pode responder a varias solicitudes SNMP ao mesmo tempo. Polo tanto, fixemos un modo híbrido, cando a consulta SNMP do mesmo host se realiza de forma asíncrona:
Isto faise para todo o paquete de hosts. En última instancia, este modo non é máis lento que un completamente asíncrono, xa que o sondeo de cento e medio de valores SNMP aínda é moito máis rápido que 1 tempo de espera.
Os nosos experimentos demostraron que o número óptimo de solicitudes nunha iteración é de aproximadamente 8 mil con sondaxes SNMP. En total, a transición ao modo asíncrono permitiunos acelerar o rendemento das enquisas en 200 veces, varios centos de veces.
MCH: – As optimizacións de enquisas resultantes mostraron que non só podemos desfacernos de todos os proxies, senón que tamén podemos reducir os intervalos de moitas comprobacións e que os proxies xa non serán necesarios como forma de compartir a carga.
Hai uns tres meses
Cambia a arquitectura - aumenta a carga!
MM: - Pois, Max, é hora de ser produtivo? Necesito un servidor potente e un bo enxeñeiro.
MCH: - Vale, planeámolo. Xa é hora de pasar do punto morto de 5 mil métricas por segundo.
Mañá despois da actualización
MCH: - Misha, actualizámonos, pero pola mañá retrocedemos... Adiviñades que velocidade conseguimos?
MM: – 20 mil máximo.
MCH: - Si, 25! Por desgraza, estamos ben onde comezamos.
MM: - Por que? Fixeches algún diagnóstico?
MCH: - Si, claro! Aquí, por exemplo, tes un top interesante:
MM: -Vexamos. Vexo que probamos un gran número de fíos de votación:
Pero ao mesmo tempo non podían reciclar o sistema nin á metade:
E o rendemento xeral é bastante pequeno, preto de 4 mil métricas por segundo:
Hai algo máis?
MCH: – Si, traza dun dos enquisadores:
MM: – Aquí podes ver claramente que o proceso de votación está á espera de “semáforos”. Estes son os bloqueos:
MCH: - Escuro.
MM: – Mira, isto é semellante a unha situación na que unha morea de fíos intentan traballar con recursos cos que só un pode traballar á vez. Despois o único que poden facer é compartir este recurso ao longo do tempo:
E o rendemento total de traballar con tal recurso está limitado pola velocidade dun núcleo:
Hai dúas formas de resolver este problema.
Actualiza o hardware da máquina, cambia a núcleos máis rápidos:
Ou cambia a arquitectura e ao mesmo tempo cambia a carga:
MCH: – Por certo, na máquina de proba usaremos menos núcleos que na de combate, pero son 1,5 veces máis rápidos en frecuencia por núcleo!
MM: - Limpo? Debes mirar o código do servidor.
Ruta de datos no servidor Zabbix
MCH: – Para descubrilo, comezamos a analizar como se transfiren os datos dentro do servidor Zabbix:
Unha imaxe xenial, non? Repasámolo paso a paso para que quede máis ou menos claro. Existen fíos e servizos responsables da recollida de datos:
Transmiten as métricas recollidas a través dun socket ao xestor do preprocesador, onde se gardan nunha cola:
O "xestor do preprocesador" transmite datos aos seus traballadores, que executan instrucións de preprocesamento e os devolven a través do mesmo socket:
Despois disto, o xestor do preprocesador gárdaos na caché do historial:
A partir de aí son tomadas polos sinkers do historial, que realizan moitas funcións: por exemplo, calcular disparadores, encher a caché de valores e, o máis importante, gardar métricas no almacenamento do historial. En xeral, o proceso é complexo e moi confuso.
MM: – O primeiro que vimos foi que a maioría dos fíos compiten pola chamada “caché de configuración” (a área de memoria onde se almacenan todas as configuracións do servidor). Os fíos encargados de recoller datos fan especialmente moitos bloqueos:
...xa que a configuración almacena non só métricas cos seus parámetros, senón tamén filas das que os enquisadores toman información sobre que facer a continuación. Cando hai moitos sondaxes e un bloquea a configuración, os demais esperan solicitudes:
Os enquisadores non deben entrar en conflito
Polo tanto, o primeiro que fixemos foi dividir a cola en 4 partes e permitir que os enquisadores bloqueasen estas filas, estas partes ao mesmo tempo, en condicións de seguridade:
Isto eliminou a competencia pola caché de configuración e a velocidade dos sondeadores aumentou significativamente. Pero entón atopamos o feito de que o xestor do preprocesador comezou a acumular unha cola de traballos:
O xestor do preprocesador debe poder priorizar
Isto ocorreu nos casos nos que carecía de rendemento. Despois o único que podía facer era acumular solicitudes dos procesos de recollida de datos e sumar o seu búfer ata que consumía toda a memoria e fallaba:
Para solucionar este problema, engadimos un segundo socket dedicado especificamente aos traballadores:
Así, o xestor do preprocesador tivo a oportunidade de priorizar o seu traballo e, se o búfer crece, a tarefa é ralentizar a eliminación, dándolle aos traballadores a oportunidade de aproveitar este búfer:
Despois descubrimos que un dos motivos da ralentización eran os propios traballadores, posto que competiban por un recurso que carecía de importancia para o seu traballo. Documentamos este problema como unha corrección de erros e xa foi resolto nas novas versións de Zabbix:
Aumentamos o número de tomas - obtemos o resultado
Ademais, o propio xestor do preprocesador converteuse nun pescozo de botella, xa que é un fío. Apoiouse na velocidade do núcleo, dando unha velocidade máxima duns 70 mil métricas por segundo:
Polo tanto, fixemos catro traballadores, con catro xogos de enchufes:
E isto permitiunos aumentar a velocidade ata aproximadamente 130 mil métricas:
A non linealidade do crecemento explícase polo feito de que apareceu a competencia polo caché histórico. 4 xestores de preprocesadores e sinkers da historia competiron por el. Neste punto, estabamos recibindo aproximadamente 130 mil métricas por segundo na máquina de proba, utilizándoo por aproximadamente o 95% do procesador:
Hai uns 2,5 meses
A negativa da comunidade snmp aumentou os NVP unha vez e media
MM: – Max, necesito un coche de proba novo! Xa non encaixamos no actual.
MCH: - Que tes agora?
MM: – Agora – 130 NVP e un procesador listo para estantes.
MCH: - Vaia! Genial! Espera, teño dúas preguntas. Segundo os meus cálculos, a nosa necesidade é de aproximadamente 15-20 mil métricas por segundo. Por que necesitamos máis?
MM: "Quero rematar o traballo". Gustaríame ver canto podemos sacar deste sistema.
MCH: - Pero...
MM: "Pero é inútil para os negocios".
MCH: - Está claro. E a segunda pregunta: podemos soportar o que temos agora sós, sen a axuda dun programador?
MM: - Non creo. Cambiar como funciona a caché de configuración é un problema. Afecta aos cambios na maioría dos fíos e é bastante difícil de manter. O máis probable é que sexa moi difícil mantelo.
MCH: "Entón necesitamos algún tipo de alternativa".
MM: -Hai tal opción. Podemos cambiar aos núcleos rápidos, mentres abandonamos o novo sistema de bloqueo. Aínda teremos un rendemento de 60-80 mil métricas. Ao mesmo tempo, podemos deixar todo o resto do código. Funcionarán as enquisas de clic e asíncronas. E será fácil de manter.
MCH: - Incrible! Suxiro que paremos aquí.
Despois de optimizar o lado do servidor, por fin puidemos lanzar o novo código á produción. Abandonamos algúns dos cambios a favor de cambiar a unha máquina con núcleos rápidos e minimizar o número de cambios de código. Tamén simplificamos a configuración e eliminamos as macros nos elementos de datos cando foi posible, xa que introducen bloqueo adicional.
Por exemplo, o abandono da macro snmp-community, que adoita atoparse na documentación e nos exemplos, permitiu no noso caso acelerar aínda máis as NVP unhas 1,5 veces.
Despois de dous días en produción
Eliminando ventás emerxentes do historial de incidentes
MCH: – Misha, levamos dous días usando o sistema e todo funciona. Pero só cando todo funciona! Tiñamos un traballo planificado coa transferencia dun segmento bastante grande da rede, e volvemos comprobar coas nosas mans o que subía e o que non.
MM: - Non pode ser! Comprobamos todo 10 veces. O servidor xestiona ata a completa indisponibilidade da rede ao instante.
MCH: - Si, entendo todo: servidor, base de datos, top, austat, rexistros - todo é rápido... Pero miramos a interface web, e hai un procesador "no estante" no servidor e isto:
MM: - Está claro. Vexamos a web. Descubrimos que nunha situación na que había un gran número de incidentes activos, a maioría dos widgets en directo comezaron a funcionar moi lentamente:
O motivo disto foi a xeración de ventás emerxentes de historial de incidentes que se xeran para cada elemento da lista. Polo tanto, abandonamos a xeración destas fiestras (comentadas 5 liñas no código), e isto resolveu os nosos problemas.
O tempo de carga dos widgets, aínda que non estean completamente dispoñibles, reduciuse de varios minutos aos 10-15 segundos aceptables para nós, e aínda se pode ver o historial facendo clic na hora:
Despois do traballo. hai 2 meses
MCH: - Misha, marchas? Temos que falar.
MM: - Non tiña intención. Algo con Zabbix de novo?
MCH: - Non, relaxa! Só quería dicir: todo funciona, grazas! Teño unha cervexa.
Zabbix é eficiente
Zabbix é un sistema e función bastante universal e rico. Pódese usar para pequenas instalacións fóra da caixa, pero a medida que crecen as necesidades, hai que optimizalo. Para almacenar un gran arquivo de métricas, use un almacenamento axeitado:
- pode utilizar ferramentas integradas en forma de integración con Elasticsearch ou cargando o historial de ficheiros de texto (dispoñible desde a versión XNUMX);
- Podes aproveitar a nosa experiencia e integración con Clickhouse.
Para aumentar drasticamente a velocidade de recollida de métricas, recólleas mediante métodos asíncronos e transmíteas a través da interface trapper ao servidor Zabbix; ou pode usar un parche para facer que os sondeadores de Zabbix sexan asíncronos.
Zabbix está escrito en C e é bastante eficiente. Resolver varios colos de botella arquitectónicos permítelle aumentar aínda máis o seu rendemento e, segundo a nosa experiencia, obter máis de 100 mil métricas nunha máquina dun só procesador.
O mesmo parche de Zabbix
MM: – Quero engadir un par de puntos. O informe actual completo, todas as probas, os números son indicados para a configuración que usamos. Agora estamos tomando aproximadamente 20 mil métricas por segundo. Se estás tentando entender se isto funcionará para ti, podes comparar. O que se falou hoxe publícase en GitHub en forma de parche:
O parche inclúe:
- integración total con Clickhouse (servidor e frontend de Zabbix);
- resolver problemas co xestor do preprocesador;
- votación asíncrona.
O parche é compatible con todas as versións 4, incluíndo lts. O máis probable é que con cambios mínimos funcione na versión 3.4.
Grazas pola súa atención.
preguntas
Pregunta do público (en diante – A): – Boas tardes! Por favor, dime, tes plans de interacción intensiva co equipo de Zabbix ou con eles contigo, para que este non sexa un parche, senón o comportamento normal de Zabbix?
MM: – Si, seguro que cometeremos algúns dos cambios. Algo pasará, algo permanecerá no parche.
R: - Moitas grazas polo excelente informe! Dígame, despois de aplicar o parche, o soporte de Zabbix permanecerá e como seguir actualizando a versións superiores? Será posible actualizar Zabbix despois do parche a 4.2, 5.0?
MM: - Non podo dicir nada sobre o apoio. Se fose soporte técnico de Zabbix, probablemente diría que non, porque este é o código doutra persoa. En canto á base de código 4.2, a nosa posición é: "Moviarémonos co tempo e actualizaremos a próxima versión". Polo tanto, durante algún tempo publicaremos un parche para as versións actualizadas. Xa o dixen no informe: o número de cambios con versións aínda é bastante pequeno. Creo que a transición do 3.4 ao 4 levounos uns 15 minutos.Algo cambiou alí, pero non é moi importante.
R: – Entón, pensas apoiar o teu parche e podes instalalo con seguridade en produción e recibir actualizacións dalgún xeito no futuro?
MM: -Recomendámolo encarecidamente. Isto resolvemos moitos problemas para nós.
MCH: – Unha vez máis, gustaríame chamar a atención sobre que os cambios que non se refiren á arquitectura e non se refiren ao bloqueo ou ás colas son modulares, están en módulos separados. Mesmo con pequenos cambios pode mantelos con bastante facilidade.
MM: – Se estás interesado nos detalles, entón "Clickhouse" usa a chamada biblioteca de historia. Está desvinculado: é unha copia do soporte Elastics, é dicir, é configurable. As enquisas só cambian os enquisadores. Cremos que isto funcionará durante moito tempo.
R: - Moitas grazas. Dígame, hai documentación dos cambios realizados?
MM: – A documentación é un parche. Obviamente, coa introdución de Clickhouse, coa introdución de novos tipos de sondeadores, xorden novas opcións de configuración. A ligazón da última diapositiva ten unha breve descrición de como usalo.
Sobre a substitución de fping por nmap
R: -¿Como o fixeches finalmente? Podes poñer exemplos concretos: tes tiradores e un guión externo? Que acaba comprobando un número tan grande de hosts tan rápido? Como minas estes hosts? Necesitamos alimentalos para nmap dalgún xeito, sacalos de algún lugar, poñelos, executar algo?...
MM: - Xenial. Unha pregunta moi correcta! A cuestión é esta. Modificamos a biblioteca (ping ICMP, parte de Zabbix) para as comprobacións ICMP, que indican o número de paquetes: un (1) e o código tenta usar nmap. É dicir, este é o traballo interno de Zabbix, que se converteu no traballo interno do pinger. En consecuencia, non se require sincronización nin uso dun trampero. Isto fíxose deliberadamente para deixar o sistema intacto e non ter que lidiar coa sincronización de dous sistemas de bases de datos: que comprobar, cargar a través do sondeador e a nosa carga está rota?.. Isto é moito máis sinxelo.
R: – Tamén funciona para proxies?
MM: – Si, pero non o comprobamos. O código de votación é o mesmo tanto en Zabbix como no servidor. Debería funcionar. Permítanme subliñar unha vez máis: o rendemento do sistema é tal que non necesitamos un proxy.
MCH: – A resposta correcta á pregunta é: "Por que necesitas un proxy con tal sistema?" Só por NAT ou monitorización a través dalgún tipo de canle lento...
R: – E usas Zabbix como alertor, se entendo ben. Ou movéronse os teus gráficos (onde está a capa de arquivo) a outro sistema, como Grafana? Ou non está a usar esta función?
MM: – Vou subliñar unha vez máis: conseguimos a integración total. Estamos botando historia en Clickhouse, pero ao mesmo tempo cambiamos a interface php. O frontend de Php vai a Clickhouse e fai todos os gráficos desde alí. Ao mesmo tempo, para ser honesto, temos unha parte que constrúe datos noutros sistemas de visualización gráfica do mesmo Clickhouse, a partir dos mesmos datos de Zabbix.
MCH: – En “Grafan” tamén.
Como se tomaron as decisións sobre a asignación de recursos?
R: – Comparte un pouco da túa cociña interior. Como se tomou a decisión de que era necesario destinar recursos para un procesado serio do produto? Estes son, en xeral, certos riscos. E, por favor, dime, no contexto de que vas apoiar novas versións: como se xustifica esta decisión dende o punto de vista da xestión?
MM: – Polo visto, non contamos moi ben o drama da historia. Atopámonos nunha situación na que había que facer algo, e fundamentalmente fomos con dous equipos paralelos:
- Un deles foi o lanzamento dun sistema de monitorización mediante novos métodos: monitoring as a service, un conxunto estándar de solucións de código aberto que combinamos e despois tentamos cambiar o proceso de negocio para poder traballar co novo sistema de monitorización.
- Ao mesmo tempo, tiñamos un programador entusiasta que facía isto (sobre si mesmo). Aconteceu que gañou.
R: – E cal é o tamaño do equipo?
MCH: - Ela está diante de ti.
R: – Entón, como sempre, necesitas un apaixonado?
MM: – Non sei o que é un apaixonado.
R: - Neste caso, ao parecer, ti. Moitas grazas, eres xenial.
MM: - Grazas.
Sobre os parches para Zabbix
R: – Para un sistema que usa proxies (por exemplo, nalgúns sistemas distribuídos), é posible adaptar e parchear, por exemplo, pollers, proxies e parcialmente o preprocesador do propio Zabbix; e a súa interacción? É posible optimizar os desenvolvementos existentes para un sistema con múltiples proxies?
MM: – Sei que o servidor Zabbix está montado mediante un proxy (o código é compilado e obtido). Non probamos isto na produción. Non estou seguro disto, pero creo que o xestor do preprocesador non se usa no proxy. A tarefa do proxy é tomar un conxunto de métricas de Zabbix, fusionalas (tamén rexistra a configuración, a base de datos local) e devolvelas ao servidor Zabbix. O propio servidor fará entón o preprocesamento cando o reciba.
O interese polos proxies é comprensible. Comprobarémolo. Este é un tema interesante.
R: – A idea era esta: se podes parchear os pollers, podes parchealos no proxy e parchear a interacción co servidor, e adaptar o preprocesador para estes fins só no servidor.
MM: -Creo que é aínda máis sinxelo. Colles o código, aplicas un parche e, a continuación, configúrao do xeito que necesites: recolles servidores proxy (por exemplo, con ODBC) e distribúes o código parcheado entre os sistemas. Cando sexa necesario - recolle un proxy, cando sexa necesario - un servidor.
R: - O máis probable é que non teña que parchear a transmisión proxy ao servidor adicionalmente?
MCH: - Non, é estándar.
MM: – De feito, unha das ideas non soou. Sempre mantivemos un equilibrio entre a explosión de ideas e a cantidade de cambios e facilidade de apoio.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com