8 Problemas conhecidos

Veja também: Problemas de compilação.

Problemas conhecidos na 7.4.4

Não é recomendado atualizar para esta versão devido a:

• aumento repentino de uso de CPU se você estiver usando o plugin MySQL do Zabbix agent 2 (veja ZBX-27156)
• gráfico para items ativos do Zabbix agent mostrando um aviso "Undefined array key" devido a um erro de índice indefinido (veja ZBX-27153)

Atualização

Configuração do modo SQL para atualização bem-sucedida

A configuração sql_mode no MySQL/MariaDB deve ter o modo "STRICT_TRANS_TABLES" definido. Se estiver ausente, a atualização do banco de dados Zabbix falhará (veja também ZBX-19435).

Atualização com MariaDB 10.2.1 e anteriores

A atualização do Zabbix pode falhar se as tabelas do banco de dados foram criadas com o MariaDB 10.2.1 ou anterior, porque nessas versões o formato de linha padrão é o compact. Isso pode ser corrigido alterando o formato de linha para dynamic (veja também ZBX-17690).

Templates

Compatibilidade de template em ambientes dual-stack (IPv4/IPv6)

Em ambientes dual-stack (sistemas configurados para suportar tanto IPv4 quanto IPv6), o hostname localhost normalmente é resolvido para endereços IPv4 e IPv6. Devido à priorização comum do IPv6 sobre o IPv4 por muitos sistemas operacionais e resolvedores de DNS, os templates do Zabbix podem não funcionar corretamente se o serviço monitorado estiver configurado para escutar apenas em IPv4.

Serviços que não estão configurados para escutar em endereços IPv6 podem se tornar inacessíveis, levando a falhas no monitoramento. Os usuários podem configurar o acesso corretamente para IPv4, mas ainda assim enfrentar problemas de conectividade devido ao comportamento padrão de priorizar o IPv6.

Uma solução alternativa para isso é garantir que os serviços (Nginx, Apache, PostgreSQL, etc.) estejam configurados para escutar em endereços IPv4 e IPv6, e que o Zabbix server/agent tenha permissão de acesso via IPv6. Além disso, nos templates e configurações do Zabbix, use localhost explicitamente em vez de 127.0.0.1 para garantir a compatibilidade com IPv4 e IPv6.

Por exemplo, ao monitorar o PostgreSQL com o template PostgreSQL by Zabbix agent 2, pode ser necessário editar o arquivo pg_hba.conf para permitir conexões para o usuário zbx_monitor. Se o ambiente dual-stack priorizar o IPv6 (o sistema resolve localhost para ::1) e você configurar localhost, mas adicionar apenas uma entrada IPv4 (127.0.0.1/32), a conexão falhará porque não há uma entrada correspondente para IPv6.

O exemplo a seguir do arquivo pg_hba.conf garante que o usuário zbx_monitor possa se conectar a qualquer banco de dados a partir da máquina local usando endereços IPv4 e IPv6 com diferentes métodos de autenticação:

# TYPE     DATABASE     USER            ADDRESS          METHOD
         host     all          zbx_monitor     localhost        trust
         host     all          zbx_monitor     127.0.0.1/32     md5
         host     all          zbx_monitor     ::1/128          scram-sha-256

Se necessário, você também pode usar o endereço IPv4 (127.0.0.1) diretamente ao configurar a macro do template PostgreSQL by Zabbix agent 2 para a string de conexão.

Instalação acidental de pacotes Zabbix do EPEL

Se o repositório EPEL estiver instalado e habilitado, a instalação de pacotes Zabbix pode puxar versões do EPEL em vez dos pacotes oficiais do Zabbix. Para resolver isso:

1. Remova quaisquer pacotes Zabbix instalados a partir do EPEL:

dnf remove zabbix-server-mysql

2. Exclua pacotes Zabbix do EPEL adicionando a seguinte linha ao arquivo /etc/yum.conf:

[epel]
       ...
       excludepkgs=zabbix*

3. Reinstale o pacote oficial do Zabbix server:

