DevOps Mind
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.
Tópicos
Solução para evitar Zabbix poller processes more than 75% busy
1 – Ajustar as configurações do Zabbix Server
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
2 – Ajustar as configurações do Zabbix Proxy
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$
Melhorias / evidencias
É possível verificar através dos gráficos do Zabbix as melhorias, de uma forma bem agressiva, além dos alertas relacionados a Zabbix poller processes more than 75% busy cessarem:
Observações
Esta postagem busca trazer alguns parâmetros que foram incrementados para atender um cenário especifico, pode ser que no seu ambiente sejam necessários ajustes adicionais e/ou tentativas/testes além do esperado, conforme as particularidades do seu ambiente.
É importante cuidar o dimensionamento das máquinas envolvidas(Zabbix Server, Zabbix Proxy, etc), pois ao ajustar estes parâmetros, pode ocorrer aumento no consumo de CPU, RAM, etc.
Conclusão
Efetuando todos os passos mencionados, iremos otimizar nosso Zabbix Server + Zabbix Proxy de uma boa forma, para evitarmos novas ocorrencias do Zabbix poller processes more than 75% busy e telas como esta:
Zabbix + Kubernetes
Venho utilizando o Zabbix para monitorar a saúde de diversos componentes dos meus clusters Kubernetes, onde o Zabbix tem feito um monitoramento muito efetivo, cobrindo diversos items relevantes de diversos componentes.
Nesta página é possível verificar os items e triggers cobertos em cada template, são várioooos:
Navegando em cada aba, é possível checar a quantidade de items/triggers para cada um deles.
Esta é a arquitetura de referência da estrutura de monitoramento para clusters Kubernetes utilizando o Zabbix:
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
Aprenda mais
Não deixe de se inscrever na nossa newsletter para receber as últimas novidades e dicas sobre DevOps/SRE diretamente no seu e-mail:
Além disso, leia nossos outros conteúdos sobre Observabilidade, para continuar aprimorando suas habilidades como DevOps/SRE e sobre este tema tão importante.