O server realiza a coleta por polling e o recebimento por trapping dos 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 disponibilidade e 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 server básico do Zabbix é 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 interagem. Por exemplo, quando você cria um novo item usando o frontend web (ou a API), ele é adicionado à tabela items no banco de dados. Em seguida, cerca de uma vez por minuto, o Zabbix server consultará a tabela items para obter uma lista dos items 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 procedimento acima não funcionar, você precisa 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 de runtime

Opções de controle de runtime:

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 active/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 proxy delimitada por vírgulas. Se nenhum target for especificado, recarrega a configuração de todos os proxy.
`secrets_reload`	Recarrega os secrets 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 do trigger. Ignorado se o procedimento de housekeeping do trigger estiver em andamento no momento.
`log_level_increase[=<target>]`	Aumenta o nível de log; afeta todos os processos se 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 processos 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 target não for especificado. Não suportado em sistemas BSD.
`prof_enable[=<target>]`	Ativa a profilagem. Afeta todos os processos se target não for especificado. A profilagem ativada 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 profilagem: `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 a profilagem. Afeta todos os processos se target não for especificado.	process type - todos os processos do tipo especificado (por exemplo, `history syncer`). Tipos de processo suportados como targets de profilagem: 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 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

Usuário do processo

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 com o qual 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 no seu sistema. Você só pode executar o server como 'root' se modificar adequadamente o parâmetro 'AllowRoot' no arquivo de configuração do server.

Se o Zabbix server e o agent forem executados na mesma máquina, recomenda-se usar um usuário diferente para executar o server e outro para executar o agent. Caso contrário, se ambos forem executados com o mesmo usuário, o agent poderá acessar o arquivo de configuração do server e qualquer usuário de nível Admin no Zabbix poderá recuperar com bastante facilidade, 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ção da disponibilidade do host;
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 nos nomes de item;
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 item, 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 do 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] items 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 valor de 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 tenham sido excluídos posteriormente;
unreachable poller - poller para dispositivos inacessíveis;
vmware collector - coletor de dados 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.

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 é legível pelo grupo do proprietário. Todas as outras permissões são negadas.

Vários tipos de processos do Zabbix server 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 os valores dos items no banco de dados;
Tempo gasto atualizando os dados do item (estado, erros, inventário do host, etc.);
Tempo gasto enviando trends para o banco de dados;
Tempo gasto calculando triggers;
Tempo gasto processando eventos e ações.

Procedimento de housekeeping

O processo housekeeper remove periodicamente dados desatualizados (histórico e tendências de item, sessões de usuário, eventos etc.), bem como dados deixados por objetos excluídos. Ele é executado em ciclos, com frequência e limite de exclusões por ciclo determinados por HousekeepingFrequency e MaxHousekeeperDelete. Quaisquer dados não removidos em um ciclo são transferidos para o próximo. O housekeeping automático pode ser habilitado e configurado em Administration > Housekeeping.

Para remover dados deixados por objetos excluídos, o processo housekeeper depende de tarefas da tabela housekeeper, que é preenchida sempre que um objeto é excluído. Por exemplo, quando você exclui um host, o Zabbix também exclui seus items, mas não o histórico, as tendências ou os problemas deles. Em vez disso, triggers do banco de dados preenchem a tabela housekeeper com tarefas compostas pelos seguintes campos:

housekeeperid - ID da tarefa
object - tipo de objeto (0 - item; 1 - trigger; 2 - service; 3 - host descoberto; 4 - service descoberto)
objectid - ID do objeto (ajuda o housekeeper a localizar dados relacionados ao objeto)

Por exemplo, excluir um host com dois items e uma trigger preenche a tabela housekeeper da seguinte forma:

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

As triggers do banco de dados preenchem a tabela housekeeper sem verificar dados relacionados ao objeto; essa verificação é feita pelo processo housekeeper.

Cada tarefa resulta em uma ou mais operações do housekeeper que dependem do tipo de objeto:

Para items (incluindo regras de LLD) - remove dados de todas as tabelas de histórico e tendências (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint) que contenham valores desses items. Também verifica a tabela problems e remove eventos internos desatualizados associados a esses items.
Para triggers - verifica tabelas relacionadas a eventos (problem, event_symptom, event_recovery, events) e remove eventos desatualizados associados a essas triggers, além de notificar o processo service manager sobre os eventos removidos.

Um processo separado trigger housekeeper trata de uma tarefa mais restrita — remover problems e eventos que não têm uma trigger de origem conhecida. Sua frequência de execução é controlada por ProblemHousekeepingFrequency.

Até que o procedimento de housekeeping de triggers seja iniciado, problems causados por triggers que já tenham sido excluídas ainda podem gerar problems de service e atribuí-los a services. Se sua configuração envolve muitas regras de cálculo de status de service com base em triggers descobertas/não descobertas com frequência, considere aumentar a frequência do procedimento de housekeeping ajustando o parâmetro de configuração do server ProblemHousekeepingFrequency.

Para services - verifica a tabela problems e remove eventos de service desatualizados, bem como problems de service desatualizados, resolvendo-os no momento do housekeeping.
Para descoberta de rede - remove eventos de descoberta desatualizados da tabela problems.

O housekeeper remove apenas os eventos que não estão associados a problems. Por exemplo, um evento de problem/recovery desatualizado não será removido se estiver associado a um problem em aberto. Quando o housekeeper remove entidades desatualizadas, ele primeiro remove problems e depois eventos.

Tabelas que usam o modo partition (tabelas particionadas do TimescaleDB) são ignoradas; apenas tabelas que usam o modo regular são processadas.

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.

What’s next?

1 Alta disponibilidade

Docs

1 Server

Visão geral