Zabbix poller processes more than 75% busy – Como efetuar tuning do Zabbix e corrigir este problema

Problema – Zabbix poller processes more than 75% busy

Alertas de “Zabbix poller processes more than 75% busy” e/ou “Zabbix unreachable poller processes more than 75% busy”, após situações onde diversos nodes do Kubernetes nascem ou morrem, gerando um grande trabalho dos pollers(Zabbix StartPollersUnreachable e StartPollers), porém eles não estão dimensionados para suportar aquela carga de operações, causando alertas e as vezes lotando as queue dos Proxies no Zabbix.

Ajustar a conf, trocando os valores dos campos Zabbix StartPollers e Zabbix StartPollersUnreachable.

Valores dependem de diversas questões, são necessários ajustes, testes e validações, podendo variar conforme o ambiente.

Segue o que foi aplicado no nosso caso:

fernando@ohnz-zabbix-server:/etc/zabbix#
fernando@ohnz-zabbix-server:/etc/zabbix# cat zabbix_server.conf  | grep StartPollers
### Option: StartPollers
StartPollers=25
### Option: StartPollersUnreachable
StartPollersUnreachable=10
fernando@ohnz-zabbix-server:/etc/zabbix#

Após o ajuste, é necessário reiniciar o serviço do Zabbix:

systemctl restart zabbix-server

Já no lado do Proxy, a configuração precisa ser realizada no Deployment do Zabbix-Proxy no Kubernetes.

Temos variáveis que são “entendidas” pelo Docker, que podem ser aproveitadas para uso no env a nível do Kubernetes, por exemplo:

https://github.com/erickertz/zabbix-docker/blob/master/.env_srv

No nosso caso, ajustamos:

ZBX_STARTPOLLERS
ZBX_STARTPOLLERSUNREACHABLE

Estes dois valores são responsáveis pelo funcionamento dos pollers e consequentemente dos Zabbix poller processes.

Segue a configuração do Deployment do zabbix-proxy antes/depois:

DE:

    spec:
      containers:
        - env:
            - name: ZBX_HOSTNAME
              value: zabbix-proxy-lab
            - name: ZBX_SERVER_HOST
              value: 33.121.2.89
            - name: ZBX_CACHESIZE
              value: 256M
            - name: ZBX_CONFIGFREQUENCY
              value: '60'

PARA:

    spec:
      containers:
        - env:
            - name: ZBX_HOSTNAME
              value: zabbix-proxy-lab
            - name: ZBX_SERVER_HOST
              value: 33.121.2.89
            - name: ZBX_CACHESIZE
              value: 256M
            - name: ZBX_CONFIGFREQUENCY
              value: '60'
            - name: ZBX_STARTPOLLERS
              value: '25'
            - name: ZBX_STARTPOLLERSUNREACHABLE
              value: '10'

Validando, as configurações foram aplicadas com sucesso, após ajuste no Deployment:

bash-5.1$ cd /etc/zabbix/
bash-5.1$ cat zabbix_proxy.conf | grep StartPollers
### Option: StartPollers
# StartPollers=5
StartPollers=25
### Option: StartPollersUnreachable
# StartPollersUnreachable=1
StartPollersUnreachable=10
bash-5.1$ 
bash-5.1$ 

Anteriormente, utilizei algumas ferramentas para monitorar a saúde dos clusters Kubernetes, como:

• Elastic Search
• Prometheus

Porém elas não conseguiram trazer tantos insumos e me alertar com antecedência em diversos cenários sobre problemas que estavam ocorrendo nos meus clusters EKS.

Reforço as palavras deste post:

Why Choose Zabbix to Monitor Kubernetes?

Before choosing Zabbix as a Kubernetes monitoring tool, we asked ourselves, “why would we choose to use Zabbix rather than Prometheus, Grafana, and alertmanager?” After all, they have become the standard monitoring tools in the cloud ecosystem. We decided that our minimum criteria for Zabbix would be that it was just as effective as Prometheus for monitoring both Kubernetes and cloud-native applications.

Through our discovery process, we concluded that Zabbix meets (and exceeds) this minimum requirement. Zabbix provides similar metrics and triggers as Prometheus, alert manager, and Grafana for Kubernetes, as they both use the same backend tools to do this. However, Zabbix can do this in one product while still maintaining flexibility and allowing you to monitor pretty much anything you can write code to collect. Regarding application monitoring, Zabbix can transform Prometheus metrics fed to it by Prometheus exporters and endpoints. In addition, because Zabbix can make calls to any HTTP endpoint, it can monitor applications that do not have a dedicated Prometheus endpoint, unlike Prometheus.

Michaela DeForest – https://blog.zabbix.com/monitoring-kubernetes-with-zabbix/25055/

Caso tenham curiosidade sobre a implantação do Zabbix no monitoramento de clusters Kubernetes, seguem alguns materiais importantes na próxima seção.

Recursos Adicionais

• Documentação Oficial do Zabbix: https://www.zabbix.com/documentation/current/
• Modelo de Monitoramento de Kubernetes do Zabbix: https://www.zabbix.com/integrations/kubernetes / https://www.zabbix.com/integrations/kubernetes#kubernetes_http
• Monitoramento de Contêineres com Zabbix: https://www.zabbix.com/br/container_monitoring
• Blog post interessante sobre o uso de Zabbix com Kubernetes: https://blog.zabbix.com/monitoring-kubernetes-with-zabbix/25055/
• Repositório contendo o Helm para provisionamento da solução no Kubernetes: https://git.zabbix.com/projects/ZT/repos/kubernetes-helm/browse

Um pouco mais

Gostou do artigo? Não deixe de se inscrever na nossa newsletter para receber as últimas novidades e dicas sobre DevOps diretamente no seu e-mail, acesse a nossa home e se inscreva no bloco “Receba as notícias por email” . Além disso, leia nossos outros conteúdos sobre Observabilidade, para continuar aprimorando suas habilidades como DevOps/SRE.