dnf install zabbix-server-mysql

Durante a instalação, os pacotes oficiais do Zabbix incluem a palavra release em sua string de versão (por exemplo, 7.0.0-release1.el8), distinguindo-os dos pacotes do EPEL.

Pacotes Zabbix para RHEL em ambientes Red Hat UBI

Ao instalar o Zabbix a partir de pacotes do Red Hat Enterprise Linux em ambientes Red Hat Universal Base Image, garanta o acesso aos repositórios e dependências necessários. Os pacotes do Zabbix dependem das bibliotecas libOpenIPMI.so e libOpenIPMIposix.so, que não são fornecidas por nenhum pacote nos repositórios padrão do gerenciador de pacotes habilitados em sistemas UBI e resultarão em falhas na instalação.

As bibliotecas libOpenIPMI.so e libOpenIPMIposix.so estão disponíveis no pacote OpenIPMI-libs, que é fornecido pelo repositório redhat-#-for-<arch>-appstream-rpms. O acesso a este repositório é controlado por assinaturas, que, no caso de ambientes UBI, são propagadas montando os diretórios de configuração do repositório e de segredos do host RHEL no namespace do sistema de arquivos do contêiner.

Para mais informações, consulte ZBX-24291.

Chave de assinatura expirada para pacotes RHEL

Ao atualizar o Zabbix no Red Hat Enterprise Linux ou seus derivados, você pode encontrar um problema de chave de assinatura expirada para pacotes no repositório Zabbix. Quando uma chave de assinatura expira, as tentativas de verificar as assinaturas dos pacotes resultarão em um erro indicando que o certificado ou a chave não são mais válidos. Por exemplo:

error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
         1. Certificate 19F2475308EFA7DD invalid: certificate is not alive
             because: The primary key is not live
             because: Expired on 2024-07-04T11:41:23Z
         2. Key 19F2475308EFA7DD invalid: key is not alive
             because: The primary key is not live
             because: Expired on 2024-07-04T11:41:23Z

Para resolver esse tipo de problema, reinstale manualmente o pacote zabbix-release mais recente para sua variante específica do RHEL (substitua o link abaixo pelo correto do repositório Zabbix).

Por exemplo, no RHEL 9, execute:

rpm -Uvh https://repo.zabbix.com/zabbix/7.4/release/rhel/9/noarch/zabbix-release-latest.el9.noarch.rpm

Em seguida, atualize as informações do repositório:

dnf update

Para mais informações, consulte ZBX-24761.

Timescale DB: alto uso de memória com grande número de partições

As versões do PostgreSQL 9.6-12 usam muita memória ao atualizar tabelas com um grande número de partições. Esse problema se manifesta quando o Zabbix atualiza tendências em sistemas com TimescaleDB se as tendências forem divididas em partes relativamente pequenas (por exemplo, 1 dia). Isso leva a centenas de partes presentes nas tabelas de tendências com as configurações padrão de housekeeping - a condição em que o PostgreSQL provavelmente ficará sem memória.

O problema foi resolvido desde o Zabbix 5.0.1 para novas instalações com TimescaleDB, mas se o TimescaleDB foi configurado com o Zabbix antes disso, consulte ZBX-16347 para as notas de migração.

Timescale DB 2.5.0: a política de compressão pode falhar em tabelas que contêm inteiros

Esse problema se manifesta quando o TimescaleDB 2.5.0/2.5.1 é usado. Ele foi resolvido desde o TimescaleDB 2.5.2.

Para mais informações, consulte TimescaleDB Issue #3773.

Conexão TLS com banco de dados MariaDB

A conexão TLS com banco de dados não é suportada com a opção 'verify_ca' para o parâmetro DBTLSConnect parâmetro se o MariaDB for usado.

Possíveis deadlocks com MySQL/MariaDB

Ao executar sob alta carga e com mais de um worker LLD envolvido, é possível encontrar um deadlock causado por um erro do InnoDB relacionado à estratégia de bloqueio de linhas (consulte o bug upstream). O erro foi corrigido no MySQL a partir da versão 8.0.29, mas não no MariaDB. Para mais detalhes, consulte ZBX-21506.

