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.
Apontamentos pessoais acerca de sistemas operativos, mais concretamente, acerca de Processos e Threads.
Erros ortográficos existentes, pelo que se sugere que se ignorem os mesmos.
Apontamentos pessoais acerca de sistemas operativos, mais concretamente, acerca de Processos e Threads.
Erros ortográficos existentes, pelo que se sugere que se ignorem os mesmos.
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...Gleicon Moraes
Apresentação com Renato Lucindo(https://github.com/lucindo) para o DNAD 2015 Esta apresentação é uma evolução do material que apresentamos anteriormente na QCon.
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.
Monitoração - muito além do sistema operacional - WeOp 2014Marcus Vechiato
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.
Muitos desenvolvedores se preocupam bastante com os aspectos estáticos dos sistemas que constroem, tais como se o código está bonito, se está idiomático, se está seguindo um determinado styleguide, entre outros bullet points do bom design de código; e isso é muito bom. Mas isso não é tudo. Há ainda o aspecto real da coisa, o Runtime. É no Runtime que ômis e mininus se sobressaem. E essa apresentação é sobre com o que os ômis mais se preocupam quanto estão escrevendo sistemas críticos – para o Mundo Real, é lógico.
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...Gleicon Moraes
Apresentação com Renato Lucindo(https://github.com/lucindo) para o DNAD 2015 Esta apresentação é uma evolução do material que apresentamos anteriormente na QCon.
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.
Monitoração - muito além do sistema operacional - WeOp 2014Marcus Vechiato
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.
Muitos desenvolvedores se preocupam bastante com os aspectos estáticos dos sistemas que constroem, tais como se o código está bonito, se está idiomático, se está seguindo um determinado styleguide, entre outros bullet points do bom design de código; e isso é muito bom. Mas isso não é tudo. Há ainda o aspecto real da coisa, o Runtime. É no Runtime que ômis e mininus se sobressaem. E essa apresentação é sobre com o que os ômis mais se preocupam quanto estão escrevendo sistemas críticos – para o Mundo Real, é lógico.
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
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
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
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?
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.
40.
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