Table of Contents

1 Server

1 Server

Visão geral

O servidor Zabbix é o processo central do software Zabbix.

O servidor realiza a coleta e o recebimento de dados, calcula triggers e envia notificações aos usuários. É o componente central para o qual os agents e proxies do Zabbix reportam dados sobre a disponibilidade e integridade dos sistemas. O servidor pode, ele mesmo, verificar remotamente serviços em rede (como servidores web e servidores de e-mail) usando verificações simples de serviço.

O servidor é o repositório central no qual todas as informações de configuração, dados estatísticos e operacionais são armazenados, e é a entidade no Zabbix que alertará ativamente os administradores quando surgirem problemas em qualquer um dos sistemas monitorados.

O funcionamento de um servidor Zabbix básico é dividido em três componentes distintos: servidor Zabbix, frontend web e armazenamento em banco de dados.

Todas as informações de configuração do Zabbix são armazenadas no banco de dados, com o qual tanto o servidor quanto o frontend web interagem. Por exemplo, quando você cria um novo item usando o frontend web (ou API), ele é adicionado à tabela de itens no banco de dados. Então, cerca de uma vez por minuto, o servidor Zabbix consulta a tabela de itens para obter uma lista dos itens que estão ativos, que é então armazenada em um cache dentro do servidor Zabbix. É por isso que pode levar até dois minutos para que quaisquer alterações feitas no frontend do Zabbix apareçam na seção de dados mais recentes.

Executando o server

Se instalado como pacote

O Zabbix server é executado como um processo daemon. O server pode ser iniciado executando:

systemctl start zabbix-server

Isso funcionará na maioria dos sistemas GNU/Linux. Em outros sistemas, pode ser necessário executar:

/etc/init.d/zabbix-server start

Da mesma forma, para parar/reiniciar/ver o status, use os seguintes comandos:

systemctl stop zabbix-server
       systemctl restart zabbix-server
       systemctl status zabbix-server

Iniciar manualmente

Se o acima não funcionar, você deve iniciá-lo manualmente. Encontre o caminho para o binário zabbix_server e execute:

zabbix_server

Você pode usar os seguintes parâmetros de linha de comando com o Zabbix server:

-c --config <file>              caminho para o arquivo de configuração (o padrão é /usr/local/etc/zabbix_server.conf)
       -f --foreground                 executa o Zabbix server 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ão

Exemplos de execução do Zabbix server com parâmetros de linha de comando:

zabbix_server -c /usr/local/etc/zabbix_server.conf
       zabbix_server --help
       zabbix_server -V

