O objetivo desta apresentação é explorar implementações de monitoração sem se ater somente a ferramentas. Melhores práticas aplicáveis a todos os tamanhos de infraestrutura, aprofundando no que deu certo e funcionou 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. Também irá abordar como a monitoração pode ser integrada ao ciclo de desenvolvimento de sistemas e seus desafios e benefícios.
Gerente de Operações na Locaweb, com mais de 20 anos de experiência em administração de sistemas, Marcus Vechiato concebeu, implantou, integrou e gerenciou sistemas em larga escala com milhares de servidores e múltiplos data centers. Viciado em soluções opensource e novas tecnologias.
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.
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.