O documento discute a importância do monitoramento e da observabilidade para identificar problemas nos sistemas antes que aconteçam e entender as causas quando acontecem. Também fornece dicas sobre como realizar troubleshooting de forma estruturada utilizando checklists e evitando armadilhas comuns.

1. MANDIC + RIVENDEL.
ESPECIALISTAS EM CLOUDS.
Diego Lakatos
Apertem os cintos - O
servidor caiu

2. 2
SOBRE MIM
+Rivendel desde Junho de 2017
+Tech Lead do Team 42

3. História
baseada em
fatos reais

8. Os sistemas estão cada vez mais complexos.
Como chegamos aqui???

11. ● Automação cada vez maior em configuração,
gerência e deploy de software
● Humanos ainda estão no envolvidos no processo -
softwares (ainda) são desenvolvidos por humanos
● Sistemas semi-automatizados são especialmente
perigosos: O poder da automação com a
falibilidade humana
Errar é humano, propagar o erro para centenas de servidores em poucos segundos é DevOps

12. In general, we tend to measure at three
levels: network, machine, and application.
Application metrics are usually the
hardest, yet most important, of the three.
They’re very specific to your business, and
they change as your applications change
Fonte: https://codeascraft.com/2011/02/15/measure-anything-measure-everything/
Monitoramento

13. 13
Monitoramento
+Identificar problemas antes que eles aconteçam
+Alertar assim que o problema acontece
+Monitoramento só alerta para problemas conhecidos
+Monitoramento deve ser adaptável, templates são pontos de partida e não
de chegada
+Somente um monitoramento tradicional não garante que você saiba o que
está acontecendo
+Agregação de dados ajuda a ter informação e informação leva a
conhecimento

14. The Observability Engineering team at Twitter provides
full-stack libraries and multiple services to our internal
engineering teams to monitor service health, alert on
issues, support root cause investigation by providing
distributed systems call traces, and support diagnosis
by creating a searchable index of aggregated
application/system logs. These are the four pillars of the
Observability Engineering team’s charter:
● Monitoring
● Alerting/visualization
● Distributed systems tracing infrastructure
● Log aggregation/analytics
Fonte: https://blog.twitter.com/engineering/en_us/a/2016/observability-at-twitter-technical-overview-part-i.html

15. Your monitoring system should address two
questions: what’s broken, and why? The “what’s
broken” indicates the symptom; the “why”
indicates a (possibly intermediate) cause.“What”
versus “why” is one of the most important
distinctions in writing good monitoring with
maximum signal and minimum noise.
Livro de SRE do Google

16. Monitorar e observar o lugar certo

17. O monitoramento deve ser claro

18. OK… Mas o servidor
ainda não está
funcionando

19. Em primeiro lugar

20. Algumas considerações
● Restabelecer o sistema ou entender o que está
acontecendo?
● Muito foco na recuperação pode causar ações
não relacionadas que pioram a situação
● Recuperação em detrimento de entendimento
torna normal um software quebrado
● Restabelecer o sistema preservando o máximo
de informação

21. Em segundo lugar

22. Runbooks

25. 25

26. 26

28. 28
E agora?
+ 3 W (what, where,why)
+ O log é seu amigo (by Pedreira)
+ Se comunique, informe as suas ações e por que você vai fazer
+ Faça um backup dos arquivos de configuração antes de realizar qualquer
alteração
+ Pense em todos os componentes do sistema (matriz de resiliência)
+ Verifique as coisas simples primeiro

29. 29
+ Sistemas tem inércia, se nada foi alterado é provável que ele continue
rodando
+ Guarde o máximo de informação possível
+ Você não é uma máquina, se estiver muito cansado e for possível passe o
bastão para outra pessoa
+ Separe as ações entre diferentes pessoas
+ Troubleshoot pode ser ensinado e aprendido
+ Entender como o sistema foi desenhado e construído facilita o
troubleshoot
+ Correlação não implica causa
+ Minimize impactos -- mantenha o avião voando

30. 30
E agora? Hora do Troubleshoot

31. Checklists

32. 32
Checklists
+Sequência de passos que devem ser seguidos ou itens a serem verificados
+Velocidade
+Ponto de partida
+Instruções rapidas

33. 33

34. 34
Uma checklist da Netflix

35. 35
Checklist de performance no Linux
+ uptime -- load do servidor, a quanto tempo está ligado
+ dmesg -T | tail -- buffer do kernel em uma timestamp legivel
+ vmstat 1 -- informações sobre memória atualizadas a cada 1 segundo
+ mpstat -P ALL 1 -- informações sobre os processadores
+ pidstat 1 -- informações sobre as tasks em execução
+ iostat -xz 1 -- informações sobre operações de IO com mais estatísticas e
output limpo
+ free -m -- informações sobre utilização de memória
+ sar -n DEV 1 -- informações sobre os devices de rede
+ sar -n TCP,ETCP 1 ---- informações sobre tráfego TCP e erros no TCP
+ htop/top

36. 36
Coisas a se observar num cenário cloud
+ Carga -- requests/segundo -- Qual tipo de request?
+ Erros -- Códigos de erros, timeouts, retries
+ Latência - Média e percentil 99
+ Saturação - Load Average das máquinas -- tamanho de filas
+ Instâncias - Quantidade, tipo, scale up/down
Que tal juntar tudo isso numa dashboard?

37. 37

38. 38

39. 39
Armadilhas
+ Olhar para sintomas que não tem relação com o problema reportado ou
não entender o significado das métricas
+ Não entender como alterar o sistema, inputs ou o ambiente como um
todo, para conseguir realizar testes com facilidades
+ Viajar na maionese - criar teorias mirabolantes ou automaticamente
referenciar um problema do passado.
+ Procurar por correlações que são apenas coincidências ou são
relacionadas por possuírem a mesma causa raiz.

41. 41
Problema resolvido?
+ Documente os passos usados para resolver o problema
+ Analise as informações recolhidas e descubra a causa-raiz
+ Post-mortem -- aprenda com a falha
+ Tome medidas para não acontecer de novo
+ Documentação nunca tem fim a sua melhoria é um processo iterativo,

42. 42
Links úteis
+ Monitoring and Observability -
https://medium.com/@copyconstruct/monitoring-and-observability-8417d1952e1c
+ What we can learn from a nuclear
reactor-https://www.ft.com/content/cea7b256-1def-11e0-badd-00144feab49a
+ GOTO 2017 • Debugging Under Fire: Keep your Head when Systems have Lost their Mind • Bryan
Cantrill - https://www.youtube.com/watch?v=30jNsCVLpAE
+ SREcon16 - Performance Checklists for SREs -
https://www.youtube.com/watch?v=zxCWXNigDpA

43. diego.lakatos@rivendel.com.br
rivendel.com.br
mandic.com.br
Diego Lakatos