Correlação de eventos globais

Os eventos podem não ser correlacionados corretamente se o intervalo de tempo entre o primeiro e o segundo evento for muito pequeno, ou seja, meio segundo ou menos.

Intervalo do tipo de dado numérico (float) com PostgreSQL 11 e versões anteriores

O PostgreSQL 11 e versões anteriores suportam apenas o intervalo de valores de ponto flutuante de aproximadamente -1,34E-154 a 1,34E+154.

NetBSD 8.0 e mais recentes

Vários processos do Zabbix podem falhar aleatoriamente na inicialização nas versões 8.X e 9.X do NetBSD. Isso ocorre devido ao tamanho de pilha padrão ser muito pequeno (4MB), que deve ser aumentado executando:

ulimit -s 10240

Para mais informações, consulte o relatório de problema relacionado: ZBX-18275.

Limitações de expressões regulares no Zabbix agent 2

O Zabbix agent 2 não suporta lookaheads e lookbehinds em expressões regulares devido às limitações da biblioteca padrão de regexp do Go.

Verificações IPMI

As verificações IPMI não funcionarão com o pacote padrão da biblioteca OpenIPMI no Debian anterior ao 9 (stretch) e no Ubuntu anterior ao 16.04 (xenial). Para corrigir isso, recompile a biblioteca OpenIPMI com o OpenSSL habilitado, conforme discutido em ZBX-6139.

IPMI — untrusted hosts may crash OpenIPMI

There is a bug in the OpenIPMI library used by Zabbix for polling IPMI data that can be triggered by specially crafted responses from an untrusted device.
An untrusted IPMI device may send crafted data that causes the OpenIPMI library to crash, which in turn can cause Zabbix server process that performs IPMI polling to terminate.

Verificações SSH

• Algumas distribuições Linux como Debian, Ubuntu não suportam chaves privadas criptografadas (com senha) se a biblioteca libssh2 for instalada a partir de pacotes. Consulte ZBX-4850 para mais detalhes.
• Ao usar libssh 0.9.x em algumas distribuições Linux com OpenSSH 8, as verificações SSH podem ocasionalmente relatar "Cannot read data from SSH server". Isso é causado por um problema na libssh (relatório mais detalhado). Espera-se que o erro tenha sido corrigido na versão estável libssh 0.9.5. Veja também ZBX-17756 para detalhes.
• Usar o pipe "|" no script SSH pode levar a um erro "Cannot read data from SSH server". Neste caso, recomenda-se atualizar a versão da biblioteca libssh. Veja também ZBX-21337 para detalhes.

Verificações ODBC

• O driver MySQL unixODBC não deve ser usado com o Zabbix server ou Zabbix proxy compilados contra a biblioteca do conector MariaDB e vice-versa. Se possível, também é melhor evitar usar o mesmo conector como driver devido a um bug upstream. Configuração recomendada:

Conector PostgreSQL, SQLite ou Oracle → driver MariaDB ou MySQL unixODBC
Conector MariaDB → driver MariaDB unixODBC
Conector MySQL → driver MySQL unixODBC

Veja ZBX-7665 para mais informações e soluções alternativas disponíveis.

• Dados XML consultados do Microsoft SQL Server podem ser truncados de várias maneiras em sistemas Linux e UNIX.

• Foi observado que o uso de verificações ODBC para monitorar bancos de dados Oracle usando várias versões do Oracle Instant Client para Linux faz com que o Zabbix server trave.
  Veja também: ZBX-18402, ZBX-20803.

• Se estiver usando o driver FreeTDS UnixODBC, você precisa adicionar uma instrução 'SET NOCOUNT ON' no início de uma consulta SQL (por exemplo, SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). Caso contrário, o item de monitoramento do banco de dados no Zabbix não conseguirá recuperar as informações e apresentará o erro "A consulta SQL retornou resultado vazio".
  Veja ZBX-19917 para mais informações.

Parâmetro de método de requisição incorreto em items

