Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TDC 2017 - Borg até o Prometheus: Site Reliability Engineering

314 views

Published on

Apenas monitorar a infraestrutura não é o bastante, com as modernas arquiteturas de software e a necessidade de rápida entregas de software, começaram a exigir uma monitoria inteligente. Partindo do paper do Google apresentando o Borg iremos abordar os benefícios e técnicas para identificação de erros de forma granular traduzindo 0 e 1 para negócios.

Com histórico de métricas ?Time-series based?, alertas poderoso, bibliotecas de instrumentação em Java, Python, C#, Go, PHP, NodeJS, Erlang entre outros, apresentamos o Prometheus.io criado pela equipe do SoundCloud. O case é a implementação de nova equipe Site Reliability Engineering na estrutura de Operações de TI da B2W.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

TDC 2017 - Borg até o Prometheus: Site Reliability Engineering

  1. 1. Quem somos ? Paulo Castro Físico pela USP e desenvolvedor de software, arquiteto e agora coordenador de operações back ti na B2W. http://paulorcf.com - @paulorcf Felipe Signorini, DevOps na B2W, arquiteto padawan e grande entusiasta do desenvolvimento durável. https://github.com/Signorini - @signorini
  2. 2. Introdução - As coisas caem As coisas caem, todos os profissionais de TI conhecem essa verdade, como podemos minimizar esse problema. Monitoramento é o pilar da equipe de operação e infraestrutura, sendo assim, em um mundo de datacenters híbridos precisamos pensar uma maneira nova de entender, monitorar e quantificar os sistemas. INtrodução
  3. 3. Monitoramento para que te quero Sistema de monitoramento servem para agilizar a tomada de decisões quando algo está errado. Não impactar nossos clientes e consequentemente nosso negócio. Introdução
  4. 4. Saindo do código e visualizando o negócio. Normalmente a implementação de um sistema de monitoramento se limita a informações de servidor como memória, cpu, disco e etc, mais podemos ir além com análise de aplicativo até o negócio. Introdução
  5. 5. Borg e SRE Novas culturas, novos meios
  6. 6. Borg e SRE SRE (Site Reliability Engineer) é uma disciplina que incorpora engenharia de software e aplica para operações, como objetivo criar sistemas ultra-escaláveis e que nunca param. Definição Ben Treynor: "what happens when a software engineer is tasked with what used to be called operations." Borg e SRE https://research.google.com/pubs/pub43438.html https://github.com/kubernetes/kubernetes Borg Kubernetes
  7. 7. Borg e SRE Borg e SRE https://research.google.com/pubs/pub43438.html https://github.com/kubernetes/kubernetes Borg Kubernetes
  8. 8. μServices Palavra para reunir tudo isso Microserviços. Pensando em todo esse novo cenário procuramos uma maneira de entender a operação como developers. Prometheus apareceu de uma maneira natural já que foi pensado em como monitorar aplicação publicadas no Kubernetes. Borg e SRE
  9. 9. μServices Palavra para reunir tudo isso Microserviços. Pensando em todo esse novo cenário procuramos uma maneira de entender a operação como developers. Prometheus apareceu de uma maneira natural já que foi pensado em como monitorar aplicação publicadas no Kubernetes. Borg e SRE
  10. 10. Entendendo o problema O desafio de multi-datacenter
  11. 11. Datacenter híbridos Entendendo os problemas Open Stack AWS 1 AWS 2 AWS 3 Bare Metal Bare Metal Direct Connect
  12. 12. Requisição simples? Entendendo os problemas Micro App Micro App DB X DB X Micro App Micro App LoadBalance Scan Oracle AWS OpenStack Bare Metal
  13. 13. E o tamanho? Entendendo os problemas ~ 800 Servidores ~ 9000 CPUs ~ 25k Memory ~ 12 Zones
  14. 14. E o tamanho? Entendendo os problemas Quantos GB de Storage preciso para armazenar todos os dados em um mês ?
  15. 15. Introdução ao Prometheus.io
  16. 16. Tudo começou no Sound Cloud Prometheus Sistema de monitoramento e alerta open source desenvolvido internamente na SoundCloud. Escrito em Go (Golang).
  17. 17. Vantagens e desvantagens Prometheus Vantagens •Sistema multi dimensional de dados. •Totalmente customizável, com funcionalidades poderosas. •Banco TimeSeries otimizado. •Totalmente Open Source com uma boa aprovação pela comunidade. •Suporte a Services discovery. •Modelo Pull. Desvantagens •Não tem nenhuma, mentira… :-) •HA é difícil. •Exportação dos dados históricos não é simples. •Um setup em cada datacenter.
  18. 18. Arquitetura Prometheus •Prometheus Server •Exporters •AlertMananger •Grafana
  19. 19. Arquitetura Prometheus •Prometheus Server •Exporters •AlertMananger •Grafana
  20. 20. Arquitetura Prometheus •Prometheus Server •Exporters •AlertMananger •Grafana
  21. 21. Arquitetura Prometheus •Prometheus Server •Exporters •AlertMananger •Grafana
  22. 22. Arquitetura Prometheus •Prometheus Server •AlertMananger •Grafana •Exporters
  23. 23. Pull, sim senhor Prometheus A grande maioria dos sistemas de monitoramento tem a arquitetura baseada no modelo push. Os servidores enviam informações para servidor de monitoramento. Modelo Pull o servidor expõe um endpoint e o Prometheus consome. Todo o trabalho fica a cargo do Prometheus deixando os servidores fazerem seus trabalhos, que é atender os clientes!
  24. 24. ServiceDiscovery Prometheus
  25. 25. Federação Prometheus Prometheus Server Prometheus Server Prometheus Server Exporter Exporter Exporter Exporter Exporter Exporter Prometheus Server
  26. 26. Subindo o Prometheus Prometheus docker run -p 9090:9090 -v /prometheus-data prom/prometheus -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml -config.file=/prometheus-data/prometheus.yml
  27. 27. Prometheus prometheus.yml
  28. 28. Prometheus Tags
  29. 29. Banco de dados TimeSeries
  30. 30. Banco TimeSeries BIT TALKS Banco feitos especialmente para armazenar informações temporais. •InfluxDB •Open TSDB •Graphite •PromQL (Este é do prometheus)
  31. 31. Banco TimeSeries Banco timeseries Como funciona um banco TimeSeries ? Imagine que você consegue facilmente no seu laptop correlacionar "data objects" na ordem de 68.000.000.000 (68*10^9), o que equivale a coletar por 10 segundos 72 métricas com 15 processos em 20 hosts por 1 ano.
  32. 32. Banco TimeSeries Banco timeseries Como funciona um banco TimeSeries ? Imagine que você consegue facilmente no seu laptop correlacionar "data objects" na ordem de 68.000.000.000 (68*10^9), o que equivale a coletar por 10 segundos 72 métricas com 15 processos em 20 hosts por 1 ano.
  33. 33. Banco TimeSeries Banco timeseries Como funciona um banco TimeSeries ? Imagine que você consegue facilmente no seu laptop correlacionar "data objects" na ordem de 68.000.000.000 (68*10^9), o que equivale a coletar por 10 segundos 72 métricas com 15 processos em 20 hosts por 1 ano.
  34. 34. Banco TimeSeries Banco timeseries A mágica é: ● Separar em pequenos "chunks" de mesmo tamanho com "data objects" em séries temporais. ● Comprimir os "chunks" para reduzir o volume da informação. ● Guardar os dados comprimidos e seu atributo em apenas um "record". Após a mágica, ganhamos: ● 32 Gb de disco armazena 68 bilhões de data objects. ● Leitura dos "data objects" em milisegundos. ● A navegação nos atributos é super rápida (lendo os "chunks"). ● Dá para rodar no seu laptop :-) Complicado ?
  35. 35. Banco TimeSeries Banco timeseries Vamos a teoria: ● Definição 1 ○ "Data object" é uma tupla de {timestamp, value} onde "value" pode ser qualquer objeto. ● Definição 2 ○ Uma série temporal T é uma lista arbitrária e cronologicamente ordenada de "data objects" de um tipo de "value". ● Definição 3 ○ Um "chunk" é cronologicamente ordenada como parte de uma série temporal. ● Definição 4 ○ Um banco de dados de séries temporais é específico para armazenar e recuperar informação no tempo de forma eficiente e optimizada.
  36. 36. Métricas customizada com os exporter
  37. 37. Histogram Matriz de dados Requisições por segundo distribuídos Counter Dado incremental. Soma de requisições Gauge Incremental e decremental Consumo de CPU Estilos de métricas Métricas Summary Matriz de dados multidimensional. Consumo por requisição, max, med, min etc.
  38. 38. Tipos de exporter Métricas Dentro da documentação oficial temos mais de 50 tipos de exporter, deste de serviços específicos, redes, tipos de negócio, se olharmos os oferecidos pela comunidade as opções são infinitas, destacamos alguns exporters: •Node: Informações de infra •JMX: Exportar todas as informações JMX •JSON : Exportar métricas vindo de jsons •Cadvisor: Informações detalhadas de containers dockers •BlackBox: Informações sobre a saúde de serviços •Rabbit: Informações detalhadas sobre o Rabbit •MongoDb: Informações detalhadas sobre o MONGODB •ElasticSearch: Informações de saúde ElasticSearch Código Frameworks
  39. 39. Subindo o Node exporter Prometheus go get github.com/prometheus/node_exporter cd ${GOPATH-$HOME/go}/src/github.com/prometheus/node_exporter make ./node_exporter <flags> wget http://node_exporter-0.14.0.darwin-386.tar.gz nohup ./node_exporter &
  40. 40. Instrumentação de código
  41. 41. Construindo suas próprias métricas Instrumentação de código Poderá criar e expor métricas personalizadas com instrumentação no próprio código, atualmente quase todas as linguagens possuem suas bibliotecas. •Python •Java •Node •Go •Elixir •Ruby •Entre outros
  42. 42. Exemplo de instrumentação Java (Linguagem)
  43. 43. Instrumentação de código Counter Gauge
  44. 44. Exemplo de instrumentação Python (Linguagem)
  45. 45. Python from prometheus_client import start_http_server, Metric, REGISTRY import json import requests metric = Metric('svc_requests_duration_seconds', 'Requests time taken in seconds', 'summary') metric.add_sample('svc_requests_duration_seconds_count', value=response['requests_handled'], labels={}) metric.add_sample('svc_requests_duration_seconds_sum', value=response['requests_duration_milliseconds'] / 1000.0, labels={})
  46. 46. Exemplo de instrumentação SpringBoot (Framework)
  47. 47. Instrumentação de código Adicionou a dependência, registrou e acabou.
  48. 48. PushGateway Instrumentação de código Métricas que não podem ser capturadas, muito utilizado para processos em batch, cron jobs entre outros.
  49. 49. Push Gateway em Java import io.prometheus.client.CollectorRegistry; import io.prometheus.client.Gauge; import io.prometheus.client.exporter.PushGateway; void executeBatchJob() throws Exception { CollectorRegistry registry = new CollectorRegistry(); Gauge duration = Gauge.build() .name("my_batch_job_duration_seconds") .help("Duration of my batch job in seconds.") .register(registry); Gauge.Timer durationTimer = duration.startTimer(); try { // Your code here. Gauge lastSuccess = Gauge.build() .name("my_batch_job_last_success_unixtime") .help("Last time my batch job succeeded, in unixtime.") .register(registry); lastSuccess.setToCurrentTime(); } finally { durationTimer.setDuration(); PushGateway pg = new PushGateway("127.0.0.1:9091"); pg.pushAdd(registry, "my_batch_job"); } }
  50. 50. Alertas com AlertManager
  51. 51. Definição por queries Alertas Sistema de alertas delimitados por queries, possibilitando uma completa customização em como os alertas irão funcionar. Integração com E-mail, Hipchat, slack, pageduty e etc.
  52. 52. Alertas ALERT node_down IF up == 0 FOR 1m LABELS {severity="low", title="Cliente node exporter morto"} Alertas
  53. 53. Alertas
  54. 54. Granularidade nos alertas Alertas Com um sistema de tags e um grande poder do AlertManager, podemos delimitar regras e pesos para cada tipo de alertas. •Severidade de cada alerta •Diferentes canais de atendimento e equipes •Históricos de alertas
  55. 55. Alertas
  56. 56. Alertas
  57. 57. Receivers Alertas
  58. 58. WebHook Alertas # Whether or not to notify about resolved alerts. [ send_resolved: <boolean> | default = true ] # The endpoint to send HTTP POST requests to. url: <string>
  59. 59. Visualização com o Grafana
  60. 60. Templates Grafana Grafana possui compatibilidade com Prometheus nativamente, além de possuir uma gama de templates produzido pela comunidade. Todas as métricas são automaticamente disponíveis para Grafana, sendo possível de forma fácil criar um dashboard customizado para cada necessidade. Quer navegar sobre dados históricos de 4 meses atrás, sem problemas. Quer ver em tempo real o quê está acontecendo também dá.
  61. 61. Grafana
  62. 62. Grafana Counter
  63. 63. Grafana Gauge
  64. 64. Grafana Histogram
  65. 65. Grafana Summary
  66. 66. Grafana
  67. 67. Grafana
  68. 68. Grafana
  69. 69. Grafana
  70. 70. Grafana
  71. 71. Mapa pirata
  72. 72. Mapa pirata Exporters
  73. 73. Demo
  74. 74. Futuro próximo
  75. 75. Inteligência com dados! Futuro próximo Com dados temporais que coletamos podemos junto com áreas de negócio descobrir coisas fantásticas, hoje já sabemos: Operações ● Será que sua aplicação precisa de mais ou menos recurso ? ● Diminuição drástico do MTTR (Tempo médio de recuperação do sistema). ● Entendemos arquitetura da sua aplicação e te ajudamos a nunca mais ficar fora do ar. Indicadores de negócio ● Quanto realmente seu app vendeu. ● GMV por app. ● Cliente não percebe problemas, são resolvidos antes. Dashboards são compartilhados para equipe que centraliza as estatísticas de seu app.

×