Monitoracao Inteligente na Globo.com

Monitoração Inteligente Denis A. Vieira Jr. Ricardo Clemente

Monitoração Inteligente

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Correlação de eventos

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Motivação:

Monitoração pontual

Tempo de atuação/resolução de problemas

Precaução

Visão realista da produção

Motivação:

Aprendizado (desvio de padrão)

Automação

Dados históricos sem perda

Credibilidade (Situational Awareness)

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Onde estamos:

Muita informação (1200 servidores com mais de 14000 monitorações) - mais de 40000 gerando gráficos

Diversas ferramentas de monitoração em uso (SME, IPMonitor, Cricket, SiteScope, SiteSeer) - Nagios

Dificuldades com customizações específicas, performance e custo

Falta de credibilidade (muitos emails) porém com boas iniciativas

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Para onde vamos:

Utilização de eventos. Ex.: Appenders para frameworks de logs integrando as aplicações atuais

Experiência para antecipar

situações

Interface unificada de

monitoração

Detecção de causa raíz

através de causas conhecidas

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Plano de ação:

Unificar a ferramenta de monitoração com Nagios (escalabilidade e integração)

Integração dos sistemas de monitoração usando NEB com o sistema de correlação de eventos

disponível em:

code.google.com/p/neb2activemq

Mapeamento de eventos e sistemas

para correlação (manual e analítico)

Agenda:

Motivação

Onde estamos

Para onde vamos

Plano de ação

Visão Geral e Arquitetura do sistema

Barramento de Eventos

Tecnologia de correlação

Motor de Correlação

Visualização

Aprendizado de Máquina

Projeto

Visão geral e arquitetura do sistema

Arquitetura modular e orientada a eventos

BARRAMENTO DE EVENTOS MOTOR CORRELAÇÃO APRENDIZADO DE MÁQUINA COLETOR VISUALIZAÇÃO

Qual é a arquitetura do sistema?

Barramento único para troca de mensagens

Módulos são processos separados no sistema operacional e podem estar em máquinas diferentes

Módulos podem publicar e/ou consumir eventos de filas/tópicos do barramento

Porque utilizar uma arquitetura orientada a eventos (Event Driven Architecture) ?

Desacoplada e Distribuída

Menos intrusivo aos sistemas monitorados

Módulos são independentes

Visão geral e arquitetura do sistema

Barramento de eventos

Projeto de software livre

Escolha feita pelo Apache ActiveMQ:

Estabilidade

Performance

Comunidade Ativa

Conectividade

JMS

STOMP

REST

XMPP (...)

Barramento de eventos

Formato da mensagem

JSON ( e não XML)

Simplicidade

Composição

Header : tipo de canal (fila ou tópico) e o tipo do evento

Body: dados

$ curl -d "type=queue&body={'idle'=70, 'sys’=20, 'usr'=10, 'host'='ws122' }&eventtype=CPU" http://barramento/message/events;

CEP (Complex Event Processing )

Tecnologia que permite processar em tempo real múltiplos eventos com o objetivo de identificar eventos significativos

Baseado em regras ou consultas (“SQL like”)

Consultas criadas em tempo de execução

Origem

Em 1995 o professor David Luckham de Stanford, trabalhando no projeto Rapide criou o termo CEP

Linha de pesquisa de banco de dados: Data Stream Management Systems (DSMS)

Tecnologia de correlação Processamento de consultas Memória Dados Dados Dados Relações persistentes consulta resposta Processamento de consultas Memória dados dados consulta contínua resposta fluxos de dados “ banco de dados ao contrário”

Mercado

Tendência (Buzz)

Mercado de CEP é estimado em 460 milhões de dólares em 2010 (fonte: IEEE Computer Society – Abril 2009)

Aplicável onde exista um grande fluxo de dados e a necessidade de se extrair informação em tempo real destes dados

Mercado financeiro

Processos de logística (RFID)

Controle aéreo

UTIs

Datacenters

Tecnologia de correlação Big Players

Players de software livre

Projetos acadêmicos:

STREAM – Stanford – 2003 (oficialmente descontinuado)

TelegraphCQ – Berkeley - 2003

Baseado no PostgreSQL 7.3.2

Sem atividade

Cayuga – Cornell

Projeto de uma empresa:

Esper, projeto no codehaus

Completo funcionalmente