O parâmetro do método de requisição, usado apenas em verificações HTTP, pode estar incorretamente definido como '1', um valor não padrão para todos os items como resultado da atualização de uma versão do Zabbix anterior à 4.0. Para detalhes sobre como corrigir essa situação, consulte ZBX-19308.

Monitoramento web e agente HTTP

O servidor Zabbix vaza memória em algumas distribuições Linux devido a um bug upstream quando "SSL verify peer" está habilitado em cenários web ou agente HTTP. Consulte ZBX-10486 para mais informações e soluções alternativas disponíveis.

Verificações simples

Existe um bug nas versões do fping anteriores à v3.10 que lida incorretamente com pacotes de resposta de eco duplicados. Isso pode causar resultados inesperados para os items icmpping, icmppingloss, icmppingsec. Recomenda-se usar a versão mais recente do fping. Consulte ZBX-11726 para mais detalhes.

Erros com a execução do fping em containers rootless

Quando os containers estão sendo executados no modo rootless ou em um ambiente com restrições específicas, você pode enfrentar erros relacionados à execução do fping ao realizar verificações ICMP, como fping: Operation not permitted ou todos os pacotes para todos os recursos perdidos.

Para corrigir esse problema, adicione --cap-add=net_raw aos comandos "docker run" ou "podman run".

Além disso, a execução do fping em ambientes sem root pode exigir a modificação do sysctl, ou seja:

sudo sysctl -w "net.ipv4.ping_group_range=0 1995"

onde "1995" é o GID do zabbix. Para mais detalhes, consulte ZBX-22833.

Verificações SNMP

Se o sistema operacional OpenBSD for usado, um bug de use-after-free na biblioteca Net-SNMP até a versão 5.7.3 pode causar uma falha no Zabbix server se o parâmetro SourceIP estiver definido no arquivo de configuração do Zabbix server. Como solução alternativa, por favor, não defina o parâmetro SourceIP. O mesmo problema também se aplica ao Linux, mas não faz com que o Zabbix server pare de funcionar. Um patch local para o pacote net-snmp no OpenBSD foi aplicado e será lançado com o OpenBSD 6.3.

Picos de dados SNMP

Foram observados picos em dados SNMP que podem estar relacionados a certos fatores físicos, como picos de tensão na rede elétrica. Veja ZBX-14318 para mais detalhes.

Traps SNMP

O pacote "net-snmp-perl", necessário para traps SNMP, foi removido no RHEL 8.0-8.2; readicionado no RHEL 8.3.

Portanto, se você estiver usando o RHEL 8.0-8.2, a melhor solução é atualizar para o RHEL 8.3.

Veja também ZBX-17192 para mais informações.

Falha do processo de alerta no RHEL 7

Foram encontrados casos de falha do processo de alerta do Zabbix server no RHEL 7. Consulte ZBX-10461 para obter mais detalhes.

Atualizando o Zabbix agent 2 (6.0.5 ou anterior)

Ao atualizar o Zabbix agent 2 (versão 6.0.5 ou anterior) a partir de pacotes, pode ocorrer um erro de conflito de arquivos relacionado a plugins. Para corrigir o erro, faça backup da configuração do agent 2 (se necessário), desinstale o agent 2 e instale-o novamente.

Em sistemas baseados em RHEL, execute:

dnf remove zabbix-agent2
       dnf install zabbix-agent2

Em sistemas baseados em Debian, execute:

apt remove zabbix-agent2
       apt install zabbix-agent2

Para mais informações, consulte ZBX-23250.

Alternância de idiomas no frontend

Foi observado que os idiomas do frontend podem alternar sem lógica aparente, ou seja, algumas páginas (ou partes de páginas) são exibidas em um idioma enquanto outras páginas (ou partes de páginas) em outro idioma. Normalmente, o problema pode aparecer quando há vários usuários, alguns dos quais usam um idioma, enquanto outros usam outro.

Uma solução conhecida para isso é desabilitar o multithreading no PHP e no Apache.

