A próxima conferência HighLoad++ será realizada nos dias 6 e 7 de abril de 2020 em São Petersburgo Detalhes e ingressos . HighLoad++ Moscou 2018. Salão “Moscou”. 9 de novembro, 15h. Teses e .
* Monitoramento - online e analítico.
* Limitações básicas da plataforma ZABBIX.
* Solução para dimensionar o armazenamento analítico.
* Otimização do servidor ZABBIX.
* Otimização da IU.
* Experiência operando o sistema sob cargas de mais de 40k NVPS.
* Breves conclusões.
Mikhail Makurov (doravante – MM): - Olá a todos!
Maxim Chernetsov (doravante – MCH): - Boa tarde!
MILÍMETROS: – Deixe-me apresentar Maxim. Max é um engenheiro talentoso, o melhor networker que conheço. A Maxim está envolvida em redes e serviços, no seu desenvolvimento e operação.
MCH: – E eu gostaria de falar sobre Mikhail. Mikhail é um desenvolvedor C. Ele escreveu diversas soluções de processamento de tráfego de alta carga para nossa empresa. Vivemos e trabalhamos nos Urais, na cidade dos durões de Chelyabinsk, na empresa Intersvyaz. Nossa empresa é provedora de serviços de Internet e televisão a cabo para um milhão de pessoas em 16 cidades.
MILÍMETROS: – E vale dizer que a Intersvyaz é muito mais que um fornecedor, é uma empresa de TI. A maioria das nossas soluções são feitas pelo nosso departamento de TI.
A: desde servidores que processam tráfego até uma central de atendimento e aplicativos móveis. O departamento de TI conta agora com cerca de 80 pessoas com competências muito diversas.
Sobre o Zabbix e sua arquitetura
MCH: – E agora vou tentar estabelecer um recorde pessoal e dizer em um minuto o que é Zabbix (doravante denominado “Zabbix”).
O Zabbix se posiciona como um sistema de monitoramento pronto para uso de nível empresarial. Possui muitos recursos que facilitam a vida: regras avançadas de escalonamento, API para integração, agrupamento e detecção automática de hosts e métricas. O Zabbix possui as chamadas ferramentas de escalonamento - proxies. Zabbix é um sistema de código aberto.
Resumidamente sobre arquitetura. Podemos dizer que consiste em três componentes:
- Servidor. Escrito em C. Com processamento e transferência de informações bastante complexos entre threads. Nele ocorre todo o processamento: desde o recebimento até o salvamento no banco de dados.
- Todos os dados são armazenados no banco de dados. Zabbix suporta MySQL, PostreSQL e Oracle.
- A interface web é escrita em PHP. Na maioria dos sistemas ele vem com um servidor Apache, mas funciona de forma mais eficiente em combinação com nginx + php.
Hoje gostaríamos de contar uma história da vida da nossa empresa relacionada ao Zabbix...
Uma história da vida da empresa Intersvyaz. O que temos e do que precisamos?
5 ou 6 meses atrás. Um dia depois do trabalho...
MCH: - Misha, olá! Estou feliz por ter conseguido pegar você - há uma conversa. Novamente tivemos problemas com o monitoramento. Durante um acidente grave, tudo ficou lento e não havia informações sobre o estado da rede. Infelizmente, esta não é a primeira vez que isso acontece. Eu preciso de sua ajuda. Vamos fazer nosso monitoramento funcionar em qualquer circunstância!
MILÍMETROS: - Mas vamos sincronizar primeiro. Faz alguns anos que não olho lá. Pelo que me lembro, abandonamos o Nagios e mudamos para o Zabbix há cerca de 8 anos. E agora parece que temos 6 servidores poderosos e cerca de uma dúzia de proxies. Estou confundindo alguma coisa?
MCH: - Quase. 15 servidores, alguns dos quais são máquinas virtuais. O mais importante é que não nos salve no momento em que mais precisamos. Como um acidente - os servidores ficam lentos e você não consegue ver nada. Tentamos otimizar a configuração, mas isso não proporcionou o aumento ideal de desempenho.
MILÍMETROS: - Está claro. Você olhou alguma coisa, já descobriu alguma coisa no diagnóstico?
MCH: – A primeira coisa que você precisa lidar é o banco de dados. O MySQL é constantemente carregado, armazenando novas métricas, e quando o Zabbix começa a gerar vários eventos, o banco de dados fica sobrecarregado por literalmente algumas horas. Já falei sobre como otimizar a configuração, mas literalmente este ano eles atualizaram o hardware: os servidores têm mais de cem gigabytes de memória e matrizes de disco em SSDs RAID - não adianta crescer linearmente no longo prazo. O que nós fazemos?
MILÍMETROS: - Está claro. Em geral, MySQL é um banco de dados LTP. Aparentemente, não é mais adequado para armazenar um arquivo de métricas do nosso tamanho. Vamos descobrir.
MCH: - Vamos!
Integração do Zabbix e Clickhouse como resultado do hackathon
Depois de algum tempo recebemos dados interessantes:
A maior parte do espaço em nosso banco de dados foi ocupada pelo arquivo de métricas e menos de 1% foi usado para configurações, modelos e configurações. Naquela época, já operamos a solução de Big data baseada em Clickhouse há mais de um ano. A direção do movimento era óbvia para nós. Em nosso Hackathon de primavera, escrevi a integração do Zabbix com Clickhouse para servidor e frontend. Naquela época o Zabbix já tinha suporte para ElasticSearch e decidimos compará-los.
Comparação de Clickhouse e Elasticsearch
MILÍMETROS: – Para efeito de comparação, geramos a mesma carga que o servidor Zabbix fornece e analisamos como os sistemas se comportariam. Escrevemos dados em lotes de 1000 linhas, usando CURL. Presumimos antecipadamente que o Clickhouse seria mais eficiente para o perfil de carga que o Zabbix faz. Os resultados até superaram nossas expectativas:
Nas mesmas condições de teste, Clickhouse gravou três vezes mais dados. Ao mesmo tempo, ambos os sistemas consumiram de forma muito eficiente (uma pequena quantidade de recursos) na leitura de dados. Mas o Elastics exigia uma grande quantidade de processador durante a gravação:
No total, Clickhouse foi significativamente superior ao Elastix em termos de consumo e velocidade do processador. Ao mesmo tempo, devido à compactação de dados, Clickhouse usa 11 vezes menos disco rígido e executa aproximadamente 30 vezes menos operações de disco:
MCH: – Sim, o trabalho da Clickhouse com o subsistema de disco é implementado de forma muito eficiente. Você pode usar discos SATA enormes para bancos de dados e obter velocidades de gravação de centenas de milhares de linhas por segundo. O sistema pronto para uso suporta fragmentação, replicação e é muito fácil de configurar. Estamos mais do que satisfeitos com a sua utilização ao longo do ano.
Para otimizar recursos, você pode instalar o Clickhouse próximo ao seu banco de dados principal existente e, assim, economizar muito tempo de CPU e operações de disco. Movemos o arquivo de métricas para clusters Clickhouse existentes:
Aliviamos tanto o banco de dados MySQL principal que pudemos combiná-lo em uma máquina com o servidor Zabbix e abandonar o servidor dedicado para MySQL.
Como funciona a votação no Zabbix?
4 meses atrás
MILÍMETROS: – Bem, podemos esquecer os problemas com a base?
MCH: - Isso é certeza! Outro problema que precisamos resolver é a lenta coleta de dados. Agora todos os nossos 15 servidores proxy estão sobrecarregados com SNMP e processos de pesquisa. E não há outra maneira a não ser instalar cada vez mais servidores.
MILÍMETROS: - Ótimo. Mas primeiro, conte-nos como funciona a votação no Zabbix?
MCH: – Resumindo, existem 20 tipos de métricas e uma dezena de formas de obtê-las. O Zabbix pode coletar dados no modo “solicitação-resposta” ou aguardar novos dados através da “Interface Trapper”.
Vale ressaltar que no Zabbix original esse método (Trapper) é o mais rápido.
Existem servidores proxy para distribuição de carga:
Os proxies podem realizar as mesmas funções de coleta do servidor Zabbix, recebendo tarefas dele e enviando as métricas coletadas através da interface do Trapper. Esta é a forma oficialmente recomendada de distribuir a carga. Os proxies também são úteis para monitorar infraestruturas remotas operando através de NAT ou de um canal lento:
MILÍMETROS: – Tudo fica claro com a arquitetura. Precisamos olhar as fontes...
Alguns dias depois
A história de como o nmap fping venceu
MILÍMETROS: “Acho que desenterrei alguma coisa.”
MCH: - Diga-me!
MILÍMETROS: – Descobri que ao verificar a disponibilidade, o Zabbix verifica no máximo 128 hosts por vez. Tentei aumentar esse número para 500 e remover o intervalo entre pacotes no ping (ping) - isso dobrou o desempenho. Mas eu gostaria de números maiores.
MCH: – Na minha prática, às vezes tenho que verificar a disponibilidade de milhares de hosts, e nunca vi nada mais rápido que o nmap para isso. Tenho certeza que este é o caminho mais rápido. Vamos tentar! Precisamos aumentar significativamente o número de hosts por iteração.
MILÍMETROS: – Checar mais de quinhentos? 600?
MCH: - Pelo menos alguns milhares.
MILÍMETROS: - OK. A coisa mais importante que eu queria dizer é que descobri que a maioria das pesquisas no Zabbix são feitas de forma síncrona. Definitivamente precisamos alterá-lo para o modo assíncrono. Então poderemos aumentar drasticamente o número de métricas coletadas pelos pesquisadores, especialmente se aumentarmos o número de métricas por iteração.
MCH: - Ótimo! E quando?
MILÍMETROS: – Como sempre, ontem.
MCH: – Comparamos as duas versões do fping e do nmap:
Em um grande número de hosts, esperava-se que o nmap fosse até cinco vezes mais eficaz. Como o nmap verifica apenas a disponibilidade e o tempo de resposta, transferimos o cálculo de perdas para gatilhos e reduzimos significativamente os intervalos de verificação de disponibilidade. Descobrimos que o número ideal de hosts para o nmap é de cerca de 4 mil por iteração. O Nmap nos permitiu reduzir o custo da CPU nas verificações de disponibilidade em três vezes e reduzir o intervalo de 120 segundos para 10.
Otimização de votação
MILÍMETROS: “Então começamos a fazer pesquisas. Estávamos interessados principalmente em detecção e agentes SNMP. No Zabbix, a votação é feita de forma síncrona e medidas especiais foram tomadas para aumentar a eficiência do sistema. No modo síncrono, a indisponibilidade do host causa degradação significativa da pesquisa. Existe todo um sistema de estados, existem processos especiais - os chamados pollers inacessíveis, que funcionam apenas com hosts inacessíveis:
Este é um comentário que demonstra a matriz estadual, toda a complexidade do sistema de transições que são necessárias para que o sistema permaneça eficaz. Além disso, a pesquisa síncrona em si é bastante lenta:
É por isso que milhares de fluxos de pesquisas em dezenas de proxies não conseguiram coletar a quantidade necessária de dados para nós. A implementação assíncrona resolveu não apenas os problemas com o número de threads, mas também simplificou significativamente o sistema de estado de hosts indisponíveis, pois para qualquer número verificado em uma iteração de polling, o tempo máximo de espera foi de 1 timeout:
Além disso, modificamos e melhoramos o sistema de polling para solicitações SNMP. O fato é que a maioria das pessoas não consegue responder a múltiplas solicitações SNMP ao mesmo tempo. Portanto, fizemos um modo híbrido, quando a polling SNMP do mesmo host é feita de forma assíncrona:
Isso é feito para todo o pacote de hosts. Em última análise, esse modo não é mais lento do que um modo completamente assíncrono, já que a pesquisa de uma centena e meia de valores SNMP ainda é muito mais rápida que 1 tempo limite.
Nossos experimentos mostraram que o número ideal de solicitações em uma iteração é de aproximadamente 8 mil com polling SNMP. No total, a transição para o modo assíncrono permitiu acelerar o desempenho da pesquisa em 200 vezes, várias centenas de vezes.
MCH: – As otimizações de pesquisa resultantes mostraram que podemos não apenas nos livrar de todos os proxies, mas também reduzir os intervalos para muitas verificações, e os proxies não serão mais necessários como forma de compartilhar a carga.
Cerca de três meses atrás
Mude a arquitetura - aumente a carga!
MILÍMETROS: - Bem, Max, é hora de ser produtivo? Preciso de um servidor poderoso e de um bom engenheiro.
MCH: - Ok, vamos planejar. Já é hora de sair do ponto morto de 5 mil métricas por segundo.
Manhã após a atualização
MCH: - Misha, nós nos atualizamos, mas pela manhã retrocedemos... Adivinha que velocidade conseguimos alcançar?
MILÍMETROS: – 20 mil no máximo.
MCH: - Sim, 25! Infelizmente, estamos exatamente onde começamos.
MILÍMETROS: - Por que? Você executou algum diagnóstico?
MCH: - Sim, claro! Aqui, por exemplo, está um top interessante:
MILÍMETROS: - Vamos assistir. Vejo que tentamos um grande número de tópicos de pesquisa:
Mas, ao mesmo tempo, eles não conseguiram reciclar o sistema nem pela metade:
E o desempenho geral é bem pequeno, cerca de 4 mil métricas por segundo:
Mais alguma coisa?
MCH: – Sim, relato de um dos pesquisadores:
MILÍMETROS: – Aqui você pode ver claramente que o processo de votação está aguardando “semáforos”. Estas são as fechaduras:
MCH: - Não está claro.
MILÍMETROS: – Veja, isso é semelhante a uma situação em que vários threads estão tentando trabalhar com recursos com os quais apenas um pode trabalhar por vez. Então tudo o que eles podem fazer é compartilhar esse recurso ao longo do tempo:
E o desempenho total de trabalhar com tal recurso é limitado pela velocidade de um núcleo:
Existem duas maneiras de resolver esse problema.
Atualize o hardware da máquina, mude para núcleos mais rápidos:
Ou mude a arquitetura e ao mesmo tempo mude a carga:
MCH: – A propósito, usaremos menos núcleos na máquina de teste do que na máquina de combate, mas eles são 1,5 vezes mais rápidos em frequência por núcleo!
MILÍMETROS: - Claro? Você precisa olhar o código do servidor.
Caminho de dados no servidor Zabbix
MCH: – Para descobrir, começamos a analisar como os dados são transferidos dentro do servidor Zabbix:
Foto legal, certo? Vamos examinar isso passo a passo para torná-lo mais ou menos claro. Existem threads e serviços responsáveis pela coleta de dados:
Eles transmitem as métricas coletadas através de um soquete para o gerenciador do pré-processador, onde são salvas em uma fila:
O “gerenciador de pré-processador” transmite dados para seus trabalhadores, que executam instruções de pré-processamento e os retornam através do mesmo soquete:
Depois disso, o gerenciador do pré-processador os armazena no cache de histórico:
A partir daí, eles são retirados pelos chumbadores de histórico, que executam diversas funções: por exemplo, calcular gatilhos, preencher o cache de valores e, o mais importante, salvar métricas no armazenamento de histórico. Em geral, o processo é complexo e muito confuso.
MILÍMETROS: – A primeira coisa que vimos foi que a maioria dos threads competem pelo chamado “cache de configuração” (a área da memória onde são armazenadas todas as configurações do servidor). Threads responsáveis pela coleta de dados bloqueiam especialmente:
...já que a configuração armazena não apenas métricas com seus parâmetros, mas também filas das quais os pollers obtêm informações sobre o que fazer a seguir. Quando há muitos pollers e um bloqueia a configuração, os demais aguardam solicitações:
Os pesquisadores não devem entrar em conflito
Portanto, a primeira coisa que fizemos foi dividir a fila em 4 partes e permitir que os pollers bloqueiem essas filas, essas partes ao mesmo tempo, em condições seguras:
Isso eliminou a competição pelo cache de configuração e a velocidade dos pollers aumentou significativamente. Mas então nos deparamos com o fato de que o gerenciador do pré-processador começou a acumular uma fila de trabalhos:
O gerente do pré-processador deve ser capaz de priorizar
Isso aconteceu nos casos em que faltou desempenho. Então tudo o que ele pôde fazer foi acumular solicitações de processos de coleta de dados e adicionar seu buffer até consumir toda a memória e travar:
Para resolver este problema, adicionamos um segundo soquete dedicado especificamente aos trabalhadores:
Assim, o gerenciador do pré-processador teve a oportunidade de priorizar seu trabalho e, caso o buffer cresça, a tarefa é desacelerar a remoção, dando aos trabalhadores a oportunidade de aproveitar esse buffer:
Depois descobrimos que um dos motivos da desaceleração eram os próprios trabalhadores, que competiam por um recurso totalmente sem importância para o seu trabalho. Documentamos esse problema como uma correção de bug, e ele já foi resolvido em novas versões do Zabbix:
Aumentamos o número de soquetes - obtemos o resultado
Além disso, o próprio gerenciador de pré-processador tornou-se um gargalo, já que é um thread. Baseava-se na velocidade central, proporcionando uma velocidade máxima de cerca de 70 mil métricas por segundo:
Portanto, fizemos quatro, com quatro conjuntos de tomadas, trabalhadores:
E isso nos permitiu aumentar a velocidade para aproximadamente 130 mil métricas:
A não linearidade do crescimento é explicada pelo fato de ter surgido competição pelo cache histórico. 4 gerentes de pré-processador e chumbadas de história competiram por ele. Neste ponto, recebíamos aproximadamente 130 mil métricas por segundo na máquina de teste, utilizando-as por aproximadamente 95% do processador:
Cerca de 2,5 meses atrás
A recusa da comunidade snmp aumentou os NVPs em uma vez e meia
MILÍMETROS: – Max, preciso de um novo carro de teste! Não cabemos mais no atual.
MCH: - O que você tem agora?
MILÍMETROS: – Agora – 130 mil NVPs e um processador pronto para uso.
MCH: - Uau! Legal! Espere, tenho duas perguntas. Pelos meus cálculos, nossa necessidade gira em torno de 15 a 20 mil métricas por segundo. Por que precisamos de mais?
MILÍMETROS: “Quero terminar o trabalho.” Gostaria de ver quanto podemos extrair deste sistema.
MCH: - Mas ...
MILÍMETROS: “Mas é inútil para os negócios.”
MCH: - Está claro. E a segunda pergunta: podemos sustentar o que temos agora sozinhos, sem a ajuda de um desenvolvedor?
MILÍMETROS: - Eu não acho. Alterar o funcionamento do cache de configuração é um problema. Afeta alterações na maioria dos threads e é bastante difícil de manter. Muito provavelmente, será muito difícil mantê-lo.
MCH: “Então precisamos de algum tipo de alternativa.”
MILÍMETROS: - Existe essa opção. Podemos mudar para núcleos rápidos, abandonando o novo sistema de bloqueio. Ainda teremos um desempenho de 60 a 80 mil métricas. Ao mesmo tempo, podemos deixar todo o resto do código. Clickhouse e pesquisas assíncronas funcionarão. E será fácil de manter.
MCH: - Incrível! Sugiro que paremos por aqui.
Depois de otimizar o lado do servidor, finalmente conseguimos lançar o novo código em produção. Abandonamos algumas das mudanças em favor de mudar para uma máquina com núcleos rápidos e minimizar o número de alterações de código. Também simplificamos a configuração e eliminamos macros em itens de dados sempre que possível, pois elas introduzem bloqueio adicional.
Por exemplo, abandonar a macro da comunidade snmp, frequentemente encontrada em documentação e exemplos, em nosso caso tornou possível acelerar ainda mais os NVPs em cerca de 1,5 vezes.
Depois de dois dias em produção
Removendo pop-ups do histórico de incidentes
MCH: – Misha, estamos usando o sistema há dois dias e tudo funciona. Mas só quando tudo funcionar! Tínhamos planejado trabalhar com a transferência de um segmento bastante grande da rede e verificamos novamente com as mãos o que subiu e o que não subiu.
MILÍMETROS: - Não pode ser! Verificamos tudo 10 vezes. O servidor lida instantaneamente com indisponibilidade total da rede.
MCH: - Sim, eu entendo tudo: servidor, banco de dados, top, austat, logs - tudo é rápido... Mas olhamos a interface web, e tem um processador “na prateleira” no servidor e isto:
MILÍMETROS: - Está claro. Vamos assistir a web. Descobrimos que em uma situação em que havia um grande número de incidentes ativos, a maioria dos widgets ativos começava a funcionar muito lentamente:
A razão para isso foi a geração de pop-ups de histórico de incidentes gerados para cada item da lista. Portanto, abandonamos a geração dessas janelas (comentadas 5 linhas no código), e isso resolveu nossos problemas.
O tempo de carregamento dos widgets, mesmo quando completamente indisponíveis, foi reduzido de vários minutos para os aceitáveis 10-15 segundos para nós, e o histórico ainda pode ser visualizado clicando no tempo:
Depois do trabalho. 2 meses atrás
MCH: - Misha, você está indo embora? Nós precisamos conversar.
MILÍMETROS: - Eu não pretendia. Algo com Zabbix de novo?
MCH: - Não, relaxe! Só queria dizer: tudo funciona, obrigado! Eu tenho uma cerveja.
Zabbix é eficiente
Zabbix é um sistema e funções bastante universais e ricos. Ele pode ser usado imediatamente para pequenas instalações, mas conforme as necessidades aumentam, ele precisa ser otimizado. Para armazenar um grande arquivo de métricas, use um armazenamento adequado:
- você pode usar ferramentas integradas na forma de integração com Elasticsearch ou upload de histórico para arquivos de texto (disponível a partir da versão XNUMX);
- Você pode aproveitar nossa experiência e integração com Clickhouse.
Para aumentar drasticamente a velocidade de coleta de métricas, colete-as usando métodos assíncronos e transmita-as através da interface trapper para o servidor Zabbix; ou você pode usar um patch para tornar os pollers Zabbix assíncronos.
Zabbix é escrito em C e é bastante eficiente. Resolver diversos gargalos arquitetônicos permite aumentar ainda mais seu desempenho e, em nossa experiência, obter mais de 100 mil métricas em uma máquina de processador único.
O mesmo patch do Zabbix
MILÍMETROS: – Quero acrescentar alguns pontos. Todo o relatório atual, todos os testes, números são fornecidos para a configuração que usamos. Agora estamos extraindo dele aproximadamente 20 mil métricas por segundo. Se você está tentando entender se isso funcionará para você, você pode comparar. O que foi discutido hoje está postado no GitHub na forma de um patch:
O patch inclui:
- integração total com Clickhouse (servidor Zabbix e frontend);
- resolver problemas com o gerenciador de pré-processador;
- pesquisa assíncrona.
O patch é compatível com todas as versões 4, incluindo lts. Muito provavelmente, com alterações mínimas, funcionará na versão 3.4.
Obrigado por sua atenção.
perguntas
Pergunta do público (doravante – A): – Boa tarde! Por favor, diga-me, você tem planos de interação intensa com a equipe do Zabbix ou com eles com você, para que isso não seja um patch, mas um comportamento normal do Zabbix?
MILÍMETROS: – Sim, com certeza iremos realizar algumas das mudanças. Algo acontecerá, algo permanecerá no patch.
A: – Muito obrigado pelo excelente relatório! Diga-me, após aplicar o patch, o suporte do Zabbix permanecerá e como continuar atualizando para versões superiores? Será possível atualizar o Zabbix após o patch para 4.2, 5.0?
MILÍMETROS: – Não posso falar nada sobre suporte. Se eu fosse o suporte técnico do Zabbix, provavelmente diria não, porque este é o código de outra pessoa. Quanto à base de código 4.2, nossa posição é: “Iremos avançar com o tempo e nos atualizaremos na próxima versão”. Portanto, por algum tempo estaremos postando um patch para versões atualizadas. Já falei no relatório: o número de mudanças de versões ainda é bem pequeno. Acho que a transição de 3.4 para 4 demorou cerca de 15 minutos, algo mudou aí, mas não muito importante.
A: – Então você planeja oferecer suporte ao seu patch e pode instalá-lo com segurança na produção e receber atualizações de alguma forma no futuro?
MILÍMETROS: – Recomendamos fortemente. Isso resolve muitos problemas para nós.
MCH: – Mais uma vez gostaria de chamar a atenção para o fato de que as alterações que não dizem respeito à arquitetura e não dizem respeito a bloqueios ou filas são modulares, estão em módulos separados. Mesmo com pequenas alterações você pode mantê-los facilmente.
MILÍMETROS: – Se você estiver interessado nos detalhes, então “Clickhouse” utiliza a chamada biblioteca de histórico. Está desamarrado - é uma cópia do suporte do Elastics, ou seja, é configurável. A votação apenas muda os pesquisadores. Acreditamos que isso funcionará por muito tempo.
A: - Muito obrigado. Diga-me, existe alguma documentação das alterações feitas?
MILÍMETROS: – A documentação é um patch. Obviamente, com a introdução do Clickhouse, com a introdução de novos tipos de pollers, surgem novas opções de configuração. O link do último slide traz uma breve descrição de como usá-lo.
Sobre a substituição do fping pelo nmap
A: – Como você finalmente implementou isso? Você pode dar exemplos específicos: você tem strappers e um script externo? O que acaba verificando um número tão grande de hosts tão rapidamente? Como você explora esses hosts? Precisamos alimentá-los para o nmap de alguma forma, obtê-los de algum lugar, colocá-los, executar alguma coisa?
MILÍMETROS: - Legal. Uma pergunta muito correta! A questão é esta. Modificamos a biblioteca (ICMP ping, parte do Zabbix) para verificações ICMP, que indicam o número de pacotes - um (1), e o código tenta usar o nmap. Ou seja, esse é o trabalho interno do Zabbix, que passou a ser o trabalho interno do pinger. Conseqüentemente, nenhuma sincronização ou uso de um trapper é necessária. Isso foi feito deliberadamente para deixar o sistema intacto e não ter que lidar com a sincronização de dois sistemas de banco de dados: o que verificar, fazer upload através do poller, e nosso upload está quebrado?.. Isso é muito mais simples.
A: – Também funciona para proxies?
MILÍMETROS: – Sim, mas não verificamos. O código de polling é o mesmo tanto no Zabbix quanto no servidor. Deveria trabalhar. Deixe-me enfatizar mais uma vez: o desempenho do sistema é tal que não precisamos de proxy.
MCH: – A resposta correta para a pergunta é: “Por que você precisa de um proxy com esse sistema?” Só por causa do NAT ou do monitoramento através de algum tipo de canal lento...
A: – E você usa o Zabbix como alertador, se bem entendi. Ou seus gráficos (onde está a camada de arquivo) foram movidos para outro sistema, como o Grafana? Ou você não está usando essa funcionalidade?
MILÍMETROS: – Vou enfatizar mais uma vez: conseguimos uma integração completa. Estamos despejando história no Clickhouse, mas ao mesmo tempo mudamos o frontend do php. O frontend do PHP vai para Clickhouse e faz todos os gráficos de lá. Ao mesmo tempo, para ser sincero, temos uma parte que constrói dados em outros sistemas de exibição gráfica do mesmo Clickhouse, a partir dos mesmos dados do Zabbix.
MCH: – Em “Grafan” também.
Como foram tomadas as decisões sobre a alocação de recursos?
A: – Compartilhe um pouco da sua cozinha interior. Como foi tomada a decisão de que era necessário destinar recursos para o processamento sério do produto? Estes são, em geral, certos riscos. E por favor me diga, no contexto do fato de que você vai apoiar novas versões: como essa decisão se justifica do ponto de vista gerencial?
MILÍMETROS: – Aparentemente, não contamos muito bem o drama da história. Encontramo-nos numa situação em que algo tinha de ser feito e, essencialmente, optámos por duas equipas paralelas:
- Uma delas foi lançar um sistema de monitoramento usando novos métodos: monitoramento como serviço, um conjunto padrão de soluções de código aberto que combinamos e depois tentamos mudar o processo de negócios para funcionar com o novo sistema de monitoramento.
- Ao mesmo tempo, tínhamos um programador entusiasmado que fazia isso (sobre si mesmo). Acontece que ele ganhou.
A: – E qual é o tamanho da equipe?
MCH: - Ela está na sua frente.
A: – Então, como sempre, você precisa de um apaixonado?
MILÍMETROS: – Não sei o que é um apaixonado.
A: - Neste caso, aparentemente, você. Muito obrigado, você é incrível.
MILÍMETROS: Obrigado.
Sobre patches para Zabbix
A: – Para um sistema que utiliza proxies (por exemplo, em alguns sistemas distribuídos), é possível adaptar e corrigir, digamos, pollers, proxies e parcialmente o próprio pré-processador do Zabbix; e sua interação? É possível otimizar os desenvolvimentos existentes para um sistema com múltiplos proxies?
MILÍMETROS: – Eu sei que o servidor Zabbix é montado usando um proxy (o código é compilado e obtido). Não testamos isso em produção. Não tenho certeza disso, mas acho que o gerenciador de pré-processador não é usado no proxy. A tarefa do proxy é pegar um conjunto de métricas do Zabbix, mesclá-las (ele também registra a configuração, o banco de dados local) e devolvê-lo ao servidor Zabbix. O próprio servidor fará o pré-processamento quando o receber.
O interesse em procurações é compreensível. Vamos verificar. Este é um tópico interessante.
A: – A ideia era esta: se você pode corrigir pollers, você pode corrigi-los no proxy e corrigir a interação com o servidor, e adaptar o pré-processador para esses fins apenas no servidor.
MILÍMETROS: – Acho que é ainda mais simples. Você pega o código, aplica um patch e configura-o da maneira necessária - coleta servidores proxy (por exemplo, com ODBC) e distribui o código corrigido entre os sistemas. Se necessário, colete um proxy, se necessário, um servidor.
A: – Provavelmente, você não precisará corrigir adicionalmente a transmissão do proxy para o servidor?
MCH: - Não, é padrão.
MILÍMETROS: – Na verdade, uma das ideias não soou. Sempre mantivemos um equilíbrio entre a explosão de ideias e a quantidade de mudanças e facilidade de suporte.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com