monitoração - muito além do sistema operacional - weop 2014
DESCRIPTION
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.TRANSCRIPT
WeOp 2014
Marcus Vechiato - @vechiato
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
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.
Como pensamos em um sistema de monitoração
?
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
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 cadaminuto
~17 mil incidentes tratados por mês
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
O que monitorar ?
Infraestrutura e serviços Core – rede/no breaks/temperatura/DNS
Sistema Operacional (memória/cpu/redelocal/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
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
Onde alguns se perdem
É comum o diagnóstico: “a ferramenta xpto nãofunciona, precisamos de uma nova”
Intervalo entre probes de monitoração muitopequeno
Re-tentativas são importantes pra diminuir falsospositivos
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
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
ITIL e Ferramentas de ITSM
Ferramentas de ITSM Recomendo fortemente
Se pretende abrir incidentes automaticamente gaste maistempo 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
Abertura automática de incidentes
Alguns benefícios da abertura automática em ambientesmaiores:
Equaciona a ineficiência de registro manual de incidentes
Registra falhas no momento que ocorrem
Permite pré-definir importância de cadacomponente/serviço e em caso de falha priorizar suaresolução
Diminuir a resolução informal de incidentes semregistro
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
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
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
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
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)
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.
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.
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.
Perguntas ?