The wireless network monitoring data are abundant, as it seems relevant store information from devices and users connected, especially in an multicampus environment like Unesp. In this sense, the database tends to increase rapidly the number of records, being necessary to optimize the periodic cleaning routine of Zabbix data. Here are our way of improving the functioning of the "housekeeping" native application. Also will demonstrate the massive use of the data type "Zabbix Trapper" for flexible the list of informations of Wi-Fi infrastructure and techniques varied use of "low level discovery" for monitoring of wireless access points.

1. Rede sem fio com Zabbix
Otimização e descoberta automática
para monitoração
de rede sem fio na Unesp
JessianFerreiraCavalcanti
Jessian@unesp.br
GRC – Grupo de Redes de Computadores
Assessoria de Informática - Reitoria
Univ Estadual Paulista "Júlio de Mesquita Filho"
Unesp
Zabbix LatAm 2016
Porto Alegre, 15 de abril de 2016

2. Objetivo

3. Grandezas
• 24 municípios
• 1500 hosts (pontos de acesso ou APs)
• 15000 usuários simultâneos
• 3 controladoras
• Zabbix: 1 servidor + 3 proxies + 2 DB + 1 frontend
• 300 Milhões de registros (tabela history_uint)
• 60 Gigabytes de espaço em disco
• 5 Horas para otimização

5. Interface original

6. Monitoração
• Experiência com interface “feita em casa”
• Atingido limite do equipamento
• Lentidão no acesso aos dados
• Zabbix poderia solucionar
• Mesmo assim, SNMP puro torna-se impraticável:
• Dados de clientes + Fonte de auto-descoberta (LLD)
• Solução: SSH + Zabbix trapper
• Mas o espaço em disco não parava de crescer

7. Direto ao ponto
• Dicas para otimizar tabelas estão nos fóruns
• Abordagem de DBA
• Previsão do espaço em disco necessário
• Tempo de armazenamento de histórico

8. Tempo para otimização
• mysql> optimize table history_uint;
• Valores para apenas uma tabela
• 5h com 16GB de RAM
• 11h com 8GB + swap
• Houve de fato economia de espaço no HD
• Decisão: fazer no fim-de-semana ou à noite
• Lidar com possível perda de dados

9. Melhor aproveitamento de recursos
mysql> show table status like 'hist%';
Name Rows Data_length Create_time Avg_row_length
history 2726503 143818752 2015-11-09 19:00:25 52
history_log
history_str
history_text
history_uint 276695630 14453571584 2016-02-16 21:38:48 52
root@zabbix-mysql01-19:~ # df -k
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/ada0p2 47110168 16290224 27051132 38% /
devfs 1 1 0 100% /dev
/dev/ada1s1 101546248 44057788 49364764 47% /var/db/mysql/zabbix
root@zabbix-mysql01-19:~ # ls -l /var/db/mysql/zabbix/history_*
-rw-rw---- 1 mysql mysql 8834 Aug 27 16:39 /var/db/mysql/zabbix/history_log.frm
-rw-rw---- 1 mysql mysql 335544320 Feb 3 17:31 /var/db/mysql/zabbix/history_log.ibd
-rw-rw---- 1 mysql mysql 8654 Aug 27 16:39 /var/db/mysql/zabbix/history_str.frm
-rw-rw---- 1 mysql mysql 9437184 Feb 24 07:42 /var/db/mysql/zabbix/history_str.ibd
-rw-rw---- 1 mysql mysql 8680 Oct 29 01:15 /var/db/mysql/zabbix/history_text.frm
-rw-rw---- 1 mysql mysql 14730395648 Feb 24 08:20 /var/db/mysql/zabbix/history_text.ibd
-rw-rw---- 1 mysql mysql 8654 Feb 16 16:29 /var/db/mysql/zabbix/history_uint.frm
-rw-rw---- 1 mysql mysql 26549944320 Feb 24 08:20 /var/db/mysql/zabbix/history_uint.ibd

