O proxy do Zabbix é um processo que pode coletar dados de monitoramento de um ou mais dispositivos monitorados e enviar as informações para o server do Zabbix, funcionando essencialmente em nome do server. Todos os dados coletados são armazenados localmente em buffer e, em seguida, transferidos para o server do Zabbix ao qual o proxy pertence.
Implantar um proxy é opcional, mas pode ser muito benéfico para distribuir a carga de um único server Zabbix. Se apenas proxies coletarem dados, o processamento no server se torna menos exigente em 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/verificar o status do proxy Zabbix, use os seguintes comandos:
Se o acima não funcionar, você terá que iniciar 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 executa o Zabbix proxy em primeiro plano
-R --runtime-control <option> executa funções administrativas
-T --test-config valida o arquivo de configuração e sai
-h --help exibe esta ajuda
-V --version exibe 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 | Alvo |
|---|---|---|
| config_cache_reload | Recarrega o cache de configuração. Ignorado se o cache estiver sendo carregado no momento. O proxy ativo do Zabbix irá se conectar ao servidor Zabbix e solicitar os dados de configuração. O proxy passivo do Zabbix solicitará os dados de configuração ao servidor Zabbix na próxima vez que o servidor se conectar ao proxy. |
|
| history_cache_clear=alvo | 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. |
alvo - ID do item |
| diaginfo[=<seção>] | 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 vazio 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[=<alvo>] | Aumenta o nível de log, afeta todos os processos se o alvo não for especificado. Não suportado em sistemas BSD. |
tipo de processo - Todos os processos do tipo especificado (ex: poller) Veja todos os tipos de processos do proxy. tipo de processo,N - Tipo de processo e número (ex: poller,3) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o alvo como 'tipo de processo,N'. |
| log_level_decrease[=<alvo>] | Diminui o nível de log, afeta todos os processos se o alvo não for especificado. Não suportado em sistemas BSD. |
|
| prof_enable[=<alvo>] | Habilita o profiling. Afeta todos os processos se o alvo não for especificado. O profiling habilitado fornece detalhes de todos os rwlocks/mutexes por nome de função. |
tipo de processo - Todos os processos do tipo especificado (ex: history syncer) Veja todos os tipos de processos do proxy. tipo de processo,N - Tipo de processo e número (ex: history syncer,1) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o alvo como 'tipo de processo,N'. escopo - rwlock, mutex, processing podem ser usados com o tipo de processo e número (ex: history syncer,1,processing) ou todos os processos do tipo (ex: history syncer,rwlock) |
| prof_disable[=<alvo>] | Desabilita o profiling. Afeta todos os processos se o alvo não for especificado. |
tipo de processo - Todos os processos do tipo especificado (ex: history syncer) Veja todos os tipos de processos do proxy. tipo de processo,N - Tipo de processo e número (ex: history syncer,1) pid - Identificador do processo (1 a 65535). Para valores maiores, especifique o alvo como 'tipo de processo,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 alterações nas credenciais (por exemplo, devido a inconsistências de engineBoots/engineID ou dispositivos nã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 em 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 detalhes sobre a configuração do 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 de 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.
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 ao 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 do 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, gravando os dados não enviados no banco de dados se o proxy for parado, o buffer estiver cheio ou os dados estiverem muito antigos. Quando todos os valores forem gravados 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á utilizado, porém, não há proteção contra perda de dados. Se o proxy for parado ou a memória ficar cheia, 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, respectivamente, o tamanho do buffer de memória e a idade máxima dos dados no buffer.
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 possuem uma localidade UTF-8 como padrão, no entanto, existem alguns sistemas onde isso pode precisar ser definido especificamente.
O proxy Zabbix não tem conhecimento dos períodos de manutenção; consulte Cálculo das filas durante a manutenção para obter detalhes.