Controle em tempo de execução

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.
history_cache_clear=destino	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.	destino - ID do item
diaginfo[=<seção>]	Coleta informações de diagnóstico no arquivo de log do servidor.	historycache - estatísticas do cache de histórico valuecache - estatísticas do cache de valores preprocessing - estatísticas do gerenciador de pré-processamento alerting - estatísticas do gerenciador de alertas lld - estatísticas do gerenciador de LLD locks - lista de mutexes (fica vazia em sistemas BSD) connector - estatísticas para conectores com a maior fila
ha_status	Registra o status do cluster de alta disponibilidade (HA).
ha_remove_node=destino	Remove o nó de alta disponibilidade (HA) especificado pelo seu nome ou ID. Observe que nós ativos/standby não podem ser removidos.	destino - nome ou ID do nó (pode ser obtido executando ha_status)
ha_set_failover_delay=atraso	Define o atraso de failover de alta disponibilidade (HA). Sufixos de tempo são suportados, por exemplo, 10s, 1m.
proxy_config_cache_reload[=<destino>]	Recarrega o cache de configuração do proxy.	destino - lista de nomes de proxies separados por vírgula Se nenhum destino for especificado, recarrega a configuração de todos os proxies
secrets_reload	Recarrega segredos do Vault.
service_cache_reload	Recarrega o cache do gerenciador de serviços.
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 SNMP.
housekeeper_execute	Inicia o procedimento de housekeeping. Ignorado se o procedimento de housekeeping estiver em andamento.
trigger_housekeeper_execute	Inicia o procedimento de housekeeping de trigger para serviços para remover problemas causados por triggers que foram excluídos desde então, incluindo problemas de serviço gerados por tais problemas (considerados como resolvidos no momento do housekeeping). Observe que, até que o procedimento de housekeeping seja iniciado, problemas causados por triggers agora excluídos ainda podem gerar problemas de serviço e atribuí-los a serviços. Se sua configuração envolver muitas regras de cálculo de status de serviço baseadas em triggers frequentemente descobertos/não descobertos, considere aumentar a frequência do procedimento de housekeeping de trigger ajustando o parâmetro de configuração do servidor ProblemHousekeepingFrequency. Ignorado se o procedimento de housekeeping de trigger estiver em andamento.
log_level_increase[=<destino>]	Aumenta o nível de log, afeta todos os processos se o destino não for especificado. Não suportado em sistemas BSD.	tipo de processo - Todos os processos do tipo especificado (por exemplo, poller) Veja todos os tipos de processos do servidor. tipo de processo,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 'tipo de processo,N'.
log_level_decrease[=<destino>]	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[=<destino>]	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.	tipo de processo - Todos os processos do tipo especificado (por exemplo, history syncer) Tipos de processos suportados como destinos de profiling: alerter, alert manager, availability manager, configuration syncer, discovery manager, escalator, history poller, history syncer, housekeeper, http poller, icmp pinger, ipmi manager, ipmi poller, java poller, lld manager, lld worker, odbc poller, poller, preprocessing manager, preprocessing worker, proxy poller, self-monitoring, service manager, snmp trapper, task manager, timer, trapper, unreachable poller, vmware collector tipo de processo,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 'tipo de processo,N'. escopo - `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[=<destino>]	Desabilita o profiling. Afeta todos os processos se o destino não for especificado.	tipo de processo - Todos os processos do tipo especificado (por exemplo, history syncer) Tipos de processos suportados como destinos de profiling: veja `prof_enable` tipo de processo,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 'tipo de processo,N'.

Exemplo de uso do controle em tempo de execução para recarregar o cache de configuração do server:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

Exemplos de uso do controle em tempo de execução para recarregar a configuração do proxy:

# Recarregar a configuração de todos os proxies:
       zabbix_server -R proxy_config_cache_reload
           
       # Recarregar a configuração do Proxy1 e Proxy2:
       zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Exemplo de uso do controle em tempo de execução para limpar o cache de histórico de um item:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

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 server:
       zabbix_server -R diaginfo
       
       # Coletar estatísticas do cache de histórico no arquivo de log do server:
       zabbix_server -R diaginfo=historycache

Exemplo de uso do controle em tempo de execução para recarregar o cache SNMP:

zabbix_server -R snmp_cache_reload

Quando uma interface SNMPv3 é atualizada pela interface web do Zabbix, o Zabbix 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 as alterações de credenciais (por exemplo, devido a inconsistências de engineBoots/engineID ou dispositivos que não seguem o RFC), ou quando você precisar forçar uma limpeza global do cache SNMP para fins de troubleshooting.

Exemplo de uso do controle em tempo de execução para acionar a execução do housekeeper:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

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_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
       
       # Aumentar o nível de log do segundo processo poller:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
       
       # Aumentar o nível de log do processo com PID 1234:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234
       
       # Diminuir o nível de log de todos os processos http poller:
       zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Exemplo de definição do atraso de failover do HA para o mínimo de 10 segundos:

zabbix_server -R ha_set_failover_delay=10s

Processo do usuário

O Zabbix server foi projetado para ser executado como um usuário não-root. Ele será executado como qualquer usuário não-root que o iniciar. Portanto, você pode executar o server 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 server como 'root' se modificar o parâmetro 'AllowRoot' no arquivo de configuração do server de acordo.

Se o Zabbix server e o agent forem executados na mesma máquina, é recomendável usar um usuário diferente para executar o server do que para executar o agent. Caso contrário, se ambos forem executados como o mesmo usuário, o agent poderá acessar o arquivo de configuração do server e qualquer usuário com nível de Admin no Zabbix poderá, com relativa facilidade, recuperar, por exemplo, a senha do banco de dados.

Arquivo de configuração

Veja as opções do arquivo de configuração para obter detalhes sobre como configurar o zabbix_server.

Scripts de inicialização

Os scripts são usados para iniciar/parar automaticamente os processos do Zabbix durante a inicialização/desligamento do sistema. Os scripts estão localizados no diretório misc/init.d.

Tipos de processos do servidor e threads

agent poller - processo de poller assíncrono para verificações passivas com uma thread de trabalho
alert manager - gerenciador da fila de alertas
alert syncer - gravador de alertas no banco de dados
alerter - processo para envio de notificações
availability manager - processo para atualizações de disponibilidade de hosts
browser poller - poller para verificações de itens de navegador
configuration syncer - processo para gerenciar o cache em memória dos dados de configuração
configuration syncer worker - processo para resolver e sincronizar valores de macros de usuário em nomes de itens
connector manager - processo gerenciador de conectores
connector worker - processo para lidar com solicitações do gerenciador de conectores
discovery manager - processo gerenciador de descoberta de dispositivos
discovery worker - processo para lidar com tarefas de descoberta do discovery manager
escalator - processo para escalonamento de ações
ha manager - processo para gerenciamento de alta disponibilidade
history poller - processo para lidar com verificações calculadas que requerem conexão com o banco de dados
history syncer - gravador de histórico no banco de dados
housekeeper - processo para remoção de dados históricos antigos
http agent poller - processo de poller assíncrono para verificações HTTP com uma thread de trabalho
http poller - poller de monitoramento web
icmp pinger - poller para verificações icmpping
internal poller - poller para verificações internas
ipmi manager - gerenciador de poller IPMI
ipmi poller - poller para verificações IPMI
java poller - poller para verificações Java
lld manager - processo gerenciador de tarefas de descoberta de baixo nível
lld worker - processo de trabalho de tarefas de descoberta de baixo nível
odbc poller - poller para verificações ODBC
poller - poller normal para verificações passivas
preprocessing manager - gerenciador de tarefas de pré-processamento com threads de trabalho de pré-processamento
preprocessing worker - thread para pré-processamento de dados
proxy poller - poller para proxies passivos
proxy group manager - gerenciador de balanceamento de carga e alta disponibilidade de proxies
report manager- gerenciador de tarefas de geração de relatórios agendados
report writer - processo para geração de relatórios agendados
self-monitoring - processo para coleta de estatísticas internas do servidor
service manager - processo para gerenciar serviços recebendo informações sobre problemas, tags de problemas e recuperação de problemas do history syncer, task manager e alert manager
snmp 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 SNMP
task 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)
timer - temporizador para processamento de manutenções
trapper - trapper para verificações ativas, traps, comunicação com proxy
trigger housekeeper - processo para remoção de problemas gerados por triggers que foram excluídos
unreachable poller - poller para dispositivos inacessíveis
vmware collector - coletor de dados VMware responsável pela coleta de dados de serviços VMware

O arquivo de log do servidor pode ser usado para observar esses tipos de processos.

Vários tipos de processos do servidor Zabbix podem ser monitorados usando o item interno zabbix[process,<type>,<mode>,<state>].

Estatísticas de transação do history syncer

O título do processo history syncer exibe estatísticas detalhadas sobre as transações do history syncer:

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
       205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
       205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

Em "A+B triggers":

A - triggers processados devido a valores de histórico;
B - triggers processados devido a timers.

Os tempos, em "processed...in N (<timings>) sec", são:

Tempo gasto gravando valores de item no banco de dados;
Tempo gasto atualizando dados do item (estado, erros, inventário do host, etc);
Tempo gasto gravando tendências no banco de dados;
Tempo gasto calculando triggers;
Tempo gasto processando eventos e ações.

Plataformas suportadas

Devido aos requisitos de segurança e à natureza crítica da operação do server, o UNIX é o único sistema operacional que pode fornecer consistentemente o desempenho, tolerância a falhas e resiliência necessários. O Zabbix opera nas versões líderes de mercado.

O server Zabbix é testado nas seguintes plataformas:

Linux
Solaris
AIX
HP-UX
Mac OS X
FreeBSD
OpenBSD
NetBSD
SCO Open Server

O Zabbix pode funcionar em outros sistemas operacionais do tipo Unix.

Localidade

Observe que o server 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.

Documentation