O problema está relacionado a como a configuração de idioma funciona no PHP: as informações de idioma são mantidas por processo, não por thread. Portanto, em um ambiente multithread, quando há vários projetos executados pelo mesmo processo do Apache, é possível que o idioma seja alterado em outra thread e isso mude a forma como os dados podem ser processados na thread do Zabbix.

Para mais informações, consulte os relatórios de problemas relacionados:

• ZBX-10911 (Problema com alternância de idiomas no frontend)
• ZBX-16297 (Problema com o processamento de números em gráficos usando a função bcdiv das funções BC Math)

Gráficos

Horário de verão

Alterações no horário de verão (DST) resultam em irregularidades ao exibir os rótulos do eixo X (duplicação de datas, datas ausentes, etc).

Agregação de soma

Ao usar agregação de soma em um gráfico para um período inferior a uma hora, os gráficos exibem valores incorretos (multiplicados) quando os dados vêm de tendências.

Sobreposição de texto

Para alguns idiomas do frontend (por exemplo, japonês), as fontes locais podem causar sobreposição de texto na legenda do gráfico. Para evitar isso, use a versão 2.3.0 (ou posterior) da extensão PHP GD.

Monitoramento de arquivos de log

Os items log[] e logrt[] relêem repetidamente o arquivo de log desde o início se o sistema de arquivos estiver 100% cheio e o arquivo de log estiver sendo anexado (veja ZBX-10884 para mais informações).

Consultas lentas do MySQL

O Zabbix server gera consultas SELECT lentas no caso de valores inexistentes para items. Esse problema é conhecido por ocorrer nas versões 5.6/5.7 do MySQL (para uma discussão mais detalhada, veja ZBX-10652), e, em casos específicos, também pode ocorrer em versões posteriores do MySQL. Uma solução alternativa para isso é desabilitar o otimizador index_condition_pushdown ou prefer_ordering_index no MySQL. Observe, no entanto, que essa solução alternativa pode não corrigir todos os problemas relacionados a consultas lentas.

Configurações de filtro persistentes a partir de links

Ao abrir um link para uma página do frontend do Zabbix que contenha configurações de filtro, incluindo o seletor de tempo, o filtro é salvo automaticamente no banco de dados para o usuário, substituindo as configurações de filtro e/ou seletor de tempo salvas anteriormente para essa página. Essas configurações permanecem ativas até que o usuário as atualize ou redefina manualmente.

Problema de endereço IPv6 em traps SNMPv3

Devido a um bug no net-snmp, o endereço IPv6 pode não ser exibido corretamente ao usar SNMPv3 em traps SNMP. Para mais detalhes e uma possível solução alternativa, consulte ZBX-14541.

Endereço IP IPv6 longo truncado nas informações de login com falha

Uma mensagem de tentativa de login com falha exibirá apenas os primeiros 39 caracteres de um endereço IP armazenado, pois esse é o limite de caracteres no campo do banco de dados. Isso significa que endereços IP IPv6 com mais de 39 caracteres serão exibidos de forma incompleta.

Verificações do agent Zabbix no Windows

Entradas DNS inexistentes em um parâmetro Server do arquivo de configuração do agent Zabbix (zabbix_agentd.conf) podem aumentar o tempo de resposta do agent Zabbix no Windows. Isso acontece porque o daemon de cache DNS do Windows não armazena em cache respostas negativas para endereços IPv4. No entanto, para endereços IPv6, as respostas negativas são armazenadas em cache, portanto, uma possível solução alternativa para isso é desabilitar o IPv4 no host.

Exportação/importação YAML

Existem alguns problemas conhecidos com a exportação/importação YAML:

• As mensagens de erro não são traduzíveis;
• JSON válido com uma extensão de arquivo .yaml às vezes não pode ser importado;
• Datas legíveis por humanos não citadas são automaticamente convertidas em timestamps Unix.

Assistente de configuração no SUSE com NGINX e php-fpm

O assistente de configuração do frontend não pode salvar o arquivo de configuração no SUSE com NGINX + php-fpm. Isso é causado por uma configuração na unidade /usr/lib/systemd/system/php-fpm.service, que impede o Zabbix de gravar em /etc. (introduzido no PHP 7.4).

