Rede sem fio com Zabbix

Otimização e descoberta automática

para monitoração

de rede sem fio na Unesp

Jessian Ferreira Cavalcanti

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

Objetivo

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

Interface original

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

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

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

Melhor aproveitamento de recursosmysql> 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 -kFilesystem 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

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

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 -kFilesystem 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

Possível perda de dados

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

Dados recuperados pelos proxies

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

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

Inicialmente

• Um protótipo de host a cada regra

• Tipo SNMP

• Intervalo de 1h

• Mas... demorava mais de um dia

Como ficou

Conexão com o “template” de AP:

Regras de descoberta

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

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

Usabilidade

Usabilidade

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

Agradecimentos