Uma verificação de atualização de software agora é adicionada por padrão a instalações novas e existentes - o frontend do Zabbix se comunicará com o endpoint público do Zabbix para verificar atualizações.

As notícias sobre atualizações de software Zabbix disponíveis são exibidas em Relatórios -> Informações do sistema e (opcionalmente) no widget Informações do sistema do dashboard.

Você pode desabilitar a verificação de atualização de software definindo AllowSoftwareUpdateCheck=0 na configuração do server.

Pollers assíncronos

Novos processos de poller foram adicionados, capazes de executar várias verificações ao mesmo tempo:

agent poller
http agent poller
snmp poller (para itens walk[OID] e get[OID])

Esses pollers são assíncronos - eles são capazes de iniciar novas verificações sem a necessidade de esperar por uma resposta, com concorrência configurável de até 1000 verificações simultâneas.

Os pollers assíncronos foram desenvolvidos porque, em comparação, os processos de poller síncronos podem executar apenas uma verificação ao mesmo tempo e a maior parte do tempo é gasta esperando pela resposta. Assim, a eficiência pode ser aumentada iniciando novas verificações paralelas enquanto se aguarda a resposta da rede, e os novos pollers fazem isso.

Você pode iniciar pollers assíncronos de agent modificando o valor de StartAgentPollers - um novo parâmetro do server/proxy. Os pollers de HTTP agent podem ser iniciados modificando StartHTTPAgentPollers respectivamente. Os pollers de SNMP podem ser iniciados modificando StartSNMPPollers respectivamente.

A concorrência máxima para pollers assíncronos (agent, HTTP agent e SNMP) é definida por MaxConcurrentChecksPerPoller.

Observe que após a atualização todas as verificações de agent, HTTP agent e SNMP walk[OID] serão movidas para pollers assíncronos.

Como parte do desenvolvimento, o recurso de conexões persistentes do cURL foi adicionado às verificações de HTTP agent.

Monitoramento de navegador

Um novo tipo de item - Item de navegador - foi adicionado ao Zabbix, permitindo o monitoramento de sites e aplicações web complexas usando um navegador. Os itens de navegador permitem a execução de código JavaScript definido pelo usuário para simular ações relacionadas ao navegador, como clicar, inserir texto, navegar por páginas da web, etc.

Este item coleta dados via HTTP/HTTPS e implementa parcialmente o padrão W3C WebDriver com Selenium Server ou um WebDriver simples (por exemplo, ChromeDriver) como endpoint de teste.

Observe que o suporte a itens de navegador é atualmente experimental.

Além disso, este recurso adiciona o template Website by Browser e novos elementos para exportação/importação de configuração, arquivos de configuração do Zabbix server/proxy, timeouts e a ferramenta de linha de comando zabbix_js. Para mais informações, consulte Notas de atualização para 7.0.0.

Balanceamento de carga e alta disponibilidade do proxy

O balanceamento de carga do proxy é implementado por meio da introdução de grupos de proxies no Zabbix. Os grupos de proxies fornecem distribuição automática de hosts entre proxies, redistribuição da carga entre proxies e alta disponibilidade: quando um proxy fica offline, seus hosts são imediatamente distribuídos entre os outros proxies do grupo.

Para obter mais informações, consulte balanceamento de carga e alta disponibilidade do proxy.

Buffer de memória do proxy

Um buffer de memória foi desenvolvido para o proxy do Zabbix. O buffer de memória permite armazenar novos dados (valores de item, descoberta de rede e registro automático de hosts) no buffer e enviá-los ao server do Zabbix sem acessar o banco de dados.

Nas instalações anteriores ao Zabbix 7.0, os dados coletados eram armazenados no banco de dados antes de serem enviados ao server do Zabbix. Nessas instalações, esse continua sendo o comportamento padrão após a atualização.

