Caros,

Um dos motivos pelos quais a Zabbix INC está revendo toda a estrutura dos NODEs seria “bugs relacionados a problemas de sincronismo”.

Sincronismo de base de dados sempre foi algo complexo para os grandes SGDBs logo não seria diferente para uma ferramenta de monitoração.

Vou colocar aqui a minha análise do problema, não digo que ela é correta ou errada apenas que representa o que eu entendo ser o meu problema e como o NODE é essencial para resolver.

Meu problema:

1) A empresa para a qual trabalho tem representação e clientes em praticamente todo o território nacional e em várias localizações físicas do pais (na maioria das vezes mais de 1 prédio com elementos a monitorar no mesmo estado).

2) Existem equipes REMOTAS de administração e equipes locais. Equipes de suporte de terceiro nível são “sempre” remotas.

Posto isso eu preciso ter uma ferramenta que me possibilite prover uma visão local e uma visão regional / nacional. Para isso o NODE foi criado para isso o utilizo.

O problema é que o NODE tem alguns “potenciais bugs relacionados a sincronismo, potencializados quando se tem monitoração multinível de node (node mestre => node filho => node neto, etc.)”.

No meu caso a abordagem que escolhi para usar a solução e resolver o problema foi:

1) Uma equipe nacional responsável por padronização da monitoração e pelo 24×7;
2) Equipes locais (onde existir administradores de rede) responsável pelo cadastro e manutenção dos hosts a serem monitorados.
3) Telas de monitoração nacionais (normalmente exibidas em NOCs) com visões macro e micro.
4) Telas de monitoração regionais (normalmente exibidas em telas LCD no local onde ficam os administradores regionais) com visão macro e micro daquela região.

Obviamente temos aí redes LAN, MAN e WAN e SLA em cima de cada uma delas (muitas vezes SLA em cima das aplicações também), logo precisamos ter a correta granularidade de monitoração e de visão visando alcançar os níveis contratados.

Esta é a estratégia macro do que entendemos ser como o melhor que podemos chegar neste momento para a monitoração dos quase 15.000 hosts que temos que monitorar (com crescimento na ordem de 10% ano).

Uma vez que obtive a informação sobre “bugs de sincronismo” fui forçado a pensar em alternativas uma vez que não posso abrir mão da monitoração conforme os contratos me exigem.

A forma que encontrei para mitigar o problema foi: forçar que a configuração seja feita no ponto mais próximo, ou seja, nada de permitir que o node master envie para o node filho configurações. Uma vez que ele não envia configurações não há o que se falar de problemas de sincronismo, pois o envio de dados passa a ser unidirecional.

Como o sistema de nodes do Zabbix funciona?
O sistema de nodes é detalhado nas urls abaixo:
Para 2.0.x: https://www.zabbix.com/documentation/doku.php?id=2.0%2Fmanual%2Fdistributed_monitoring%2Fnodes
Para 2.2.x (ainda não foi lançado): https://www.zabbix.com/documentation/2.2/manual/distributed_monitoring/nodes

Conforme é detalhado nestas duas URLs podemos criar monitoração de um nível (pai => filho) ou de mais de um nível (pai => filho => neto => bisneto => etc.). A empresa para a qual eu trabalho precisa desta possibilidade além do suporte aos proxies, conforme declarado no início deste post.

O node foi construído visando possibilitar o sincronismo de dados que é muito lindo na teoria, entretanto, vários SGDBs simplesmente desistiram disso pois é extremamente complexo garantir a integridade da base visto que as relações de dependência que podem ocorrer no caminho (alterações simultâneas com exclusões e inclusões em locais distintos e sincronismos de dados feitos a posteriore) podem literalmente ferrar com a base de dados.

A única forma que vejo, até que a Zabbix INC nos proveja alguma outra opção, é: garantir sentido único de dados.

Digamos que o meu ambiente seja este:

NODE | IP | Objetivo
101 | 10.10.10.10 | No master da monitoração
201 | 10.10.11.10 | No filho 1 responsável por São Paulo
202 | 10.10.12.10 | No filho 2 responsável por Rio de Janeiro
203 | 10.10.15.10 | No filho 3 responsável por Brasília
301 | 10.10.16.10 | No Neto 1 responsável por Campinas/SPO ligado a Filho 1
302 | 10.10.16.10 | No Neto 2 responsável por Barueri/SPO ligado a Filho 1
303 | 10.10.16.10 | No Neto 3 responsável por Barretos/SPO ligado a Filho 1
304 | 10.10.16.10 | No Neto 4 responsável por Búzios/RJO ligado a Filho 2

Logo temos uma monitoração com 3 níveis hierárquicos:
Nível 1) Master
Nível 2) Nodes regionais
Nível 3) Nodes setoriais

Percebe-se que a quantidade de nodes setoriais varia, ou até inexiste, em função de necessidades da monitoração. E eu possuo (no caso hipotético pois não posso publicar informações reais do meu ambiente de monitoração sem autorização) equipes locais em cada prédio físico onde está um node de monitoração.

Para garantir tal modo de funcionamento é muito simples, preciso apenas de “errar propositalmente” a minha configuração.

Nos nodes de nível 1 faço a configuração correta conforme explicitado nas URLs referenciadas acima.

Nos nodes de nível 2 e 3 (e também nos subsequentes) eu “erro” a configuração do MASTER.

Em “Filho 1, 2 e 3” para que a monitoração funcione eu deveria informar ao mesmo que o ID do node MASTER é 101, entretanto eu vou dizer que o ID deste node é 999 e eu nunca irei utilizar este ID de node na minha infraestrutura para referenciar um node válido.

Em “Neto 1, 2, 3 e 4” eu deveria colocar o respectivo ID de node “Filho” (segundo nível da árvore hierárquica) na configuração, entretanto, vou “errar” novamente e colocar que o ID é 999.

Isso vai me gerar uma linha de “erro” nos nodes filhos pois o Zabbix_Server valida se o node que está enviando dados é um node válido para tal ação.

A linha será similar à linha abaixo para os nodes de nível 1:
” 2778:20130102:141305.404 NODE 201: Received configuration changes from unknown node 101″

E será similar à linha abaixo para nodes de nível 2 conectados ao node de SPO:
” 2778:20130102:141305.404 NODE 303: Received configuration changes from unknown node 201″

Com isso eu garanto que mesmo que alguém, contrariando as orientações de não faze-lo, resolva cadastrar ou alterar elementos usando o node de nível mais alto contra um node de nível mais baixo (por exemplo alterar dados de 202 em 101, ou alterar em 201 dados de 303) esta configuração [B]nunca será aceita pelo node de nível mais baixo pois o ID do node master não é reconhecido[/B].

Após ter feito isso eu garanto que não irei ter base corrompida por conta de erros operacionais ou de bugs.

Fica apenas uma lacuna que é identificar as alterações não autorizadas feitas no node de nível mais alto contra um node de nível mais baixo. Tal lacuna será preenchida através de um relatório de não conformidade que aponte (através do recurso de auditoria do Zabbix) as alterações não autorizadas feitas.

Espero estar contribuindo com a comunidade Zabbix com este post, ele resolve o MEU problema entretanto pode não resolver totalmente o de outras pessoas e, por isso gostaria de receber o feedback de vocês relacionado a isso.