Excelente documentação

Performance!

Motor de correlação Se a sessão aumentar 10% no front-end dentro de 3 minutos e a média das cpus da farm do front não subir 5% e no banco o número de queries lentas for maior que 10, então está caracterizada uma contenção no banco de dados gerando enfileiramento de usuários Aplicação

Motor de correlação Aplicação Mysql Server Vip t – 3 min t t – 3 min t t cpu_usr slow_query session

Motor de correlação SELECT Server.host , Server.cpu_usr, Server_PAST.cpu_usr, Vip.session, Vip_PAST.session, Mysql.slow_query FROM Server.win:time(1 min) as Server , Server.win:ext_timed(current_timestamp(), 3 min) as Server_PAST , Vip.win:time(1 min) as Vip , Vip.win:ext_timed(current_timestamp(), 3 min) as Vip_PAST , Mysql.win:time (1min) as Mysql HAVING Vip.session > Vip_PAST.session * 1.10 AND avg(Server.cpu_usr) < avg (Server_PAST.cpu_usr) * 1.05 AND Mysql.slow_query > 10 Aplicação

Motor de correlação

Identificando um outlier

select host, free, avg(free)

from Memory.win:time(240 sec) group by host

having free < avg(free)

Sequência de eventos

select * from

pattern [every Memory(free < 10) ->

(timer:interval(60 sec) and Log(text like ‘%OutOfMemory%’)) ]

Horários e extensões

select idle from pattern [every timer:at(*, [16:22], *, [0,3], *) ].win:time(30 sec), CPU.win:time(30) where idle < 30 AND Filter.isInNode (id, "Tempo Real")

Motor de correlação Fonte: Esper Performance - http://docs.codehaus.org/display/ESPER/Esper+performance Performance Esper Item Especificação HW Servidor Esper 2 x Intel Xeon 5130 2GHz (4 cores total), 16GB RAM VM config -Xms2g -Xmx2g -Xns128m -Xgc:gencon Consulta # cons. evt/s Latência Latência média Nota select '$' as ticker from Market(ticker='$').win:length(1000).stat:weighted_avg('price', 'volume') output last every 30 seconds 1000 519 728 99.66% < 10us 2.8us CPU com 85%, 70 Mbit/s

Motor de correlação Processamento no Motor de Correlação

Visualização – Console Consultando o ambiente em tempo real

Visualização – Troubleshooting Antecipando e resolvendo mais rápido incidentes

Visualização - Dashboard Visão consolidada de serviços

E para as regras que não são conhecidas?

Aprendizado de máquina

Opção por algoritmos não-supervisionados e incrementais

Algoritmo PCA Incremental

Transforma um número de variáveis possivelmente correlatas em um número menor de variáveis não-correlatas, os componentes principais

Uma mudança nos componentes principais significa uma quebra da correlação existente, ou anomalia

Pode ser usado para compressão de dados

Inspiração em artigo da Carnegie Mellon University (Hoke et al. 2006)

Fonte: http://www.pdl.cmu.edu/PDL-FTP/SelfStar/osr_sub.pdf

Implementação teve dois desafios principais: medidas sem valor e diferentes escalas

Aprendizado de máquina 60 sinais de entrada

Aprendizado de máquina Resumido em 1 componente principal + matriz de geração

Aprendizado de máquina componente principal 2 sensibilidade três anomalias

Projeto

Andamento

Funcionalidades desenvolvidas

Algoritmos sendo validado por testes em RRDs e reuniões com operação

Testes de carga e robustez em andamento

Sistema em produção com escopo reduzido com expectativa de produção integral em julho

Projeto na Globo.com – Próximos desafios

Escalar o sistema

“ Sharding” de eventos

Balanceamento de regras

Cache

Aperfeiçoar algoritmos

Controle adaptativo de parâmetros de memória e sensibilidade

Inserir camada supervisionada

Outros algoritmos e como eles podem cooperar

Monitoração Inteligente Considerações finais

Referências http://delicious.com/fisl10

Dúvidas

Contatos

Denis A. Vieira Jr

[email_address] (www.globo.com)

Ricardo Clemente

[email_address] (www.intelie.com.br)

Estande da Globo.com

Hoje a tarde toda

Levante a mão!

Monitoracao Inteligente na Globo.com

1 comments

Notes on slide 1

6 Favorites