👩🏻‍🤝‍👨🏿 🐳 👨🏼‍🎤 Como atualizamos o Zabbix 👩🏿‍🏭 🍥 ☄️

imagem

Por que amamos Prometeu ? Ele tem uma configuração - ele olhou e está tudo claro, o programa faz o que ela mandou. Você pode automatizar as configurações de monitoramento, armazená-las no VCS e revisar o comando. Restringiu seu MR , pipeline trabalhado, uma nova configuração aplicada ao prometheus. Em geral, IaC em toda a sua glória.

Falando em prometeu. Você o usa para sua infraestrutura de ferro? Então nós não usamos.

Como muitos que monitoram há muito tempo e possuem hardware "vazio", usamos o Zabbix , que, aliás, está localizado nesse hardware. Infelizmente, no momento, o Zabbix e o IaC são coisas não relacionadas. O Zabbix pode ser configurado manualmente ou através da API.

Antecedentes

Em outubro de 2018, o Zabbix-4.0 foi lançado - uma nova filial do LTS . E em meados de março, começamos a planejar atualizar nossa instalação da versão 3.4 para ele.

Quase não houve problemas especiais com o 3.4:

Às vezes, alguns LLDs não funcionavam em algum lugar e o Impossível acontecia, o que não está claro como depurar uma versão não suportada pelo desenvolvedor.
A memória dos extratores HTTP fluia constantemente - como resultado, um sistema cuidadosamente configurado pregou o monitoramento e o iniciou novamente. O problema foi mascarado por uma quantidade razoável de memória do servidor. O problema é bem conhecido, documentado .

E na versão 4.0 havia recursos interessantes, como itens HTTP nativos e períodos de serviço, não para todo o host.

E onde é visto, sentado em uma versão irrelevante do monitoramento, nem mesmo no LTS? Nós devemos nos manter atualizados.

Além disso, ao planejar a atualização, foi descoberto um detalhe interessante: o progresso não pára, você pode levar carros mais rápidos a um preço mais baixo. E, ao longo do caminho, encontrei uma maneira de economizar no serviço hoster já desnecessário em vários projetos de colegas. Como se costuma dizer, entramos com sucesso.

Atualização na testa

Não há nada particularmente complicado na atualização do zabbix agora. Solicite um servidor, configure-o, mescle uma cópia do banco de dados. Coloque os pacotes de monitoramento e mostre a eles a base, execute zabbiks - e ele atualizará tudo para você, faça todas as migrações. Bem, sim, você provavelmente sabe como a atualização do Zabbix se tornou fácil.

No total, a migração do banco de dados levou cerca de 15 minutos, e mesmo sem muito abuso. E tudo parece estar bem. Hein? Não importa como! Apesar do fato de o IP do novo servidor não estar listado nas listas brancas de agentes e coletar dados de apenas alguns hosts de teste, o Impossível ainda está acontecendo nele.

Para o crédito dos desenvolvedores do Zabbix, devo dizer, eles mantêm sua palavra - a versão 4.2 é suportada naquele momento. Após conversar no rastreador de projeto, descobrimos que o motivo do impossível é que ele não coincide com a estrutura esperada de uma das tabelas do banco de dados.

Surgem dúvidas vagas. Será útil lembrar que historicamente as tabelas de banco de dados do Zabbix “mais grossas” foram particionadas. Primeiro, por razões de desempenho, para, de alguma forma, encobrir seu calo zabbix favorito - excluindo dados históricos no RDBMS . Comparamos as estruturas de todas as tabelas em uma linha em um banco de dados atualizado recentemente e um controle - criado pelo próprio servidor a partir do zero. Os medos foram confirmados. Além da falta de algumas constantes no banco de dados, em muitas tabelas, muitas colunas digitais são do tipo errado.

Na verdade, não temos um esquema básico suportado pelos desenvolvedores, mas nosso próprio "fork". Outro tipo de dados da coluna é, potencialmente:

outro custo de armazenamento métrico
precisão diferente de números
velocidade de amostragem / gravação diferente das métricas

Pense para melhor? É duvidoso. De acordo com a experiência anterior com suporte técnico e desenvolvedores do zabbix, eles podem ajustar DBMSs.

E esse tipo de dados da coluna é possível, mas difícil e demorado para mudar. E é impossível sem um longo monitoramento de tempo de inatividade. Sem garantias de sucesso, sem o apoio do desenvolvedor no futuro. Precisa de outra maneira.

E o Zabbix tem. Porque em abril de 2019, o zabbix-4.2 será lançado

A segunda abordagem para o projétil