Existem duas opções de solução alternativa disponíveis:

• Defina a opção ProtectSystem como 'true' em vez de 'full' na unidade systemd do php-fpm.
• Salve manualmente o arquivo /etc/zabbix/web/zabbix.conf.php.

Encaminhamento do cabeçalho de autorização

Em alguns casos, o Apache ou o NGINX podem impedir que o cabeçalho Authorization em solicitações de API chegue ao Zabbix. Isso pode causar problemas de autenticação ao usar a API do Zabbix ou serviços de logon único (SSO), como SAML com Okta.

Para resolver isso, atualize a configuração do seu servidor web.

Para o Apache, se você estiver usando como um proxy reverso (configuração não-CGI), adicione a seguinte diretiva em /etc/httpd/conf/httpd.conf (em sistemas baseados em RHEL) ou /etc/apache2/apache2.conf (em Debian/Ubuntu):

SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

Se o Apache executar scripts diretamente para lidar com solicitações (por exemplo, usando mod_cgi), adicione a seguinte diretiva:

CGIPassAuth On

Por outro lado, o NGINX lida automaticamente com o cabeçalho Authorization. No entanto, se o NGINX estiver atuando como proxy reverso, você pode encaminhar explicitamente o cabeçalho Authorization adicionando as seguintes diretivas em /etc/nginx/nginx.conf (para o local do seu frontend Zabbix):

...
       location / {
       ...
           proxy_set_header Authorization $http_authorization;
           proxy_pass http://backend_server;
       ...
       }

Após atualizar a configuração, reinicie o servidor web.

Para mais detalhes, consulte:

• ZBX-22952
• Apache 2.4 + PHP-FPM e cabeçalhos de autorização
• Diretivas SetEnvIfNoCase e CGIPassAuth
• NGINX Reverse Proxy

Chromium para o serviço web do Zabbix no Ubuntu 20

Embora na maioria dos casos o serviço web do Zabbix possa ser executado com o Chromium, no Ubuntu 20.04 o uso do Chromium causa o seguinte erro:

Cannot fetch data: chrome failed to start:cmd_run.go:994:
       WARNING: cannot create user data directory: cannot create 
       "/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
       Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.

Esse erro ocorre porque /var/lib/zabbix é usado como diretório home do usuário 'zabbix'.

Códigos de erro personalizados do MySQL

Quando o Zabbix detecta que o banco de dados backend está inacessível, ele envia uma notificação e continua tentando se conectar. Para certos mecanismos de banco de dados, códigos de erro específicos são reconhecidos. No MySQL, esses códigos de erro reconhecidos incluem:

• CR_CONN_HOST_ERROR
• CR_SERVER_GONE_ERROR
• CR_CONNECTION_ERROR
• CR_SERVER_LOST
• CR_UNKNOWN_HOST
• ER_SERVER_SHUTDOWN
• ER_ACCESS_DENIED_ERROR
• ER_ILLEGAL_GRANT_FOR_TABLE
• ER_TABLEACCESS_DENIED_ERROR
• ER_UNKNOWN_ERROR

Além disso, ao usar o Zabbix com uma instalação MySQL no Azure, a mensagem de erro genérica [9002] Some errors occurred pode aparecer nos logs do Zabbix. Esta mensagem é enviada pelo banco de dados para o Zabbix server ou proxy. Para determinar a causa do erro, consulte os logs do Azure.

Expressões regulares inválidas após a mudança para PCRE2

No Zabbix 6.0 foi adicionada a compatibilidade com PCRE2. Embora o PCRE ainda seja suportado, os pacotes de instalação do Zabbix para RHEL 7 e mais recentes, SLES (todas as versões), Debian 9 e mais recentes, Ubuntu 16.04 e mais recentes foram atualizados para usar o PCRE2. Embora traga muitos benefícios, a mudança para o PCRE2 pode fazer com que certos padrões de regexp existentes do PCRE se tornem inválidos ou se comportem de maneira diferente. Em particular, isso afeta o padrão ^[\w-\.]. Para tornar essa regexp válida novamente sem afetar a semântica, altere a expressão para ^[-\w\.] . Isso acontece devido ao fato de que o PCRE2 trata o sinal de traço como um delimitador, criando um intervalo dentro de uma classe de caracteres.

