Caminhos para um sistema automatizado de

monitoraçãoFrancisco Freire (@ffreire)

Gleicon Moraes (@gleicon)

Agenda

• Cenário• Motivação• Premissas• Requisitos• Tecnologia• Integração• Resultado

Cenário

• Informações decentralizadas• Diversos sistemas de monitoração

diferentes• Nenhum baseline• Cada um por si

+ 15k Servidores+500 Equipamentos de rede (+28k

portas)

Motivação

• Acabar com sistemas legados (Nagios, Zabbix, Cacti e outros). • Criar automação (Servidores sendo inseridos

manualmente, necessidade de edição de arquivos de configuração ). • Nagios: Funcional, porém extremamente complicado

(Arquivos de configuração).• Zabbix: Funcional, porém tem extrema dependência de

sua base de dados.

Premissas

• Criar um ambiente de monitoração automatizado e integrado ao nosso cmdb, garantindo que todo e qualquer novo produto ou serviço vá para produção totalmente monitorado. 

• Usar dados de monitoração para ter SLA em tempo real e capacity planning de serviços. 

• Integrar a monitoração ao desenvolvimento de cada produto.

Requisitos

• Automação / Integração: Tudo tem que ser automatizado e de fácil integração com outros produtos / serviços.• Administração: Ter simples administração, e ser fácil de

escalar horizontal e/ou verticalmente.• Gráficos: Necessário para uma melhor análise.• Multiplataforma: Possibilidade de monitorar "n"

sistemas operacionais diferentes.• Prazo: O mais curto possível!

Tecnologiahttp://www.icinga.org/ (Backend de monitoração):- Escolhido devido a compatibilidade com o Nagios e em nossos testes apresentou uma performance cerca de 10% maior.http://mathias-kettner.de/check_mk.html (Frontend de monitoração):- Apelidado de descomplicador de Nagios, além de facilitar a geração de arquivos de configuração do Nagios, oferece um dashboard que possui fácil integração, centralizado, transforma todas as checagens em passivas e query própria para status de serviços.http://www.python.org/ (Linguagem oficial):- Escolhida devido ao conhecimento atual da equipe e facilidade de desenvolvimento, utilizada como core de monitoração integrada com o check_mk.

http://www.golang.org/ (Linguagem extra):- Scripts que necessitam de uma maior performance/resultado -> go.

http://www.djangoproject.com/ (Frontend gráficos):- Framework para dashboard / frontends desenvolvidos internamente, escolhido devido ao nosso core ser python.

https://github.com/locaweb/leela (Backend gráficos):- Sistema desenvolvido internamente para armazenamento de dados de performance.

http://redis.io/ (Backend NoSQL):- Armazenamento de fila e dados temporários, não utilizamos persistência.

Check_MK

• Plugins personalizados.

• Checagem passiva.

• Inventário.

• Livestatus.

• Livecheck.

• Event Daemon.

Livestatus• http://mathias-kettner.de/checkmk_livestatus.html

Redis

• Redis é single-process

• Multi-instâncias

• Shard utilizando: https://github.com/twitter/twemproxy

• Alto uso de cpu, resolvido com balanceamento utilizando IPTABLES.

• Twemproxy aka nutcracker, rodando em todos os clients para diminuir a quantidade de conexões TCP.

Redis+ Nutcracker + Iptables

Configuração

• Configuração descritiva em formato yaml.

• Replicação via cfengine

• Versões para aplicação / hardware / baseline

• Todo tipo de alteração pode ser feita em um único arquivo (Threesholds, priorização, etc)

Integração

Alarmes na monitoração, geram incidentes e são automaticamente comentados no Icinga.

Gráficos de Performance

Sla

Números

• 16k+ Hosts• 280k+ Serviços• 25k+ Escritas por segundo (Monitoração por log)• 10k+ Dados de performance por segundo• 1k+ Items de SLA• 1k+ Incidentes dia

Estrutura Final

Resultado

• Total automação e integração com CMDB. (Bonus: CMDB em dia)• Total integração com Ferramenta Itil para

gerenciamento de incidentes.• Melhor integração com nossos produtos.• Melhor e mais rápida análise de problemas.• Maior conhecimento do ambiente.• Maior número de items monitorados.

Dúvidas?