10. Parênteses
Quais valores são confiáveis?
1. Tamanho do arquivo
2. Número de linhas
3. Comprimento dos dados
4. Espaço em disco
5. Data
6. n.d.a

11. Após outro “optimize”
mysql> show table status like 'hist%';
Name Rows Data_length Create_time Avg_row_length
history 2726503 143818752 2015-11-09 19:00:25 52
history_log
history_str
history_text
history_uint 276695630 14453571584 2016-02-24 23:31:13 52
root@zabbix-mysql01-19:~ # df -k
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/ada0p2 47110168 16290776 27050580 38% /
devfs 1 1 0 100% /dev
/dev/ada1s1 101546248 41316956 52105596 44% /var/db/mysql/zabbix
root@zabbix-mysql01-19:~ # ls -ltr /var/db/mysql/zabbix/history_*
-rw-rw---- 1 mysql mysql 8654 Aug 27 16:39 /var/db/mysql/zabbix/history_str.frm
-rw-rw---- 1 mysql mysql 8834 Aug 27 16:39 /var/db/mysql/zabbix/history_log.frm
-rw-rw---- 1 mysql mysql 8680 Oct 29 01:15 /var/db/mysql/zabbix/history_text.frm
-rw-rw---- 1 mysql mysql 335544320 Feb 3 17:31 /var/db/mysql/zabbix/history_log.ibd
-rw-rw---- 1 mysql mysql 8654 Feb 24 11:41 /var/db/mysql/zabbix/history_uint.frm
-rw-rw---- 1 mysql mysql 9437184 Feb 24 12:38 /var/db/mysql/zabbix/history_str.ibd
-rw-rw---- 1 mysql mysql 14763950080 Feb 24 12:44 /var/db/mysql/zabbix/history_text.ibd
-rw-rw---- 1 mysql mysql 23676846080 Feb 24 23:29 /var/db/mysql/zabbix/history_uint.ibd

12. Possível perda de dados

13. Monitoração com proxies
• Armazenamento temporário e divisão de tarefas
• Represamento dos dados durante manutenção
• Toda monitoração a ser feita através de proxy
• Atenção aos parâmetros do tipo “trapper”: agente
deve saber para qual proxy enviar os dados
• Um proxy estava com tempo de buffer padrão 1h
• Dados no período entre 11h30 e 16h00
completamente recuperados somente para dois hosts
• Buffer na config dos proxies era maior

14. Dados recuperados pelos proxies

15. Outro aspecto da otimização
• Melhorar periodicidade da monitoração e da
descoberta automática (fila muito grande)
• Comandos SSH através de Python + Netmiko
• Saída enviada para itens do tipo Zabbix Trapper
• Também utilizado em UserParameter (Agente)
• Quantidade de processos em cada proxy: lembrar que
os dados são obtidos de um único equipamento

16. Configurando a LLD
• Low Level Discovery
• Usada em duas etapas
• Protótipo de host + Protótipo de item
• Novos hosts (APs) gerados a partir da monitoração de
cada controladora
• Novos itens gerados em cada host
• Template/Gabarito

17. Inicialmente
• Um protótipo de host a cada regra
• Tipo SNMP
• Intervalo de 1h
• Mas... demorava mais de um dia

18. Como ficou
Conexão com o “template” de AP:

19. Regras de descoberta

20. Enviando parâmetros
• Como era a macro via SNMP:
{#SNMPINDEX}
• Como ficou via Trapper:
{#HOSTNAME}
• Scripts usam protocolo Zabbix Sender
• Várias APIs em Python disponíveis

21. Monitoração de ponto de acesso (AP)
Apenas os itens criados por protótipos são monitorados via SNMP:
Neste caso, as regras são alimentadas através de agente Zabbix
Os scripts em Python, por sua vez, são acionados por UserParameter

22. Usabilidade

23. Usabilidade

24. Próximos passos
• Monitoração de clientes
• Melhorias nos scripts em Python
• Listagem de erros de autenticação
• Melhoria nos critérios para os Triggers
• Infraestrutura monitorada com Zabbix
• Weathermap
• Zabbix 3.0

25. Agradecimentos