Para obter um desempenho otimizado, recomenda-se configurar o uso do buffer de memória no proxy. Isso é possível modificando o valor de ProxyBufferMode de "disk" (padrão definido no código 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, descarregando os dados não enviados no banco de dados quando o proxy é interrompido, o buffer está cheio ou os dados estão muito antigos. Quando todos os valores tiverem sido descarregados 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á usado; no entanto, não há proteção contra perda de dados. Se o proxy for interrompido 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 desde o 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.

Novos itens internos foram adicionados para monitorar o buffer de memória do proxy.

Provisionamento de usuários JIT

Anteriormente, os usuários provisionados ficavam limitados apenas às mídias criadas durante o provisionamento, sem flexibilidade para editar propriedades como horário de atividade ou severidades.

Agora, há mais flexibilidade para os usuários provisionados no Zabbix:

a mídia do usuário provisionada pode ser desabilitada/habilitada;
os campos da mídia do usuário provisionada, como Quando ativo, Usar se a severidade e Habilitado, podem ser editados manualmente;
mídias adicionais do usuário podem ser adicionadas manualmente aos usuários provisionados (por exemplo, endereços de e-mail adicionais);
as mídias do usuário adicionadas manualmente podem ser excluídas (as mídias provisionadas do usuário não podem ser excluídas).

Além disso, ao configurar o mapeamento de mídias do usuário para o provisionamento, campos como Quando ativo, Usar se a severidade e Habilitado agora estão disponíveis. Observe que as alterações no formulário de mapeamento do tipo de mídia do usuário entrarão em vigor somente para novas mídias criadas durante o provisionamento.

Timeouts configuráveis por item

A configuração de timeout por item agora está disponível para mais tipos de item (veja os tipos de item suportados). Além de definir os valores de timeout no nível do item, é possível definir timeouts globais e de proxy para vários tipos de item.

Os timeouts configurados no nível do item têm a maior prioridade. Por padrão, os timeouts globais são aplicados a todos os itens; no entanto, se os timeouts de proxy forem definidos, eles substituirão os globais.

Oracle DB obsoleto

O suporte ao Oracle como banco de dados backend foi descontinuado e espera-se que seja completamente removido em versões futuras.

Protocolo JSON para verificações passivas do agent

Foi implementado um protocolo baseado em JSON para verificações passivas do agent.

Para garantir a compatibilidade com agents mais antigos, foi adicionada uma alternativa ao protocolo de texto simples antigo. Se o agent retornar "ZBX_NOTSUPPORTED", o Zabbix armazenará em cache a interface como usando o protocolo antigo e tentará novamente a verificação enviando apenas a chave do item em texto simples.

O Zabbix get agora pode ser executado com uma nova opção -P --protocol <value>, em que "value" pode ser:

auto - conecta usando o protocolo JSON; em caso de falha, tenta novamente usando o protocolo de texto simples (padrão);
json - conecta usando a chave do protocolo JSON;
plaintext - conecta usando o protocolo de texto simples, no qual somente a chave do item é enviada.

Se uma chave de item não for compatível, o Zabbix get retornará o código de saída 1.

Protocolos unificados do agent/agent2

Os protocolos do Zabbix agent e do agent 2 foram unificados com a mudança do Zabbix agent para o protocolo do Zabbix agent 2. A diferença entre as solicitações/respostas do Zabbix agent e do Zabbix agent 2 é expressa pelo valor da tag "variant" ("1" - Zabbix agent, "2" - Zabbix agent 2).

Veja também: Verificações passivas e ativas do agent.

Suporte a intervalos flexíveis/agendados em checagens ativas

Intervalos flexíveis/agendados agora são suportados em checagens ativas tanto pelo Zabbix agent quanto pelo Zabbix agent 2 (anteriormente apenas pelo Zabbix agent 2).

Desativação automática de recursos perdidos

Os recursos que não são mais descobertos pela descoberta de baixo nível agora podem ser desativados automaticamente. Eles podem ser desativados imediatamente, após um período especificado ou nunca (consulte o novo parâmetro Desativar recursos perdidos na configuração da regra de descoberta).

Os recursos perdidos (hosts, items, triggers) são marcados por um ícone na coluna de informações. O texto da dica de ferramenta fornece detalhes sobre o status deles.

No mesmo desenvolvimento, o parâmetro Período para manter recursos perdidos foi renomeado para Excluir recursos perdidos, com opções para excluir imediatamente, após um período especificado ou nunca.

Enviando dados para o Zabbix server via API do Zabbix

Anteriormente, era possível enviar dados específicos para o Zabbix server usando o utilitário Zabbix sender ou implementando um protocolo de comunicação personalizado baseado em JSON, semelhante ao usado pelo Zabbix sender.

Agora também é possível enviar dados para o Zabbix server via protocolo HTTP usando o método de API history.push. Observe que, para receber os dados enviados, é necessário ter um item trapper configurado ou um item HTTP agent (com o trapping habilitado).

Além disso, as operações history.push corretas são registradas em Reports → Audit log, que possui opções adicionais de filtragem (uma nova ação Push e o recurso History). O método de API history.push também está disponível na Allow/Deny list de métodos de API ao configurar uma função de usuário.

Scripts

Execução de scripts em agents ativos

Agora é possível executar scripts em agents que operam no modo ativo. Quando a execução do script é acionada por uma operação de uma ação ou pela execução manual de um script, o comando é incluído na configuração das verificações ativas e executado assim que o agent ativo o recebe.

Os scripts manuais são enviados ao agent ativo junto com o tempo limite do server/proxy para a execução do script. Aumente o tempo limite padrão do server/proxy para a execução de scripts. O tempo limite deve ser maior que a frequência de atualização das verificações ativas; caso contrário, ele será excedido antes que o agent ativo receba o script e consiga retornar o resultado.

Observe que agents ativos mais antigos ignoram quaisquer comandos remotos incluídos na configuração das verificações ativas. Para obter mais informações, consulte Verificações passivas e ativas do agent.

Entrada manual do usuário para scripts

A entrada manual do usuário para scripts do frontend permite fornecer um parâmetro personalizado a cada execução do script. Isso elimina a necessidade de criar vários scripts de usuário semelhantes, com diferença em apenas um parâmetro.

Por exemplo, você pode querer fornecer um número inteiro diferente ou um endereço URL diferente ao script durante a execução.

Para habilitar a entrada manual do usuário:

use a macro {MANUALINPUT} no script (comandos, script, parâmetro do script) onde necessário; ou no campo URL de scripts de URL;
na configuração avançada do script, habilite a entrada manual do usuário e configure as opções de entrada:

Com a entrada do usuário habilitada, antes da execução do script, uma janela pop-up Entrada manual será exibida, solicitando que o usuário forneça um valor personalizado. O valor fornecido substituirá {MANUALINPUT} no script.

Dependendo da configuração, o usuário deverá inserir um valor de texto ou selecionar o valor em uma lista suspensa com opções predefinidas.

Desempenho

Reação mais rápida à atualização do período de manutenção do host

Anteriormente, as manutenções eram recalculadas somente a cada minuto, o que podia causar uma latência de até 60 segundos para iniciar ou interromper um período de manutenção.

Agora, as manutenções continuam sendo recalculadas a cada minuto ou assim que o cache de configuração é recarregado, caso haja alterações no período de manutenção.

A cada segundo, o processo timer verifica se alguma manutenção deve ser iniciada/interrompida com base na existência de alterações nos períodos de manutenção após a atualização da configuração. Assim, a velocidade de início/interrupção dos períodos de manutenção depende do intervalo de atualização da configuração (10 segundos por padrão). Observe que as alterações no período de manutenção não incluem as configurações Active since/Active till. Além disso, se um host/grupo de hosts for adicionado a um período de manutenção ativo existente, as alterações só serão ativadas pelo processo timer no início do próximo minuto.

Verificações de permissões mais rápidas

As verificações de permissões ficaram muito mais rápidas com a introdução de várias tabelas intermediárias para verificar as permissões de usuários não privilegiados.

Essas tabelas mantêm hashes (SHA-256) dos conjuntos de grupos de usuários e dos conjuntos de grupos de hosts para cada usuário/host, respectivamente. Além disso, há uma tabela de permissões que armazena apenas as combinações acessíveis de usuários e hosts, especificadas pelos IDs dos hashes.

Essa melhoria torna muito mais rápido o carregamento de páginas do frontend que exigem muitas permissões (ou seja, hosts e problemas). Observe que hashes e permissões não são calculados para usuários Super-admin.

Execução mais rápida de ações de trigger

A execução de operações de ação de trigger, operação de recuperação e operação de atualização no Zabbix server agora ocorre imediatamente (menos de 100 milissegundos) após uma alteração no status do trigger, enquanto anteriormente os usuários podiam experimentar até 4 segundos de latência.

A redução da latência é possível graças à implementação de mecanismos de comunicação entre processos (IPC) entre vários processos (escalator e seu módulo escalation-dispatch, escalator e alerter, preprocessing manager e history syncer).

Widgets

Vários novos widgets foram adicionados na nova versão, enquanto a funcionalidade disponível em outros foi aprimorada. Além disso, agora os widgets do painel podem se conectar e se comunicar entre si, tornando os widgets e os painéis mais dinâmicos.

Medidor

Um widget Medidor foi adicionado aos widgets do dashboard, permitindo exibir o valor de um único item como um medidor. Para mais informações, consulte Medidor.

Gráfico de pizza

Um widget de Gráfico de pizza foi adicionado aos widgets do dashboard, permitindo exibir valores de itens selecionados como:

gráfico de pizza;
gráfico de rosca.


Gráfico de pizza.	Gráfico de rosca.

Para mais informações, consulte Gráfico de pizza.

Como parte deste desenvolvimento, uma caixa de seleção Exibir função de agregação foi adicionada à configuração do widget gráfico (na aba Legenda).

Honeycomb

Um widget Honeycomb foi adicionado aos widgets do dashboard, que oferece uma visão geral dinâmica e vibrante da infraestrutura e dos recursos de rede monitorados, onde grupos de hosts, como máquinas virtuais e dispositivos de rede, juntamente com seus respectivos items, são representados visualmente como células hexagonais interativas. Para mais informações, consulte Honeycomb.

Principais triggers

Um widget de Principais triggers foi adicionado aos widgets do dashboard, permitindo visualizar os triggers com o maior número de problemas.

Para obter mais informações, consulte: Principais triggers.

Histórico do item e Texto simples

O novo widget do dashboard Histórico do item substituiu o widget Texto simples, oferecendo várias melhorias.

Diferentemente do widget Texto simples, que exibia apenas os dados mais recentes do item em texto simples, o widget Histórico do item oferece suporte a várias opções de exibição para diversos tipos de item (numérico, caractere, log, texto e binário). Por exemplo, ele pode exibir barras de progresso ou indicadores, imagens para tipos de dados binários (útil para itens de navegador) e destacar valores de texto (útil para o monitoramento de arquivos de log).

Para obter mais informações, consulte Histórico do item. Para obter detalhes sobre a substituição do widget Texto simples, consulte Notas de atualização para 7.0.0.

Navegador de host e Navegador de item

Os widgets Navegador de host e Navegador de item foram adicionados aos widgets do dashboard. Esses widgets exibem hosts ou items, respectivamente, com base em várias opções de filtragem e agrupamento, e permitem controlar as informações exibidas em outros widgets com base no host ou item selecionado. Para mais informações, consulte Navegador de host e Navegador de item.

Framework de comunicação para widgets

Os widgets do dashboard agora podem se conectar e se comunicar entre si, tornando os widgets e os dashboards mais dinâmicos. Vários widgets têm parâmetros que permitem compartilhar dados de configuração entre widgets compatíveis ou com o dashboard.

Este recurso introduz as seguintes alterações:

Os parâmetros Host groups, Hosts e Item permitem selecionar as respectivas entidades ou uma fonte de dados que as forneça.
O parâmetro Enable host selection foi substituído pelo parâmetro Override host, que permite selecionar uma fonte de dados que forneça hosts.
O parâmetro Time period foi adicionado a vários widgets, permitindo selecionar uma fonte de dados que forneça um período de tempo.
O parâmetro Map no widget Map permite selecionar um mapa ou outro widget como fonte de dados para mapas.
O parâmetro Graph no widget Graph (classic) permite selecionar um gráfico ou outro widget como fonte de dados para gráficos.

Dependendo do widget e de seus parâmetros, a fonte de dados pode ser um widget compatível do mesmo dashboard ou o próprio dashboard. Para obter mais informações, consulte Dashboard widgets.

Para obter informações sobre as alterações nos templates padrão distribuídos com o Zabbix, consulte Template changes.

Períodos de tempo para agregação nos widgets de valor do item e hosts principais

Agora é possível configurar períodos de tempo nos widgets Valor do item e Hosts principais.

Também é possível exibir um valor agregado no widget de valor do item para o período selecionado. O valor agregado pode ser exibido como:

mínimo
máximo
média
contagem
soma
primeiro
último

Esses recursos adicionais são úteis para criar widgets de comparação de dados. Por exemplo, em um widget, você pode exibir o valor mais recente, enquanto em outro exibe o valor médio de um período mais longo. Ou vários widgets podem ser usados para comparar lado a lado valores agregados de vários períodos no passado.

Disponibilidade expandida de widgets em dashboards de template

Anteriormente, em um dashboard de template, era possível criar apenas os seguintes widgets: Clock, Graph (classic), Graph prototype, Item value, Plain text, URL.

Agora, os dashboards de template suportam a criação de todos os widgets.

Agora, além de ordenar por Item value, também é possível definir a coluna Host name ou Text como coluna de ordenação no widget Top hosts.

O widget Disponibilidade de hosts agora permite exibir os hosts com a interface Zabbix agent (active checks). Mais um status de disponibilidade foi adicionado: Misto, que corresponde à situação em que pelo menos uma interface está indisponível e pelo menos uma está disponível ou desconhecida. Além disso, foi introduzida a possibilidade de visualizar apenas o total de hosts, sem detalhamento por interfaces.

O widget Gráfico agora suporta a configuração de um número variável de linhas de legenda determinado pelo número de items configurados.

Funções

Novas funções

Novas funções foram adicionadas para uso em expressões de trigger e itens calculados:

jsonpath() - retorna o resultado do JSONPath;
xmlxpath() - retorna o resultado do XML XPath.

Veja também: Funções de string

Funções atualizadas

Várias funções foram atualizadas:

As funções de agregação agora também oferecem suporte a tipos não numéricos para cálculos. Isso pode ser útil, por exemplo, com as funções count e count_foreach.
As funções de agregação count e count_foreach oferecem suporte aos parâmetros opcionais operator e pattern, que podem ser usados para ajustar o filtro de itens e contar apenas os valores que correspondem aos critérios especificados.
Todas as funções foreach não incluem mais itens sem suporte na contagem.
A função last_foreach, anteriormente configurada para ignorar o argumento de período de tempo, aceita-o como um parâmetro opcional.
O intervalo compatível com os valores retornados pelas funções de previsão foi ampliado para corresponder ao intervalo do tipo de dados double. Agora, a função timeleft() pode aceitar valores de até 1.7976931348623158E+308, e a função forecast() pode aceitar valores no intervalo de -1.7976931348623158E+308 a 1.7976931348623158E+308.

Items

Período padrão consistente para armazenamento do histórico

O período padrão para manter o histórico do item foi padronizado em 31 dias no frontend e no banco de dados. Essa alteração afeta os formulários de configuração de item, item de template e protótipo de item, bem como a substituição do período de armazenamento do histórico na descoberta de baixo nível.

Valores de ponto flutuante truncados para itens inteiros

Agora, se um valor de ponto flutuante for recebido para um item de inteiro sem sinal, o valor terá a parte decimal truncada e será salvo como um inteiro. Anteriormente, um valor de ponto flutuante tornava um item de inteiro sem suporte.

Contagem de linhas no log de eventos do Windows

Um novo item eventlog.count foi adicionado ao agent/agent 2 do Zabbix no Windows. Este item retorna um valor inteiro com a contagem de linhas no log de eventos do Windows com base nos parâmetros especificados.

Requisições SNMP assíncronas de OID único

Um novo item SNMP get[OID] foi adicionado, permitindo consultar o valor de um único OID de forma assíncrona.

Itens internos

As verificações internas agora são tratadas por um novo processo internal poller do Zabbix server/proxy.

Foram adicionados itens internos para monitorar o buffer de memória do proxy:

zabbix[proxy_buffer,buffer,<mode>] - retorna as estatísticas de uso do buffer de memória do proxy;
zabbix[proxy_buffer,state,changes] - retorna o número de mudanças de estado entre os modos de buffer em disco/memória desde a inicialização;
zabbix[proxy_buffer,state,current] - retorna o estado de funcionamento atual em que os novos dados estão sendo armazenados.

Os seguintes itens internos também foram adicionados:

zabbix[discovery_queue] - permite monitorar o número de verificações de descoberta na fila;
zabbix[vps,written] - permite monitorar o número total de valores de histórico gravados no banco de dados.

Itens novos e atualizados do agent

Novos itens foram adicionados ao Zabbix agent/agent 2:

O item net.dns.perf retorna o número de segundos gastos aguardando uma resposta de um serviço, cronometrando a execução do item net.dns.
O item net.dns.get do Zabbix agent 2 retorna informações detalhadas sobre registros DNS.

Os seguintes itens do Zabbix agent/agent 2 foram atualizados:

Os itens net.dns e net.dns.record agora aceitam o nome DNS nos formatos reverso e não reverso ao realizar consultas DNS reversas;
Os itens proc.get nos modos "process" e "summary" agora também retornam a memória PSS (tamanho proporcional do conjunto) no Linux;
Os itens system.sw.packages e system.sw.packages.get agora são compatíveis com o Gentoo Linux;
O item system.hostname agora pode retornar um nome de domínio totalmente qualificado, se a nova opção fqdn for especificada no parâmetro type;
Os itens wmi.get e wmi.getall usados com o Zabbix agent 2 agora retornam JSON com valores booleanos representados como strings (por exemplo, "RealTimeProtectionEnabled": "True" em vez de "RealTimeProtectionEnabled": true, retornado anteriormente), para corresponder ao formato de saída desses itens no Zabbix agent;
O item oracle.ts.discovery do Zabbix agent 2 agora retorna uma nova macro LLD {#CON_NAME} com o nome do container;
O item oracle.ts.stats do Zabbix agent 2 agora tem um novo parâmetro conname para especificar o nome do container de destino.

O formato JSON dos dados retornados foi atualizado. Quando nenhum tablespace, type ou conname é especificado nos parâmetros da chave, os dados retornados incluirão um nível JSON adicional com o nome do container, permitindo diferenciar os containers.

Verificações simples

O item vmware.eventlog agora oferece suporte à filtragem opcional por gravidade no terceiro parâmetro.

O item vmware.vm.discovery agora também retorna dados sobre as interfaces de rede das máquinas virtuais. Esses dados podem ser usados para configurar interfaces de host personalizadas.

O item vmware.vm.net.if.discovery agora também retorna uma matriz de endereços de interfaces de rede.

Um novo parâmetro options foi adicionado aos seguintes itens:

Esse parâmetro pode ser usado para especificar se as respostas redirecionadas devem ser tratadas como host de destino ativo ou host de destino inativo. Consulte verificações simples para obter mais detalhes.

Registro de Engine IDs SNMPv3 duplicados

Os Engine IDs no SNMPv3 são usados como identificadores exclusivos do dispositivo. Às vezes, os Engine IDs são iguais em vários dispositivos devido a uma configuração incorreta ou às configurações de fábrica. Como os padrões SNMP exigem que os Engine IDs sejam exclusivos, os itens que compartilham o mesmo Engine ID tornam-se sem suporte no Zabbix, causando problemas de disponibilidade nesses dispositivos.

Para ajudar a solucionar esses problemas, as informações sobre dispositivos SNMPv3 que compartilham o mesmo Engine ID agora serão registradas periodicamente pelo Zabbix server. Observe que a detecção de Engine IDs duplicados funciona separadamente em cada coletor SNMP.

Link de documentação para cada item padrão

Cada item padrão agora possui um link direto do frontend para sua página de documentação.

Os links são colocados sob o ícone de ponto de interrogação, ao abrir a janela de ajuda do item a partir do formulário de configuração do item (clique em Selecionar ao lado do campo de chave do item).

Pré-processamento

Tratamento avançado da causa raiz para o estado de item não suportado

O tratamento de erros em caso de falha ao obter o valor de um item (fazendo com que ele se torne não suportado) anteriormente não permitia distinguir o motivo ou a etapa de execução em que o processo falhou.
Todos os erros tinham de ser tratados usando uma única opção de tratamento de erros: descartar o valor, definir um valor especificado ou definir uma mensagem de erro especificada.

Agora é possível comparar a mensagem de erro com uma expressão regular.
Se o erro corresponder (ou não corresponder), é possível especificar como o caso de erro deve ser processado.
Por exemplo, uma mensagem de erro específica pode ser "mapeada" para um caso mais geral, que será comparado e tratado por uma etapa de pré-processamento posterior. Como alternativa, um problema intermitente (por exemplo, de conectividade de rede) pode ser tratado de forma diferente de uma falha definitiva ao obter o valor do item.

Agora é possível adicionar várias etapas de pré-processamento Verificar valor não suportado.
Observe que pode haver apenas uma etapa de correspondência "qualquer erro" no final do pipeline que verifica o estado não suportado do item.
Se estiver presente, ela será ativada se nenhuma das verificações específicas corresponder (ou não corresponder) ao padrão correspondente, ou se uma mensagem de erro (modificada) tiver sido encaminhada, ou seja, se nenhuma substituição "Descartar valor" ou "Definir valor como" tiver entrado em vigor.

Veja também: Verificar valor não suportado

Melhor usabilidade para a atualização em massa das etapas de pré-processamento

O design anterior do formulário de atualização em massa de item não deixava suficientemente claro se a atualização da etapa de pré-processamento adicionaria ou substituiria as etapas de pré-processamento. No novo design, foram adicionados os botões de opção Substituir e Remover tudo, deixando claro para os usuários o que esperar como resultado da atualização em massa da etapa de pré-processamento:

Macros

Macros de usuário compatíveis com nomes de item e de protótipo de item

Agora, as macros de usuário são compatíveis com nomes de item e de protótipo de item.

Observe que o suporte a macros de usuário foi removido dos nomes de item/protótipo de item no Zabbix 6.0. Agora, ele foi restaurado. Também passou a ser possível pesquisar o nome do item com as macros resolvidas, o que anteriormente não era compatível.

O nome do item com as macros resolvidas é armazenado em uma tabela de banco de dados separada (item_rtname), que é uma extensão da tabela items. Para cada registro na tabela items, é criado um registro correspondente em item_rtname (exceto para protótipos de item, itens de regras de descoberta e itens de template). O nome com as macros resolvidas é limitado a 2048 caracteres.

O nome do item com as macros resolvidas é exibido em todos os locais do frontend, exceto na seção Coleta de dados.

Foi adicionado um novo processo do server, configuration syncer worker, responsável por resolver e sincronizar os valores das macros de usuário nos nomes dos itens.

Suporte ampliado a funções de macro

As funções de macro agora são compatíveis com todos os tipos de macros:

As funções de macro podem ser usadas em todos os locais compatíveis com as macros listadas. Isso se aplica, exceto quando for explicitamente indicado que apenas uma macro é esperada (por exemplo, ao configurar macros de host ou filtros de regras de descoberta de baixo nível).

Relatórios agendados

A funcionalidade de relatórios agendados não é mais experimental.

Relatórios com várias páginas

Para dashboards com várias páginas, os relatórios agora são retornados com todas as páginas do dashboard, sendo que cada página do PDF corresponde a uma página do dashboard. Anteriormente, essa funcionalidade limitava-se a retornar apenas a primeira página do dashboard.

Notificações

Suporte ao processamento de tags para eventos internos

O processamento de tags retornadas pelo script webhook agora também é suportado para eventos internos.

Além disso, os macros {EVENT.TAGS.<tag name>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} agora são suportados para notificações de eventos internos.

Essas alterações permitem o uso de webhooks para atualizar ou fechar um chamado externo/suporte por meio de uma notificação de recuperação de evento interno.

Bancos de dados

Auditlog convertido em hypertable no TimescaleDB

A tabela auditlog foi convertida em hypertable no TimescaleDB em novas instalações para se beneficiar do particionamento automático por tempo (7 dias por padrão) e de melhor desempenho.

Para atualizar instalações existentes com sucesso, consulte Atualizando o esquema do TimescaleDB.

Veja também: Versões compatíveis do TimescaleDB

Tabela de banco de dados separada para proxies

Os registros de proxy foram removidos da tabela hosts e agora são armazenados na nova tabela proxy.

Além disso, os dados operacionais dos proxies (como último acesso, versão e compatibilidade) foram removidos da tabela host_rtdata e agora são armazenados na nova tabela proxy_rtdata.

Processos

Multithreading

Várias alterações foram feitas como parte da transição para uma arquitetura multithread:

Um novo parâmetro de configuração foi adicionado: --with-stacksize. Esse parâmetro permite substituir o tamanho padrão da pilha de threads usado pelo sistema (em kilobytes).
A resolução de macros de usuário foi movida do gerenciador de pré-processamento para os workers de pré-processamento.

Fortalecimento da segurança do ambiente do server

Agora é possível restringir algumas funções do Zabbix para fortalecer a segurança do ambiente do server:

a execução de scripts globais no Zabbix server pode ser desabilitada definindo EnableGlobalScripts=0 na configuração do server. Para novas instalações, a execução de scripts globais no Zabbix server é desabilitada por padrão.
a autenticação HTTP do usuário pode ser desabilitada definindo $ALLOW_HTTP_AUTH=false no arquivo de configuração do frontend (zabbix.conf.php).
o modem GSM para notificações por SMS agora pode ser especificado no novo parâmetro SMSDevices, limitando a possibilidade de configurar incorretamente o caminho do modem GSM pelo frontend.

Validação do arquivo de configuração

A possibilidade de validar o arquivo de configuração foi adicionada aos comandos de manutenção do server, proxy, agent, agent 2 e web service do Zabbix. A validação pode ser realizada usando a opção -T --test-config. Em caso de validação bem-sucedida, o código de saída será "0"; caso contrário, o componente será encerrado com um código de saída diferente de zero e uma mensagem de erro correspondente. Avisos (por exemplo, no caso de um parâmetro obsoleto) não afetarão o código de saída bem-sucedida.

Detecção dos recursos da biblioteca cURL em tempo de execução

Anteriormente, os recursos da biblioteca cURL eram detectados no momento da compilação do Zabbix server, proxy ou agent. Se os recursos do cURL fossem atualizados, o respectivo componente do Zabbix precisava ser recompilado para que eles pudessem ser utilizados.

Agora, basta reiniciar para que os recursos atualizados da biblioteca cURL fiquem disponíveis no Zabbix. A recompilação não é mais necessária. Isso se aplica ao Zabbix server, proxy e agent.

Consulte também as notas de atualização.

Configuração do Agent 2

Tamanho do buffer

O valor padrão do parâmetro de configuração BufferSize para o agent 2 do Zabbix foi aumentado de 100 para 1000.

Valores vazios permitidos

Agora são permitidos valores vazios em parâmetros de configuração relacionados a plugins no agent 2 do Zabbix.

Definindo o tipo de inicialização do serviço do agent do Windows

A opção para definir o tipo de inicialização do serviço do agent/agent 2 do Zabbix no Windows (-S --startup-type) foi adicionada. Esta opção permite configurar o serviço do agent/agent 2 para iniciar automaticamente na inicialização do Windows (automatic), após os serviços iniciados automaticamente terem concluído a inicialização (delayed), quando iniciado manualmente por um usuário ou aplicativo (manual) ou para desabilitar o serviço completamente (disabled).

Ao realizar a instalação do agent do Windows a partir do MSI, o tipo de inicialização padrão no Windows Server 2008/Vista e versões posteriores agora é delayed se não for especificado de outra forma no parâmetro de linha de comando STARTUPTYPE parâmetro de linha de comando. Isso melhora a confiabilidade e o desempenho do serviço do agent/agent 2 do Zabbix no Windows, especialmente durante reinicializações do sistema.

Suporte ao antigo tipo numérico removido

O antigo estilo de valores de ponto flutuante, anteriormente obsoleto, não é mais suportado, pois valores numéricos de faixa estendida são usados.

Parâmetro de prefixo do Vault adicionado aos arquivos de configuração

Os arquivos de configuração zabbix_server.conf e zabbix_proxy.conf foram complementados com um novo parâmetro opcional Vault Prefix; zabbix.conf.php foi complementado com o parâmetro opcional $DB['VAULT_PREFIX'], e setup.php foi atualizado de acordo.

Os caminhos do vault para CyberArk e HashiCorp não são mais codificados, permitindo implantações do vault com caminhos não padrão.

Descoberta

Concorrência na descoberta de rede

Anteriormente, cada regra de descoberta de rede era processada por um único processo discoverer. Assim, todas as verificações de serviço dentro da regra só podiam ser realizadas sequencialmente.

Na nova versão, o processo de descoberta de rede foi reformulado para permitir a execução simultânea das verificações de serviço. Um novo processo de gerenciamento de descoberta foi adicionado, juntamente com um número configurável de workers (ou threads) de descoberta.

O gerenciador de descoberta processa as regras de descoberta e cria um job de descoberta para cada regra, com suas tarefas (verificações de serviço). As verificações de serviço são selecionadas e executadas pelos workers de descoberta. Somente as verificações que têm o mesmo IP e porta são agendadas sequencialmente, pois alguns dispositivos podem não permitir conexões simultâneas na mesma porta.

Um novo item interno zabbix[discovery_queue] permite monitorar o número de verificações de descoberta na fila.

O parâmetro StartDiscoverers agora determina o número total de workers de descoberta disponíveis. O número padrão de StartDiscoverers aumentou de 1 para 5, e o intervalo passou de 0-250 para 0-1000. Os processos discoverer das versões anteriores do Zabbix foram removidos.

Além disso:

Todas as verificações de serviço agora são realizadas de forma assíncrona, exceto as verificações LDAP;
O número de verificações assíncronas simultâneas por tipo de verificação de serviço (ou o número de workers disponíveis para todas as verificações de serviço síncronas) agora pode ser configurado no frontend (consulte Maximum concurrent checks per type). Este parâmetro é opcional.
Anteriormente, a verificação de serviço HTTP era igual à verificação TCP. Agora, as verificações HTTP/HTTPS são realizadas por meio da libcurl. Se o Zabbix server/proxy for compilado sem libcurl, as verificações HTTP funcionarão como antes (ou seja, como verificações TCP), mas as verificações HTTPS não funcionarão.
Os erros no processo de descoberta de rede agora serão exibidos no frontend (em Data collection > Discovery), por exemplo:
- erros do fping;
- OID SNMP incorreto;
- macro incorreta para o tempo limite do item;
- erros no intervalo de endereços.

Adicionando tags de host durante descoberta/autoregistro

Operações adicionais agora estão disponíveis para eventos de descoberta e autoregistro:

Adicionar tags de host
Remover tags de host

Compartilhamento de grupos de hosts descobertos

As regras de descoberta de baixo nível agora podem vincular grupos de hosts já descobertos e existentes aos hosts criados pelas mesmas regras de descoberta de baixo nível. Isso afeta os grupos de hosts descobertos e criados anteriormente por outras regras de descoberta de baixo nível com base nos protótipos de grupo especificados.

Conectores

A funcionalidade de data streaming não é mais experimental.

Transmitir dados seletivos e configurar intervalos de tentativa

Ao transmitir valores de item do Zabbix para sistemas externos, agora você pode configurar quais valores de item o conector deve transmitir com base em seu tipo de informação (numérico (sem sinal), numérico (float), caractere, etc.).

Além disso, para evitar tentativas malsucedidas de transmitir valores de item ou eventos (por exemplo, se o endpoint HTTP estiver ocupado ou com limite de taxa), agora você também pode configurar o intervalo de tentativa - quanto tempo o conector deve esperar após uma tentativa malsucedida de transmitir dados.

Os códigos de resposta HTTP 201, 202, 203 e 204 agora também são aceitos pelos conectores como sucesso (anteriormente apenas 200).

Transmitir dados para o Apache Kafka

Uma nova ferramenta para transmitir dados para sistemas externos - o conector Kafka para o Zabbix server - já está disponível. O conector Kafka é um servidor leve escrito em Go, projetado para encaminhar valores de item e eventos de um Zabbix server para um broker Kafka.

Templates

Para obter informações sobre novos templates e alterações nos templates existentes, consulte Alterações nos templates.

Frontend

Autenticação multifator

A autenticação multifator (MFA) com senha única baseada em tempo (TOTP) ou método de autenticação Duo Universal Prompt agora pode ser usada para fazer login no Zabbix, fornecendo uma camada adicional de segurança além do nome de usuário e senha.

Formato de hora dos EUA

As exibições de hora e data no frontend agora estão em conformidade com o padrão de exibição de hora/data dos EUA quando o idioma padrão (en_US) do frontend é usado.

Antes	Agora

Clonagem simplificada

Anteriormente, era possível Clonar e Clonar completamente hosts, templates e mapas.

Agora, a opção Clonar foi removida e a opção Clonar completamente foi renomeada para Clonar, mantendo toda a funcionalidade anterior de Clonar completamente.

Ícones substituídos por fontes

Todos os ícones no frontend foram trocados de imagens para fontes.

Formulários modais

Vários formulários do frontend agora são abertos em janelas modais (pop-up):

Configuração da regra de descoberta de rede;
Configuração do script global;
Configuração da correlação de eventos;
Configuração do módulo;
Configuração do tipo de mídia;
Configuração do template;
Configuração do trigger e do protótipo de trigger;
Configuração do item e do protótipo de item.

Configuração avançada recolhível

As caixas de seleção Configuração avançada, responsáveis por exibir opções de configuração avançadas, foram substituídas por blocos recolhíveis (consulte, por exemplo, Configuração do conector, Configuração do serviço, Configuração do widget Relógio, etc.).

Isso melhora a experiência do usuário, pois recolher esses blocos e salvar a configuração não redefinirá mais as opções avançadas configuradas para seus valores padrão.

A seção de menu para visualizar os principais triggers agora se chama Top 100 triggers. A possibilidade de filtrar triggers por nome do problema e tags foi adicionada. Além disso, o número de problemas detectados em vez do número de alterações de status agora é exibido para cada trigger.

Limite de caracteres aumentado para campos de configuração

Campos de URL

O limite de caracteres para todos os campos de URL agora é de 2048 caracteres. Isso inclui: URL do bloco para configurações relacionadas a mapas geográficos, URL do frontend para configurar diversos parâmetros do frontend, URLs de mapas de rede e elementos de mapas de rede, URL A-C para campos do inventário do host, e URL para o widget de dashboard URL.

Campos de autenticação

O limite de caracteres para os campos de autenticação Usuário/Nome de usuário e Senha agora é de 255 caracteres. Isso se aplica à configuração da autenticação HTTP para itens do HTTP agent, cenários web e conectores, bem como à configuração da autenticação para verificações simples, monitoramento ODBC, verificações SSH, verificações Telnet e monitoramento JMX.

Truncamento do resultado do teste de item e pré-processamento

Ao testar itens ou testar etapas de pré-processamento, os valores recuperados de um host e os resultados dos testes agora são truncados para um tamanho máximo de 512 KB ao serem enviados ao frontend. Observe que os dados maiores que 512 KB ainda são processados integralmente pelo Zabbix server.

Abas dos painéis de host

Todos os painéis de host configurados para o host selecionado agora são exibidos como abas sob o cabeçalho da página de painéis de host, substituindo o menu suspenso anterior no canto superior direito. Isso permite uma transição fácil entre vários painéis de host e melhora a navegação pelos dados de monitoramento.

Log de auditoria

Em Administração > Log de auditoria, agora você pode ativar/desativar o registro de auditoria das atividades de descoberta de baixo nível, descoberta de rede e registro automático realizadas pelo server (usuário System).

O período padrão de armazenamento dos registros do log de auditoria antes de serem excluídos pelo housekeeper foi alterado de 365 dias para 31 dias.

Filtro de dados mais recentes

Em Monitoramento > Dados mais recentes, o subfiltro e os dados não são mais exibidos por padrão se o filtro não estiver definido.

Se estiver atualizando de versões anteriores do Zabbix, consulte também: Notas de atualização para 7.0.0.

Versão mínima do PHP necessária

A versão mínima do PHP necessária foi aumentada de 7.4.0 para 8.0.0.

Elementos renomeados

Alguns parâmetros de widget de dashboard com o rótulo Tags foram renomeados para maior clareza: Tags do item (para o widget Visão geral dos dados), Tags do cenário (para o widget Monitoramento web); Tags do problema (para os widgets Gráfico, Hosts com problemas, Problemas, Problemas por severidade e Visão geral dos triggers);
O link de ação para edição do conteúdo do mapa, disponível na lista de mapas na seção Monitoramento → Mapas, foi renomeado de Construtor para Editar;
Os campos para definir os períodos de armazenamento de histórico e tendências nos formulários de configuração de item e protótipo de item foram renomeados;
No formulário de configuração do widget Hosts principais, os campos Coluna de ordenação e Contagem de hosts foram renomeados para Ordenar por e Limite de hosts para descrever melhor suas funções.
Na configuração do widget Gráfico, o campo da legenda Exibir min/máx/média foi renomeado para Exibir min/média/máx, e os campos do conjunto de dados padrão do host e padrão do item foram renomeados para padrões do host e padrões do item.
Nas configurações do Perfil do usuário, a aba Mensagens foi renomeada para Notificações do frontend, na qual a opção Mensagens do frontend também foi renomeada para Notificações do frontend.

Diversos

Os ícones do menu principal foram atualizados;
As mensagens que indicam a ausência de dados ou filtros não definidos (em widgets ou filtros pop-up sem dados para exibir) foram atualizadas. Além disso, o rodapé "Exibindo 0 de 0 encontrados" foi removido nos casos em que não há dados para exibir ou quando a filtragem (ou o uso da pesquisa global) não retorna correspondências.
Os números de versão do frontend do Zabbix e do server do Zabbix agora podem ser visualizados na página de informações do sistema;
Todas as ações nas quais o tipo de mídia é usado agora são exibidas na lista de tipos de mídia (coluna Usado em ações). Anteriormente, as ações nas quais a opção Enviar somente para na configuração da operação da ação era "Todos" não eram incluídas na coluna Usado em ações do tipo de mídia;
Uma nova opção de filtragem foi adicionada à seção Dados recentes: agora é possível filtrar itens pelo estado (suportado/não suportado);
Uma nova opção de filtragem Status de reconhecimento foi adicionada à seção Problemas: agora é possível filtrar problemas pelo estado (não reconhecido/reconhecido/reconhecido por mim);
Um botão padrão para fechar a janela foi adicionado às janelas pop-up destinadas à configuração e à atualização em massa dos elementos e formas do mapa;
A configuração das permissões de grupos de usuários e das tags para filtrar problemas visíveis foi aprimorada. Agora é possível selecionar vários grupos de hosts/templates de uma só vez para atribuir as mesmas permissões a eles.
As notificações globais adiadas em um navegador agora serão adiadas em todos os navegadores/dispositivos nos quais o usuário estiver conectado.
O parâmetro Substituir host no widget Valor do item foi movido para antes da seção Configuração avançada para facilitar o uso.

Plugins

Ember+

Um novo plugin para monitoramento direto de Ember+ pelo Zabbix agent 2 foi adicionado.

Para mais informações, consulte:

Instalação

Pacotes de instalação separados para derivados do RHEL

Pacotes de instalação dedicados estão disponíveis para as versões 8 e 9 do AlmaLinux, CentOS Stream, Oracle Linux e Rocky Linux.

Anteriormente, eram fornecidos pacotes de instalação únicos para o RHEL e distribuições baseadas no RHEL.

Agora, são usados pacotes separados para o RHEL e para cada um dos derivados mencionados acima, a fim de evitar possíveis problemas de incompatibilidade binária.

Suporte para ARM64/AArch64

Os pacotes de instalação ARM64/AArch64 agora estão disponíveis para Debian, RHEL 8, 9 e seus derivados, bem como SLES/OpenSUSE Leap 15.

O que vem a seguir?

6 O que há de novo no Zabbix 7.0.1

Docs

5 Novidades no Zabbix 7.0.0

Licença AGPL-3.0

Verificação de atualização de software