O proxy Zabbix é um processo que pode coletar dados de monitoramento de um ou mais dispositivos monitorados e enviar as informações para o servidor Zabbix, funcionando essencialmente em nome do servidor. Todos os dados coletados são armazenados localmente em buffer e, em seguida, transferidos para o servidor Zabbix ao qual o proxy pertence.
Implantar um proxy é opcional, mas pode ser muito benéfico para distribuir a carga de um único servidor Zabbix. Se apenas proxies coletarem dados, o processamento no servidor se torna menos exigente em termos de CPU e I/O de disco.
Um proxy Zabbix é a solução ideal para monitoramento centralizado de locais remotos, filiais e redes sem administradores locais.
O proxy Zabbix requer um banco de dados separado.
Observe que os bancos de dados suportados com o proxy Zabbix são SQLite, MySQL e PostgreSQL.
Veja também: Usando proxies em um ambiente distribuído
O proxy Zabbix é executado como um processo daemon. O proxy pode ser iniciado executando:
Isso funcionará na maioria dos sistemas GNU/Linux. Em outros sistemas, pode ser necessário executar:
Da mesma forma, para parar/reiniciar/ver o status do proxy Zabbix, use os seguintes comandos:
Se o acima não funcionar, você terá que iniciá-lo manualmente. Encontre o caminho para o binário zabbix_proxy e execute:
Você pode usar os seguintes parâmetros de linha de comando com o Zabbix proxy:
-c --config <file> caminho para o arquivo de configuração
-f --foreground executar o Zabbix proxy em primeiro plano
-R --runtime-control <option> executar funções administrativas
-T --test-config validar o arquivo de configuração e sair
-h --help exibir esta ajuda
-V --version exibir o número da versãoExemplos de execução do Zabbix proxy com parâmetros de linha de comando:
Opções de controle em tempo de execução:
| Opção | Descrição | Destino |
|---|---|---|
| config_cache_reload | Recarrega o cache de configuração. Ignorado se o cache estiver sendo carregado no momento. O proxy Zabbix ativo irá se conectar ao servidor Zabbix e solicitar os dados de configuração. O proxy Zabbix passivo solicitará os dados de configuração do servidor Zabbix na próxima vez que o servidor se conectar ao proxy. |
|
| history_cache_clear=target | Limpa o cache de histórico para o item especificado pelo seu ID. Afeta todos os valores do item, exceto o primeiro e o último valor. |
target - ID do item |
| diaginfo[=<section>] | Coleta informações de diagnóstico no arquivo de log do proxy. | historycache - estatísticas do cache de histórico preprocessing - estatísticas do gerenciador de pré-processamento locks - lista de mutexes (fica vazia em sistemas BSD) |
| snmp_cache_reload | Recarrega o cache SNMP — limpa as propriedades do mecanismo SNMP (engine time, engine boots, engine id, credenciais) para todos os hosts. Use para forçar uma limpeza global do cache ao solucionar problemas de SNMP. | |
| housekeeper_execute | Inicia o procedimento de housekeeping. Ignorado se o procedimento de housekeeping estiver em andamento. | |
| log_level_increase[=<target>] | Aumenta o nível de log, afeta todos os processos se o destino não for especificado. Não suportado em sistemas BSD. |
process type - Todos os processos do tipo especificado (por exemplo, poller) Veja todos os tipos de processos do proxy. process type,N - Tipo de processo e número (por exemplo, poller,3) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o destino como 'process type,N'. |
| log_level_decrease[=<target>] | Diminui o nível de log, afeta todos os processos se o destino não for especificado. Não suportado em sistemas BSD. |
|
| prof_enable[=<target>] | Habilita o profiling. Afeta todos os processos se o destino não for especificado. O profiling habilitado fornece detalhes de todos os rwlocks/mutexes por nome de função. |
process type - Todos os processos do tipo especificado (por exemplo, history syncer) Veja todos os tipos de processos do proxy. process type,N - Tipo de processo e número (por exemplo, history syncer,1) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o destino como 'process type,N'. scope - rwlock, mutex, processing podem ser usados com o tipo de processo e número (por exemplo, history syncer,1,processing) ou todos os processos do tipo (por exemplo, history syncer,rwlock) |
| prof_disable[=<target>] | Desabilita o profiling. Afeta todos os processos se o destino não for especificado. |
process type - Todos os processos do tipo especificado (por exemplo, history syncer) Veja todos os tipos de processos do proxy. process type,N - Tipo de processo e número (por exemplo, history syncer,1) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o destino como 'process type,N'. |
Exemplo de uso do controle em tempo de execução para recarregar o cache de configuração do proxy:
Exemplo de uso do controle em tempo de execução para limpar o cache de histórico de um item:
Exemplos de uso do controle em tempo de execução para coletar informações de diagnóstico:
# Coletar todas as informações de diagnóstico disponíveis no arquivo de log do proxy:
zabbix_proxy -R diaginfo
# Coletar estatísticas do cache de histórico no arquivo de log do proxy:
zabbix_proxy -R diaginfo=historycacheExemplo de uso do controle em tempo de execução para recarregar o cache SNMP:
Quando uma interface SNMPv3 é atualizada pela interface web do Zabbix, o Zabbix irá recarregar automaticamente as novas credenciais SNMPv3 para essa interface na maioria dos casos; use -R snmp_cache_reload apenas se a coleta ainda falhar após a alteração das credenciais (por exemplo, devido a inconsistências de engineBoots/engineID ou dispositivos que não seguem o RFC), ou quando for necessário forçar uma limpeza global do cache SNMP para solução de problemas.
Exemplo de uso do controle em tempo de execução para acionar a execução do housekeeper:
Exemplos de uso do controle em tempo de execução para alterar o nível de log:
# Aumentar o nível de log de todos os processos:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase
# Aumentar o nível de log do segundo processo poller:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2
# Aumentar o nível de log do processo com PID 1234:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=1234
# Diminuir o nível de log de todos os processos http poller:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"O proxy Zabbix foi projetado para ser executado como um usuário não-root. Ele será executado como qualquer usuário não-root que for iniciado. Portanto, você pode executar o proxy como qualquer usuário não-root sem problemas.
Se você tentar executá-lo como 'root', ele mudará para o usuário 'zabbix', que deve estar presente no seu sistema. Você só pode executar o proxy como 'root' se modificar o parâmetro 'AllowRoot' no arquivo de configuração do proxy de acordo.
Veja as opções do arquivo de configuração para obter detalhes sobre como configurar o zabbix_proxy.
agent poller - processo de poller assíncrono para verificações passivas com uma thread de trabalhoavailability manager - processo para atualizações de disponibilidade do hostbrowser poller - poller para verificações de item de navegadorconfiguration syncer - processo para gerenciar o cache em memória dos dados de configuraçãodata sender - remetente de dados do proxydiscovery manager - processo gerenciador para descoberta de dispositivosdiscovery worker - processo para lidar com tarefas de descoberta do discovery managerhistory syncer - gravador de histórico no banco de dadoshousekeeper - processo para remoção de dados históricos antigoshttp agent poller - processo de poller assíncrono para verificações HTTP com uma thread de trabalhohttp poller - poller de monitoramento webicmp pinger - poller para verificações icmppinginternal poller - poller para verificações internasipmi manager - gerenciador de poller IPMIipmi poller - poller para verificações IPMIjava poller - poller para verificações Javaodbc poller - poller para verificações ODBCpoller - poller normal para verificações passivaspreprocessing manager - gerenciador de tarefas de pré-processamento com threads de trabalho de pré-processamentopreprocessing worker - thread para pré-processamento de dadosself-monitoring - processo para coleta de estatísticas internas do serversnmp poller - processo de poller assíncrono para verificações SNMP com uma thread de trabalho (apenas itens walk[OID] e get[OID])snmp trapper - trapper para traps SNMPtask manager - processo para execução remota de tarefas solicitadas por outros componentes (por exemplo, fechar problema, reconhecer problema, verificar valor de item agora, funcionalidade de comando remoto)trapper - trapper para verificações ativas, traps, comunicação de proxyunreachable poller - poller para dispositivos inacessíveisvmware collector - coletor de dados VMware responsável pela coleta de dados de serviços VMwareO arquivo de log do proxy pode ser usado para observar esses tipos de processos.
Desde o Zabbix 7.4.6, o arquivo de log do proxy é criado com permissões de leitura e gravação apenas para o proprietário do arquivo. Além disso, o arquivo é legível pelo grupo do proprietário. Todas as outras permissões são negadas.
Vários tipos de processos do proxy Zabbix podem ser monitorados usando o item interno zabbix[process,<type>,<mode>,<state>].
O título do processo history syncer exibe estatísticas detalhadas sobre as transações do history syncer.
205276 ? S 0:00 zabbix_proxy: history syncer #1 [processed 1 values in 0.001179 (0.001167,0.000000) sec, idle 1 sec]
205277 ? S 0:00 zabbix_proxy: history syncer #2 [processed 0 values in 0.000022 (0.000000,0.000000) sec, idle 1 sec]Os tempos, em "processed...in N (<timings>) sec", são:
O proxy Zabbix é executado na mesma lista de plataformas suportadas que o server Zabbix.
O buffer de memória permite armazenar novos dados (valores de item, descoberta de rede, auto-registro de host) no buffer e enviá-los para o Zabbix server sem acessar o banco de dados. O buffer de memória foi introduzido para o proxy a partir do Zabbix 7.0.
Em instalações anteriores ao Zabbix 7.0, os dados coletados eram armazenados no banco de dados antes de serem enviados para o Zabbix server. Para essas instalações, esse continua sendo o comportamento padrão após a atualização para o Zabbix 7.0.
Para desempenho otimizado, recomenda-se configurar o uso do buffer de memória no proxy. Isso é possível modificando o valor de ProxyBufferMode de "disk" (padrão fixo para instalações existentes) para "hybrid" (recomendado) ou "memory". Também é necessário definir o tamanho do buffer de memória (parâmetro ProxyMemoryBufferSize).
No modo híbrido, o buffer é protegido contra perda de dados, descarregando os dados não enviados para o banco de dados se o proxy for parado, o buffer estiver cheio ou os dados estiverem muito antigos. Quando todos os valores forem descarregados no banco de dados, o proxy volta a usar o buffer de memória.
No modo de memória, o buffer de memória será usado, no entanto, não há proteção contra perda de dados. Se o proxy for parado ou a memória ficar sobrecarregada, os dados não enviados serão descartados.
O modo híbrido (ProxyBufferMode=hybrid) é aplicado a todas as novas instalações a partir do Zabbix 7.0.
Parâmetros adicionais, como ProxyMemoryBufferSize e ProxyMemoryBufferAge, definem o tamanho do buffer de memória e a idade máxima dos dados no buffer, respectivamente.
Nota que, com configurações conflitantes, o proxy exibirá um erro e não iniciará, por exemplo, se:
Observe que o proxy requer uma localidade UTF-8 para que alguns itens textuais possam ser interpretados corretamente. A maioria dos sistemas modernos semelhantes ao Unix possui uma localidade UTF-8 como padrão, no entanto, há alguns sistemas em que isso pode precisar ser definido especificamente.
O proxy Zabbix não tem conhecimento dos períodos de manutenção; consulte Cálculo de filas durante a manutenção para obter detalhes.