O objetivo desta apresentação é explorar implementações de monitoração sem me ater somente a ferramentas. Melhores práticas aplicáveis a todos os tamanhos de infraestrutura, no que deu certo e no aprendizado dos erros cometidos nestes anos, incluindo automação de configurações, ferramentas, processos, pessoas e como atingir e manter a eficiência.

1. WeOp 2014
Marcus Vechiato - @vechiato

2. Agenda
 Objetivo
 Como pensamos em um sistema de
monitoração ?
 Do simples ao complexo
 O que monitorar ?
 O que acompanhar ?
 Alguns números da Locaweb
 Onde alguns se perdem
 Automação de configurações
 Itil e Ferramentas de ITSM
 Abertura automática de Incidentes
 Ferramentas já utilizadas
 Desafios

3. Objetivo
Objetivo desta apresentação é explorar
implementações de monitoração sem me ater à
ferramentas.
Melhores práticas destacando o que deu certo e
o aprendizado dos erros cometidos ao longo
destes anos.

4. Como pensamos em um sistema de monitoração
?

5. Como pensamos em um sistema de monitoração
?
 Não é apenas uma ferramenta
 A ferramenta de monitoração é um dos
componentes do processo
 Processo - pode nos remeter à burocracia se
não for efetivo

6. Alguns números da Locaweb
 Equipamentos de Rede
 Brocade / Cisco / Force10 e outros
 ~21 mil servidores (físicos e virtuais)
 Windows (2003/2008/2012)
 Linux (CentOs/Redhat/Debian)
 Oracle/MySql/Postgre/MSSQL/Mongo DB
 VmWare/Xen
 ~500 mil ítens/serviços monitorados a cada
minuto
 ~17 mil incidentes tratados por mês

7. Do simples ao complexo
 Tenha claro quais são suas maiores dores pra
definir seus objetivos
 Não idealize o sistema perfeito que cobrirá
todos os GAPs, ele não existe
 Lembre-se: quais são seus recursos e quais as
reais habilidades do time
 Prefira uma implementação gradual com
entregáveis bem definidos

8. O que monitorar ?
 Infraestrutura e serviços Core – rede/no
breaks/temperatura/DNS
 Sistema Operacional (memória/cpu/rede
local/disco) onde aplicável
 Aplicações
 Visão do usuário (requisição http/tcp)
 Local (uso de memória/threads/processos/etc)
 Indicadores de Negócio/erros
 Ex.: Vendas por hora
 Ex.: Falhas de autenticação por minuto

9. O que acompanhar ?
Converter a visão de indicadores de
infraestrutura para produtos/componentes/times
 Dashboards para públicos diferentes
 Operações
○ Visão de Indicadores por times/infraestrutura
 Ex.: MTTR de incidentes do N1 por prioridade
 Ex.: SLA e MTTR de storage abc
 Produtos/Negócio
○ Visão de Indicadores comuns e específicos
 Ex.: SLA do produto xpto 99,89%
 Ex.: MTTR do produto xpto 0h45m

10. Onde alguns se perdem
 É comum o diagnóstico: “a ferramenta xpto não
funciona, precisamos de uma nova”
 Intervalo entre probes de monitoração muito
pequeno
 Re-tentativas são importantes pra diminuir falsos
positivos
 Minha experiência:
 Intervalo de probes padrão entre 1 e 5 minutos
 Re-tentativas:
○ 5m durante a implantação/com instabilidades conhecidas
○ 3m em ambientes estavéis

11. Automação de configurações
 A monitoração é o melhor lugar pra começar a
gerenciar a instalação de componentes e
configurações
 começe com o agente de monitoração (se houver)
 Servidor de monitoração
○ Via API onde for possível
○ Arquivos de configuração
 Qual ferramenta usar pra automação ?
 Depende do seu ambiente e conhecimento do time.
Chef e Puppet são boas opções pra começar