Erro no widget Geomap

Os mapas no widget Geomap podem não carregar corretamente se você atualizou de uma versão mais antiga do Zabbix com NGINX e não mudou para o novo arquivo de configuração do NGINX durante a atualização.

Para corrigir o problema, você pode descartar o arquivo de configuração antigo, usar o arquivo de configuração do pacote da versão atual e reconfigurá-lo conforme descrito nas instruções de download na seção e. Configure o PHP para o frontend do Zabbix.

Como alternativa, você pode editar manualmente um arquivo de configuração NGINX existente (normalmente, /etc/zabbix/nginx.conf). Para isso, abra o arquivo e localize o seguinte bloco:

location ~ /(api\/|conf[^\.]|include|locale|vendor) {
               deny            all;
               return          404;
       }

Em seguida, substitua este bloco por:

location ~ /(api\/|conf[^\.]|include|locale) {
               deny            all;
               return          404;
       }
       
       location /vendor {
               deny            all;
               return          404;
       }

Pré-processamento — variáveis globais são inseguras

O JavaScript de pré-processamento é executado por solicitação, mas atribuições a identificadores não declarados (por exemplo, secret = value) criam globais implícitas que podem persistir além da execução atual. Armazenar dados confidenciais (tokens, senhas, etc.) em globais implícitas aumenta o risco de exposição acidental ou reutilização por execuções subsequentes de pré-processamento ou outras integrações executando no mesmo ambiente.

Não confie em globais implícitas. Sempre declare variáveis com var ou const e evite anexar segredos a objetos globais (por exemplo, globalThis ou window). Não há uma maneira suportada de substituir objetos globais internos a partir do pré-processamento.

Exemplo seguro:

var apiToken = payload.token;
       var count = 1;
       return JSON.stringify({ token: apiToken, calls: count });

Grupos de processadores no Windows

A documentação da Microsoft afirma que sistemas com menos de 64 processadores lógicos sempre têm um único grupo de processadores, o Grupo 0. No entanto, usuários do Zabbix relataram um bug raro ZBX-20260, quando há dois grupos de processadores em sistemas com 64 ou menos processadores lógicos. Isso resultou em ter os contadores de desempenho "(n)" para apenas um grupo de processadores entre dois. A causa raiz real desse bug não é conhecida. No entanto, um caso semelhante foi descrito em stackoverflow.com, e a causa raiz lá estava na interoperabilidade entre o BIOS e o Windows.

Limites de filtragem com collations utf8mb4

Os filtros (por exemplo, em Coleta de dados > Manutenção) podem não funcionar corretamente quando aplicados a entidades que contêm certos caracteres Unicode (por exemplo, ȼ, ɇ). Esse problema ocorre devido à forma como a collation padrão utf8mb4_bin para bancos de dados MySQL ou MariaDB lida com a ordenação e comparação de caracteres Unicode.

Para contornar essa limitação, os usuários podem alterar a collation das colunas do banco de dados para alternativas como utf8mb4_0900_bin, utf8mb4_0900_ai_ci ou utf8mb4_unicode_520_ci. Observe, no entanto, que a alteração da collation pode causar comportamentos inesperados no tratamento de espaços em branco, bem como na ordenação e filtragem de outros caracteres.

Para mais informações sobre como alterar collations, consulte a documentação do MySQL ou a documentação do MariaDB. Para detalhes sobre diferenças de collation, consulte Unicode Character Sets na documentação do MySQL.

Access to UI elements with MariaDB 10.5.1–10.5.9

Accessing the Zabbix web frontend with a role other than Super Admin may result in the message: "System error occurred. Please contact Zabbix administrator.". This issue affects installations using MariaDB versions 10.5.1 through 10.5.9.