O principal recurso do 4.2 para nós é o suporte ao particionamento imediato usando o TimescaleDB . Após conversar com os representantes do Zabbix e nos familiarizar com os resultados de testar seu suporte técnico para esse recurso ( tradução no hub), decidimos testar a instalação com timescaledb e, com base nos resultados, tomar uma decisão sobre a transição. Mais especificamente: por algum tempo, todos os dados de monitoramento serão gravados em paralelo à versão antiga e à nova. E então apenas mudamos a entrada DNS.

Obviamente, essa abordagem não permite salvar dados e tendências históricos - o novo banco de dados é preenchido do zero. Mas eles são realmente necessários? A história importa apenas aqui e agora, ela se acumulará rapidamente novamente (veja o mesmo prometheus). Somente a utilidade indiscutível das tendências para o planejamento da capacidade permanece. De qualquer forma, o arquivo com os dados já coletados permanece conosco (olhando para o futuro - foi útil para alguns clientes). Outro recurso do suporte ao timescaledb no zabbix é que períodos individuais do histórico / armazenamento de tendências não são mais válidos.

Temos clientes que insistem no armazenamento "eterno" de todos os dados coletados a todo custo. Podemos oferecer a eles que considerem a instalação / suporte de uma instalação de monitoramento separada com configurações específicas. Nossa principal tarefa é garantir a operação estável dos projetos / servidores dos clientes, mantendo um custo aceitável dos serviços, o que inclui também o monitoramento.

No total, as seguintes etapas serão necessárias para a migração:

Instale e configure uma segunda instalação de monitoramento
Faça tudo da mesma forma que na primeira instalação
Switch!

Parece fácil, certo? De fato, o primeiro não é muito difícil, porque durante a abordagem anterior, escrevemos uma função para instalar um servidor zabbix, basta apenas fazer o upload da configuração. O terceiro item também parece simples - alterne o DNS e todos os agentes, proxies, clientes API e zabbiks da API para a nova versão. Mas como fazer o segundo ponto?

A princípio, tentamos uma abordagem ingênua. Importados do monitoramento atual alguns dos modelos mais usados. Usando os scripts já escritos para trabalhar com a API, iniciamos os mesmos projetos no novo monitoramento que no atual, promovemos edições nos sistemas SCM , adicionando o IP da nova máquina ao filtro de pacotes e às diretivas de agente / servidor ativo . Até funcionou - muitos hosts começaram a se registrar em dois monitoramentos ao mesmo tempo, o novo atribuiu a eles modelos e começou a coletar dados em paralelo com o atual.

Infelizmente, essa é precisamente a abordagem ingênua da migração, adequada apenas para o teste. A carga resultante (em nvps ) não pôde ser comparada com a instalação atual, sendo mais baixa em ordens de magnitude. É compreensível. No nosso caso, o monitoramento é literalmente os anos de trabalho de muitas pessoas e scripts, a quintessência da experiência na operação de projetos heterogêneos.

Por exemplo, e quanto aos usuários que acabaram manualmente e suas senhas, gerados aleatoriamente ao criar projetos, monitorar modelos pendurados em hosts (com seus valores de macro personalizados), itens criados manualmente, telas complexas, gráficos, painéis, períodos de serviço, proxies? Tudo isso e muito mais precisa ser transferido para uma migração suave.

Felizmente, o zabbix possui uma funcionalidade integrada para exportar / importar objetos - também disponível através da API. Infelizmente, abrange não mais da metade de todas as instalações existentes. E o código para usá-lo também precisa ser escrito. Em geral, você não pode simplesmente pegar e importar a configuração de um zabbik para outro.

Ou é possível?

Aqui, o cérebro recorda de maneira útil a tarefa da lista de pendências de que seria bom organizar o armazenamento do histórico de configurações de monitoramento por meios externos. Infelizmente, este é um ponto dolorido do Zabbix. Com referência ao artigo no hub e no repositório com código. Mas existem nuances:

o código não exporta todos os objetos de monitoramento para arquivos YAML legíveis por humanos (em particular, nem tudo o que precisamos)
o código não suporta a importação de objetos

Felizmente, existem pessoas que conhecem um pouco a linguagem do projeto (python) e têm experiência com a API do Zabbix. O único negócio é importar objetos de dumps YAML prontos. Por quanto tempo, para resumir, mas depois de três semanas de trabalho e cem e meia confirmadas, um garfo era bastante adequado para nossos propósitos. Na verdade, para cuja apresentação o artigo inteiro está escrito:

https://github.com/centosadmin/zabbix-review-export-import

O que foi feito:

Adicionado suporte para muitos novos objetos
O formato da exportação YAML da maioria dos objetos existentes foi alterado para que eles possam ser importados
Adicionada a capacidade de importar a maioria dos objetos exportados
Adicionado funcionalidade limitada para converter objetos entre diferentes versões do zabbix (como no nosso caso)

A importação é suportada quase exclusivamente pela criação de novos objetos. Se um objeto existir, ele não será modificado. Isso nos permitiu manter a complexidade do código pelo menos em algumas estruturas, economizar tempo e aumentar a velocidade do trabalho - ao importar milhares de objetos. O uso da importação é muito simples:

./zabbix-import.py /path/to/file.yaml

(presume-se que os parâmetros de monitoramento de destino sejam especificados nas variáveis de ambiente, para obter mais detalhes, consulte a saída --help )

Em geral, você pode especificar qualquer número de arquivos YAML de entrada - e todos eles serão processados. Mas, considerando que existem muitas dependências entre objetos, faz mais sentido importar objetos tipo por tipo, começando pelos mais simples e básicos. Além disso, se você importar um objeto de um arquivo, pode fazer sentido especificar explicitamente seu tipo para acelerar um pouco a importação - nem todos os caches são carregados, mas apenas os necessários.

Assim, dois repositórios apareceram em nosso hitlab com despejos YAML atualizados periodicamente de duas versões de monitoramento, a atual e a nova. E, é claro, a capacidade de restaurar quase qualquer objeto de monitoramento a qualquer momento.

Implantação de monitoramento contínuo e migração propriamente dita

Como resultado, chegamos à conclusão de que o gitlab, dentro do cronograma, lança um pipeline no repositório do novo monitoramento, que, passo a passo, importa hierarquicamente do tipo de objetos um após o outro. Isso nos permitiu importar a grande maioria dos objetos e dar às nossas equipes de administradores tempo para resolver com calma os problemas que surgiram - e eles não se acumularam tanto ao longo dos anos. Objetos "extras" não foram excluídos.

O problema com senhas de usuário - elas também são exportadas / importadas, mas uma senha aleatória é atribuída durante a criação - pode ser resolvido convertendo o dump SQL da tabela com as credenciais do monitoramento atual em instruções SQL para definir as senhas corretas no novo monitoramento.

Para não receber uma porção dupla de tarefas durante a operação paralela, todas as ações no novo monitoramento foram imediatamente desativadas e não foram mais excluídas.

Assim, a troca foi bem fácil e se resumiu aos seguintes pontos:

exclua todos os hosts no novo monitoramento (alguns scripts na API são gravados para isso)
puxe os SCMs para atualizar a versão do zabbix-proxy e alterne os proxies para um novo servidor
aguarde a importação de hosts do despejo do antigo monitoramento
alternar registros DNS

(plano reduzido para simplificar)

O que vem a seguir?

Obviamente, o código não é perfeito nem particularmente bonito. Ele não importa tudo, em particular, há problemas com alguns modelos - procure FIXME no código. Mas isso foi suficiente para nós. Talvez este garfo seja útil para outra pessoa. Uma extensão lógica é o desenvolvimento de uma operação semelhante do utilitário Terraform , quando o monitoramento de destino é completamente reduzido ao formato especificado, por exemplo, por um diretório com dumps YAML. Incluindo a redução das instalações existentes para a forma desejada.

Isso permitirá que você espere com calma o suporte de alta disponibilidade "nativo" no zabbix, tendo dois servidores, as configurações são sincronizadas entre eles automaticamente. Agora você precisa manter uma réplica, proxies e scripts de gravação.

Camo vindo?

Após estudar os materiais das conferências e reuniões, o roteiro oficial, o rastreador de erros e a (modesta) experiência pessoal com os desenvolvedores do zabbix, parece que eles entendem perfeitamente a situação em que estão agora. Quando o zabbix começou, os autores não pensaram em nenhum IaC ao resolver seus problemas. Uma década depois, o produto amadureceu e floresceu. O outro lado do sucesso foi a massa de clientes da empresa, cujo monitoramento resolve seus problemas. E quem realmente não gosta da revolução. Nas condições modernas, eles, por um lado, são contra quebrar tudo e começar do zero. Por outro lado, eles às vezes carecem de recursos de monitoramento e parecem “ao lado”, não esquecendo de expressar a lista de desejos para os desenvolvedores do Zabbix. A empresa não vai arriscar, apesar de qualquer simpatia pela nova juventude, conveniente e elegante.

Não veremos um novo e correto prometheus do Zabbix em um futuro próximo. Não importa como eu gostaria. Mas o trabalho está claramente acontecendo - e se você, como o zabbix, for completo e paciente, o futuro também espera um futuro sem nuvens.

Como atualizamos o Zabbix