12. ITIL e Ferramentas de ITSM
 Ferramentas de ITSM
 Recomendo fortemente
 Se pretende abrir incidentes automaticamente gaste mais
tempo avaliando qual será sua ferramenta
 Processos são a espinha dorsal
 Gestão de Incidentes
 Gestão de Problemas
 Gestão de Mudanças
 CMDB – registro/controle é mandatório
 Em instalações pequenas sua ferramenta de monitoração
é seu CMDB
 Em ambientes maiores você terá que sincronizá-lo com a
ferramenta de ITSM

13. Abertura automática de incidentes
Alguns benefícios da abertura automática em ambientes
maiores:
 Equaciona a ineficiência de registro manual de
incidentes
 Registra falhas no momento que ocorrem
 Permite pré-definir importância de cada
componente/serviço e em caso de falha priorizar sua
resolução
 Diminuir a resolução informal de incidentes sem
registro
 Subsídio para análise profunda do ambiente
 Integrada à gestão de crises reduz o tempo de
resolução e melhora a comunicação relacionada
 Cálculo realista de OLA’s e SLA’s

14. Abertura automática de incidentes
 Integração via:
 API preferencialmente (rest/soap)
 E-mail – com templates, a maioria das ferramentas permitem
(só use em último caso)
 Utilize a prioridade ao abrir o incidente para permitir a
priorização pelo time resolvedor. Segundo Itil, de 1-5:
 Prioridades (pense numa pirâmide):
○ 1 e 2: tem que ser menos de 10% dos incidentes
○ 3: 30%
○ 4: 40%
○ 5: 10%
 Pra cada prioridade defina seus diferentes OLA’s de resolução.
Lembre-se que isto vai afetar diretamente o tamanho dos times
resolvedores

15. Abertura automática de incidentes
 Re-abertura automática de incidente caso seja
resolvido e continue falhando na monitoração
ou falhe novamente em menos de 30m
 Novo incidente no caso de novo alarme após
30m do último incidente resolvido
 Não abrir incidentes durante manutenções
programadas

16. Abertura automática de incidentes
 Fechamento automático de incidentes caso a
monitoração normalize antes de atuação do
time com status de “sem intervenção” permite:
 refinar a solução e sua eficiência
 ajuste de thresholds muito justos
 Informações para abertura de Problemas
 Falhas de planejamento/execução em mudanças
 Retomar rapidamente o tratamento de incidentes
após eventos com centenas/milhares de incidentes
abertos em curto período de tempo

17. Ferramentas já utilizadas
 Monitoração:
 Nagios
 Check_mk – Locaweb
 Zabbix
 ITSM:
 Service Now (API) – Locaweb
 CA – Service Desk Manager (API) – Locaweb
 HP – Service Center (API)
 OTRS – (API)

18. Desafios
 Regra de Ouro: “Todo alarme tem que ter uma
atuação corretiva” nem que seja ajustar os
thresholds em caso de falso positivo.
 Não se engane – no ínicio você vai ter muitos
falsos positivos. É preciso persistência.
 Se você não fechar incidentes
automaticamente durante instabilidades,
normalmente de rede, você vai ficar soterrado
em incidentes e vai deixar de ver alarmes
importantes quando a instabilidade cessar.

19. Desafios
 Quem implementa a solução e quem
administra o dia a dia ?
 Implementação da solução: naturalmente o
time/pessoa mais Sênior
 Quem deve incluir as monitorações no sistema ? Se
pensou no estagiário ou nas pessoas mais Júniores
do time pensou errado. Também é responsabilidade
dos mais Sêniores.

20. Desafios
Mais importante que as ferramentas são as pessoas
e aderência aos processos definidos, de ponta a
ponta.
Revisite os processos periodicamente para ajustar e
evoluir de acordo com as necessidades correntes
Se algum processo não está funcionando, mude-o.
Não permita que ele seja abandonado ou burlado.

21. Perguntas ?