To avoid this issue, update MariaDB to a version later than 10.5.9. For more details, see ZBX-25746.

Perfilando uso excessivo de memória com tcmalloc

Se você suspeita que sua instalação do Zabbix está usando muita memória, pode usar o recurso de profiling de memória do tcmalloc para investigar o consumo de memória do Zabbix server/proxy.

1. Ao instalar o Zabbix a partir do código-fonte, configure as flags adicionais:

export CFLAGS="-std=gnu99 -g -O0"

A flag -std=gnu99 é necessária para compilar o Zabbix server, Zabbix proxy ou Zabbix agent. A flag -g adiciona informações extras de depuração, enquanto -O0 desativa otimizações, que podem interferir no profiling do tcmalloc.

2. Defina as seguintes variáveis de ambiente antes de iniciar o Zabbix server. Essas variáveis informam ao tcmalloc como rastrear e relatar o uso de memória:

LD_PRELOAD="/usr/lib/aarch64-linux-gnu/libtcmalloc.so" \
       HEAPPROFILE=./heap_profile \
       HEAP_PROFILE_ALLOCATION_INTERVAL=0 \
       HEAP_PROFILE_INUSE_INTERVAL=4294967296 \
       HEAPPROFILESIGNAL=5 \
       MALLOCSTATS=1 \
       ./sbin/zabbix_server -f -c /etc/zabbix/zabbix_server.conf

3. Dispare um dump do profile enviando o sinal 5 para o processo alvo. Substitua 1234 pelo ID real do processo (PID):

kill -5 1234

4. Imprima o profile gerado:

pprof-symbolize -text ./sbin/zabbix_server ./heap_profile.0001.heap
       
       Using local file ./sbin/zabbix_server.
       Using local file ./heap_profile.0001.heap.
       Total: 1078.1 MB
         1076.8  99.9%  99.9%   1076.8  99.9% zbx_malloc2
            1.0   0.1% 100.0%      1.0   0.1% __GI___strdup
            0.2   0.0% 100.0%      0.2   0.0% CRYPTO_zalloc@@OPENSSL_3.0.0
            0.1   0.0% 100.0%      0.1   0.0% OPENSSL_LH_insert@@OPENSSL_3.0.0
            0.0   0.0% 100.0%      0.0   0.0% zbx_realloc2
            0.0   0.0% 100.0%      0.1   0.0% PKCS7_decrypt@@OPENSSL_3.0.0
            0.0   0.0% 100.0%      0.0   0.0% find_best_tree_node
            0.0   0.0% 100.0%      0.0   0.0% CRYPTO_strndup@@OPENSSL_3.0.0
            ...
            0.0   0.0% 100.0%      0.0   0.0% preprocessing_flush_value
            0.0   0.0% 100.0%   1074.0  99.6% preprocessor_add_request

Neste exemplo, zbx_malloc2 é responsável por quase todas as alocações de memória.

Veja também:

• ZBX-25050 e ZBX-25584 para relatórios de problemas relacionados.
• Resumo das opções do GCC sobre opções de compilação (-std=gnu99, -g, -O0, etc.).
• Documentação do Gperftools Heap Profiler sobre variáveis de ambiente para profiling do tcmalloc.

MySQL 8.0 Group Replication em modo multi‐primary

Ao usar o MySQL 8.0 Group Replication em modo multi‐primary, você pode encontrar um erro durante a confirmação de transações semelhante ao seguinte:

1531697:20250128:064734.697 query [txnlev:1] [update alerts set status=1,retries=0,error='' where alertid=154618;
       1531697:20250128:064734.713 query [txnlev:1] [commit;]
       1531697:20250128:064734.753 [Z3005] query failed: [3101] Plugin instructed the server to rollback the current transaction. [commit;]

Esse erro parece ser causado por problemas com operações de rollback envolvendo restrições de chave estrangeira.

Veja também:

• ZBX-26060 para o relatório do problema relacionado.
• MySQL Bug #96758 "Rollbacks with Foreign Keys on single node" para o problema upstream.