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

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

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

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

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

Borg e SRE
Novas culturas, novos meios

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

Borg e SRE
Borg e SRE
https://research.google.com/pubs/pub43438.html
https://github.com/kubernetes/kubernetes
Borg Kubernetes

μ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

Entendendo o problema
O desafio de multi-datacenter

Datacenter híbridos
Entendendo os problemas
Open
Stack
AWS
1
AWS
2
AWS
3
Bare
Metal
Bare
Metal
Direct Connect

Requisição simples?
Micro
App
Micro
App
DB X DB X
Micro
App
Micro
App
LoadBalance
Scan Oracle
AWS
OpenStack
Bare Metal

E o tamanho?
~ 800 Servidores
~ 9000 CPUs ~ 25k Memory
~ 12 Zones

E o tamanho?
Quantos GB de Storage preciso
para armazenar todos os dados em um mês ?

Tudo começou no Sound Cloud
Prometheus
Sistema de monitoramento e alerta open source desenvolvido internamente na SoundCloud.
Escrito em Go (Golang).

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.

Arquitetura
Prometheus
•Prometheus Server
•Exporters
•AlertMananger
•Grafana

Arquitetura
Prometheus
•Prometheus Server
•AlertMananger
•Grafana
•Exporters

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!

Federação
Prometheus
Prometheus
Server
Prometheus
Server
Prometheus
Server
Exporter Exporter Exporter Exporter Exporter Exporter
Prometheus
Server

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

Banco TimeSeries
BIT TALKS
Banco feitos especialmente para armazenar informações
temporais.
•InfluxDB
•Open TSDB
•Graphite
•PromQL (Este é do prometheus)

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.

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 ?

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.

Métricas
customizada com os exporter

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.

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

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 &

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

Exemplo de instrumentação
Java (Linguagem)

Counter
Gauge

Python (Linguagem)

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={})

SpringBoot (Framework)

Adicionou a dependência, registrou
e acabou.

PushGateway
Métricas que não podem ser capturadas, muito utilizado para
processos em batch, cron jobs entre outros.

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");
}
}

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.

Alertas
ALERT node_down
IF up == 0
FOR 1m
LABELS {severity="low", title="Cliente node exporter morto"}
Alertas

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

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>

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á.

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.

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

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

Mais conteúdo relacionado

Mais procurados

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

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