O server 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 server 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 server é 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 irá alertar ativamente os administradores quando surgirem problemas em qualquer um dos sistemas monitorados.

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

Todas as informações de configuração do Zabbix são armazenadas no banco de dados, com o qual tanto o server quanto o frontend web interagem. Por exemplo, quando você cria um novo item usando o frontend web (ou API), ele é adicionado à tabela de items no banco de dados. Então, cerca de uma vez por minuto, o Zabbix server consulta a tabela de items para obter uma lista dos items que estão ativos, que é então armazenada em um cache dentro do Zabbix server. É 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ê terá que 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 de tempo de execução

Opções de controle de 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 atualmente.
diaginfo[=<section>]	Coleta informações de diagnóstico no arquivo de log do server.	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=target	Remove o nó de alta disponibilidade (HA) especificado pelo nome ou ID. Observe que nós ativos/standby não podem ser removidos.	target - nome ou ID do nó (pode ser obtido executando ha_status)
ha_set_failover_delay=delay	Define o atraso de failover de alta disponibilidade (HA). Sufixos de tempo são suportados, por exemplo, 10s, 1m.
proxy_config_cache_reload[=<target>]	Recarrega o cache de configuração do proxy.	target - lista de nomes de proxies separados por vírgula Se nenhum alvo 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 de 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. Ignorado se o procedimento de housekeeping de trigger estiver em andamento. Até que o procedimento de housekeeping de trigger seja iniciado, problemas causados por triggers que foram 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 ajustando o parâmetro de configuração do server `ProblemHousekeepingFrequency`.
log_level_increase[=<target>]	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 (por exemplo, poller) Veja todos os tipos de processos do server. 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 alvo como 'tipo de processo,N'.
log_level_decrease[=<target>]	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[=<target>]	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 (por exemplo, history syncer) Tipos de processo suportados como alvos 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 alvo como 'tipo de processo,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 alvo não for especificado.	tipo de processo - Todos os processos do tipo especificado (por exemplo, history syncer) Tipos de processo suportados como alvos 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 alvo 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

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 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 for iniciado. 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' codificado, 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á recuperar facilmente, por exemplo, a senha do banco de dados.

Arquivo de configuração

Veja as opções do arquivo de configuração para detalhes sobre a configuração do 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 e threads do servidor

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 host
browser poller - poller para verificações de item 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 item
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 exigem conexão com o banco de dados
history syncer - gravador de histórico no banco de dados
housekeeper - processo para remoção de dados desatualizados (histórico e tendências de item, sessões de usuário, eventos, etc.), bem como dados deixados por objetos excluídos
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 proxy
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 e eventos gerados por triggers que foram excluídos posteriormente
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.

Desde o Zabbix 7.0.22, o arquivo de log do servidor é 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 servidor Zabbix podem ser monitorados usando o item interno zabbix[process,<type>,<mode>,<state>].

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, a tolerância a falhas e a 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 também pode funcionar em outros sistemas operacionais semelhantes ao 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 tem uma localidade UTF-8 como padrão, no entanto, há alguns sistemas em que isso pode precisar ser definido especificamente.

What’s next?

1 Alta disponibilidade

Docs

1 Server

Visão geral