O server realiza a coleta por polling e o recebimento por trapping de dados, calcula triggers e envia notificações aos usuários. Ele é o componente central ao qual os agents e proxies do Zabbix reportam dados sobre a disponibilidade e a integridade dos sistemas. O server também pode 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 todos os dados de configuração, 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 Zabbix server básico é dividido em três componentes distintos; eles são: Zabbix server, frontend web 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 a API), ele é adicionado à tabela items no banco de dados. Depois, cerca de uma vez por minuto, o Zabbix server consultará a tabela 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 texto 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 server Zabbix:

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

Option	Description	Target
`config_cache_reload`	Recarrega o cache de configuração. Ignorado se o cache estiver sendo carregado no momento.
`history_cache_clear=target`	Limpa o cache de histórico do 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 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 (está vazia em sistemas BSD); `connector` - estatísticas dos 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 ativo/em espera 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 da 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 proxy separada por vírgulas. Se nenhum target for especificado, recarrega a configuração de todos os proxy.
`secrets_reload`	Recarrega os 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 engine SNMP (engine time, engine boots, engine id, credentials) 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 no momento.
`trigger_housekeeper_execute`	Inicia o procedimento de housekeeping de trigger. Ignorado se o procedimento de housekeeping de trigger estiver em andamento no momento. Até que o procedimento de housekeeping de trigger seja iniciado, problemas causados por triggers que tenham sido excluídos desde então ainda podem gerar problemas de serviço e atribuí-los aos serviços. Se sua configuração envolve muitas regras de cálculo de status de serviço baseadas em triggers descobertos/não descobertos com frequência, 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 target 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 processo do server. 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 target como 'process type,N'.
`log_level_decrease[=<target>]`	Diminui o nível de log, afeta todos os processos se o target não for especificado. Não suportado em sistemas BSD.
`prof_enable[=<target>]`	Ativa o profiling. Afeta todos os processos se o target não for especificado. O profiling ativado fornece detalhes de todos os rwlocks/mutexes por nome de função.	process type - todos os processos do tipo especificado (por exemplo, `history syncer`) Tipos de processo suportados como targets 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`. 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 target 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 com todos os processos do tipo (por exemplo, `history syncer,rwlock`).
`prof_disable[=<target>]`	Desativa o profiling. Afeta todos os processos se o target não for especificado.	process type - todos os processos do tipo especificado (por exemplo, `history syncer`). Tipos de processo suportados como targets de profiling: veja `prof_enable`. 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 target como 'process type,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 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 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 um 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

Consulte as opções do arquivo de configuração para obter 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 server

agent poller - processo 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 do host;
browser poller - poller para verificações de itens do 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 nos nomes dos itens;
connector manager - processo gerenciador de conectores;
connector worker - processo para tratar solicitações do connector manager;
discovery manager - processo gerenciador para descoberta de dispositivos;
discovery worker - processo para tratar tarefas de descoberta do discovery manager;
escalator - processo para escalonamento de ações;
ha manager - processo para gerenciar alta disponibilidade;
history poller - processo para tratar verificações calculadas que exigem uma conexão com o banco de dados;
history syncer - gravador de histórico no banco de dados;
housekeeper - processo para remover dados desatualizados (histórico e tendências de itens, sessões de usuário, eventos etc.), bem como dados deixados por objetos excluídos;
http agent poller - processo 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 gerar relatórios agendados;
self-monitoring - processo para coletar estatísticas internas do server;
service manager - processo para gerenciar serviços recebendo informações sobre problemas, tags de problema e recuperação de problema do history syncer, task manager e alert manager;
snmp poller - processo poller assíncrono para verificações SNMP com uma thread de trabalho (walk[OID] e get[OID] apenas);
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 o valor do item agora, funcionalidade de comando remoto);
timer - timer para processar manutenções;
trapper - trapper para verificações ativas, traps, comunicação com proxy;
trigger housekeeper - processo para remover problemas e eventos gerados por triggers que foram excluídos posteriormente;
unreachable poller - poller para dispositivos inacessíveis;
vmware collector - coletor de dados do VMware responsável pela coleta de dados dos serviços VMware.

O arquivo de log do server pode ser usado para observar esses tipos de processo.

Desde o Zabbix 7.4.6, o arquivo de log do server é criado com permissões de leitura e gravação apenas para o proprietário do arquivo. Além disso, o arquivo pode ser lido pelo grupo proprietário. Todas as outras permissões são negadas.

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

Estatísticas de transações 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 history;
B - triggers processados devido a temporizadores.

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 trends 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 servidor, 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 Zabbix server é 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 possui 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 Servidor

Visão geral