Observabilidade na Prática

Igor Osch Simões

2022
 Observabilidade na Prática
Bootcamp: Engenheiro de Confiabilidade SRE
Igor Osch Simões
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.

2
Sumário

Capítulo 1. Fundamentos da observabilidade ...........................................................5

Introdução..................................................................................................................... 5

Desafios das arquiteturas de software atuais .............................................................. 7

Os pilares da observabilidade: métricas ..................................................................... 11

Vantagens e desvantagens das métricas .................................................................... 12

Os pilares da observabilidade: logs ............................................................................ 14

Desafios para a coleta de logs .................................................................................... 17

Os pilares da observabilidade: traces ......................................................................... 19

Desafios para a coleta de traces ................................................................................. 23

Capítulo 2. Arquitetura para observabilidade..........................................................26

Visão geral de como planejar a observabilidade ........................................................ 26

Opensource ou Mercado, qual a diferença? .............................................................. 27

Capítulo 3. Codificando e testando ..........................................................................33

Observabilidade vai além da produção ...................................................................... 33

Código orientado a falhas ........................................................................................... 34

Testes e observabilidade ............................................................................................ 35

Testes em produção? .................................................................................................. 38

Capítulo 4. Laboratório Parte 1 ................................................................................41

Capítulo 5. Desafios da observabilidade ..................................................................42

Qual o público da observabilidade ............................................................................. 42

Como prover os dados para cada público?................................................................. 43

3
 Coleta de dados, desafios e estratégias ..................................................................... 45

Introdução a alertas .................................................................................................... 50

Que sinais usar para os alertas ................................................................................... 51

Envio de aletas e notificações ..................................................................................... 53

Capítulo 6. Laboratório Parte 2 ................................................................................57

Capítulo 7. Laboratório Parte 3 ................................................................................58

Capítulo 8. Laboratório Parte 4 ................................................................................59

Referências……… ..............................................................................................................60

4
Capítulo 1. Fundamentos da observabilidade

O objetivo deste capítulo é prover as bases do que é a observabilidade e o papel

que esta prática desempenha na gestão de aplicações modernas. Um dos pontos mais
importantes deste capítulo é que o conceito de sistemas observáveis não é da TI, mas
se encaixa perfeitamente em atender as necessidades de controle e estabilidade de
aplicações modernas.

O software que compõe a infraestrutura de aplicações evoluiu

consideravelmente nos últimos anos, ao mesmo tempo que essa evolução nos
possibilita controles e flexibilidade sem precedentes, as aplicações e os seus
componentes se tornam consideravelmente mais complexas e com diversas “partes
móveis”, que podem impactar no desempenho geral entregue aos nossos usuários.

Introdução

Observabilidade é um conceito que pode ser aplicado a qualquer sistema, seja

ele de TI ou não. Um sistema ser observável significa que sinais são emitidos e permitem
a qualquer momento identificar o estado desse sistema. Dessa forma um sistema
observável garante estabilidade e controle, e até a solução de alguns problemas.

Tomemos como exemplo os nossos carros. Podemos assumir que da massa de

motoristas que temos no Brasil e no mundo a grande maioria não é um expert em
mecânica automotiva. Ainda assim, quando dirigimos os nossos veículos em viagens
curtas ou longas e sob qualquer tipo de condição, conseguimos saber o estado desse
sistema (nosso veículo):

 Há combustível suficiente?
 Sinais de aquecimento ou a temperatura, estão dentro da normalidade?
 Existem aviso de componentes falhando?

5
  Etc.

O sistema “veículo” então pode ser considerado um sistema observável.

Entretanto, mesmo com essas informações, ocasionalmente podemos nos deparar com
um problema de desempenho (alto consumo, funcionamento diferente do esperado,
ruído) ou de indisponibilidade (veículo não liga ou não se move). Nesses casos
invariavelmente envolvemos um especialista, nosso mecânico. O que acontece aqui?

Em carros antigos nosso mecânico teria que abrir o motor ou outras partes para
diagnosticar o que está falhando; em veículos modernos, uma interface computacional
emite sinais sobre a saúde dos componentes, permitindo assim que se entenda qual foi
a falha:

 Bomba de combustível falhou.

 Problemas de injeção.
 Problema de ignição.
 E mais uma infinidade de informações de diagnóstico.

Com isso podemos dizer que veículos modernos são observáveis, enquanto
para veículos mais antigos podem ser considerados não observáveis ou parcialmente
observáveis.

O exemplo acima se observa em diversas indústrias desde a manufatura até a

manutenção de aviões. Os ganhos com um sistema observável são inúmeros, garantindo
melhor resposta na correção de problemas e melhor prevenção de problemas. Sendo
assim, aplicar a observabilidade a sistemas de software é de suma importância.

O ponto mais importante sobre sistemas observáveis é que eles devem ser
construídos para isso. Sendo assim, deixo abaixo a definição de sistema observável de
Sridharan C., no livro Distributed Systems Observability.

6
  Observabilidade significa um sistema construído, testado e mantido
levando em conta que:
o Nenhum sistema complexo está sempre 100% saudável.
o Sistemas distribuídos são fundamentalmente imprevisíveis.
o É impossível prever a variedade de estados que um sistema
pode atingir em caso de falhas.
o Falha deve ser contemplada em todas as fases do design até a
operação.
o Debug simples é a base para a manutenção e evolução de
sistemas robustos.

Sendo assim, fica claro que para se possa atingir a observabilidade, é

importante que o sistema tenha sido construído para esse fim. Tornar um sistema
observável apenas adicionando monitoração ou a coleta de métricas, sem
planejamento, pode ser uma estratégia inicial, mas se não evoluir para garantir
cobertura efetiva, trará resultados bastante limitados. Adicionar times de SRE à gestão
desse sistema tampouco é efetivo, pode até parecer uma estratégia simples para
aumentar a estabilidade, mas um time de SRE sem as ferramentas modernas de uma
aplicação feita para ser observável, é o mesmo que um mecânico moderno tentar ler
sinais do motor de um carro dos anos 80: esse carro não foi feito para isso, portanto a
efetividade do nosso mecânico em resolver os problemas fica bastante limitada, assim
como no caso da nossa equipe de SER.

Desafios das arquiteturas de software atuais

É inegável que as exigências dos negócios evoluíram. Há 10 anos atrás uma

compra on-line era feita através de um navegador, a maioria dos dispositivos móveis
ainda não era inteligente e a existência de aplicativos para celular ainda era limitada. O

7
volume de tráfego e as dependências de uma aplicação eram, portanto, muito mais
simples.

Era comum que conhecêssemos toda a infraestrutura da nossa aplicação, que

os servidores tivessem nomes conhecidos e novos deploys eram pouco frequentes. As
dependências das nossas aplicações eram muito mais simples e bem menos tipos
diferentes de usuários. A ausência de aplicativos móveis fazia com que nossas aplicações
tivessem mais sazonalidade diária (picos de acesso em horário comercial, por exemplo)
e a quantidade de chamadas que precisavam de resposta em tempo real era bastante
menor.

Avançamos para 2022 e temos uma explosão de acessos mobiles, seja por
navegadores móveis ou aplicativos dedicados, uma grande variedade de produtos, de
regras de negócio e condições de acesso às nossas aplicações. Clientes podem acessar
através de diversos canais e parceiros distintos. Garantir uma transação segura e
consistente se torna mais desafiador: nossa aplicação agora tem inúmeros componentes
menores, interconectados entre si de diversas formas diferentes e espalhados por
inúmeras localidades. Deploys são extremamente frequentes, podendo acontecer
diversas vezes num mesmo dia. Garantir estabilidade e desempenho nessas condições
se torna um desafio sem precedentes.

 Arquiteturas legadas:

‒ Arquitetura composta por grandes blocos de código distribuídos em

poucos servidores.

‒ Ciclo de desenvolvimento longo, com deploys pouco frequentes e

manuais.

8
 ‒ Arquitetura aparentemente simples, por depender de menos
componentes, mas com regras e dependências bastante complexas.

‒ Pequenos conjuntos de servidores ou réplicas da aplicação conferiam

pouca resiliência e tornavam difícil escalar a aplicação.

‒ Monólitos eram comuns:

o Aplicações eram compostas de poucas camadas, em geral 3:

apresentação, middleware e base de dados.

o Havia frontend e backend que eram fortemente atrelados, assim

alterações ao frontend normalmente requeriam alteração ao
backend.

o Poucas integrações e APIs.

o Todas essas características conferiam sistemas bastante difíceis

de manter, tornando o ciclo de desenvolvimento (design,
codificação e testes) longo e os deploys pouco frequentes.

 Arquiteturas modernas:

‒ Aplicações são compostas de inúmeros serviços.

‒ Dois serviços diferentes podem estar no mesmo processo, em processos

separados ou até mesmo em infraestruturas completamente separadas.

‒ Regras de negócio são bastante complexas, isso acarreta no surgimento

de uma quantidade enorme de microsserviços.

‒ Um microsserviço pode fazer parte de um ou mais fluxos de negócios

completamente distintos:

9
 o Quando um determinado serviço falha, é difícil prever o impacto
aos usuários.

o Um mesmo serviço em casos extremos pode atender aplicações

diferentes.

Figura 1 – Evolução das arquiteturas de software.

Figura 2 – Observabilidade em arquitetura.

Ferramenta
Monitoração

Plataforma de Observabilidade

A natureza diversa dos nossos serviços e a sua localização em diversos

datacenters ou clouds públicas torna a adoção de uma plataforma única de

10
observabilidade um desafio. Sendo assim, torna-se um desafio a coleta e o
armazenamento consistente das informações dos nossos elementos monitorados.

Os pilares da observabilidade: métricas

A observabilidade em TI está definida por três pilares:

 Métricas.
 Logs.
 Traces.

Cada um desses três pilares tem funções e características bastante diferentes,

e quando usados em conjunto e de forma inteligente, são a garantia de aplicações mais
estáveis e robustas.

Métricas são representações numéricas de uma condição de um sistema ao

longo do tempo. Por serem dados numéricos são simples de gerar e armazenar. O
grande desafio é que em sistemas modernos, a mesma métrica precisa ser catalogada
de diversas formas, por exemplo o tempo de resposta.

Podemos coletar o tempo de resposta ao longo do tempo para:

 Serviços.
 Requests.
 Instância de um processo.
 Etc.

Isso significa que a mesma métrica terá várias dimensões (ou labels) que
permitirão filtragem e melhor análise dos dados. Para isso as métricas precisarão evoluir
de simplesmente um trio composto por nome/valor/unidade, para uma anatomia mais
moderna. Abaixo detalhamento dessa anatomia com base no Prometheus:

11
  Detalhes de uma métrica Prometheus:

‒ Métricas são identificadas pelo seu nome e pelo seus labels.

‒ Os dados armazenados são denominados um sample que seria como

um datapoint.

‒ Cada sample é armazenado com um float64 associado a um timestamp

preciso.

‒ Toda métrica tem um ID próprio único.

‒ Métricas são imutáveis, o que significa que novos labes ou alterações

criam uma nova métrica.

Figura 3 – Anatomia de uma métrica moderna.

Fonte: SRIDHARAN, C. Distributed Systems Observability, O'Reilly Media, 2018.

Vantagens e desvantagens das métricas

Do ponto de vista de armazenamento e coleta métricas são bastantes

vantajosas: são relativamente simples de serem coletadas e, devido ao seu tamanho,
requerem pouco espaço para armazenamento, são altamente comprimíveis e excelente
para operações matemáticas.

Essa última característica é excelente permitindo que dados mais antigos sejam
resumidos estatisticamente para menor consumo de espaço: métricas recentes são

12
armazenadas minuto a minuto, métricas mais antigas têm resolução de 10 minutos
chegando até a resolução, em métricas mais antigas, de forma diária.

Entretanto, nem tudo são flores quando nos referimos à métricas. A maior
limitação e, portanto, uma desvantagem, é que as métricas têm escopo limitado. São
limitadas ao serviço monitorado, sendo assim se precisarmos de mais dimensões temos
dificuldades. Por ex.:

 Aplicação não foi desenvolvida para prover as métricas com essas dimensões.

 Muitas dimensões podem degradar a nossa base de dados.

Boas estratégias de métricas envolvem planejamento e parcimônia nas

dimensões coletadas. Podemos por exemplo ter o seguinte serviço:

 Nome: OrdemPagamento

 Endpoint exposto: /enviar_ordem

 Métodos usados: PUT, POST, GET

Cada método nesse caso tem necessidades específicas para o negócio. Alguns
exemplos de requisições:

 GET /enviar_ordem?id=123141432

 GET /enviar_ordem?id=4232423423

 GET /enviar_ordem?id=12asdaswer2

 GET /enviar_ordem?id=123sdfsde22

 POST /enviar_ordem

13
  PUT /enviar_ordem

Se vamos catalogar os tempos de resposta deste serviço por request, teríamos

que cada ID enviado na URL acima seria uma dimensão. Isso pode gerar uma degradação
no desempenho do nosso repositório de métricas. Algumas estratégias para evitar isso
podem ser tomadas, como por exemplo excluir o ID do nome da métrica, mas temos
que lembrar que esse é um exemplo bastante simplificado, que no geral os sistemas
possuem inúmeros dados para os quais não precisamos de métricas detalhadas.

O exemplo acima foi baseado num case de um banco brasileiro e a monitoração

do PIX, no caso o único request que precisava de detalhamento era o PUT, dessa forma
todos os demais requests eram coletados de forma geral e apenas o PUT era coletado
de forma detalhada. Isso pemitiu uma melhor eficiência na manipulação dos dados pelas
equipes e a não degradação do desempenho do repositório de métricas, nesse caso um
Cassandra.

Os pilares da observabilidade: logs

Para falar de logs é necessário discutir um pouco sobre os fundamentos da

geração e armazenamento de logs, isso significa entender que:

 Os logs são parte integrante da grande maioria das aplicações eles.

 Possuem um custo relativamente baixo de serem gerados e, portanto, são

uma opção bastante interessante para gerar evidência e até rastreabilidade
das aplicações.

 Os logs vão garantir visibilidade em pontos específicos e vão permitir o

entendimento em situações de muita assincronicidade.

14
 Os logs basicamente podem ser gerados em três formatos diferentes, sendo
que cada formato tem suas características específicas. Um log pode ser gerado em texto
puro, esse sendo o tipo mais comum dos logs, composto por um texto e uma data. Um
evento de log pode ter uma forma estruturada, que é um log em formato normalmente
JSON, tendo assim campos que permitem indexar esse evento. Sendo assim, um tipo de
log muito poderoso para indexar permitindo rápidas buscas e análises desses logs. Por
último temos os logs binários, que são logs de eventos gerados como os demais, mas o
seu formato dedica-se a situações específicas, por exemplo, sincronizar uma base de
dados e sua réplica. Logs em estado binário provavelmente não serão usados para uma
aplicação de observabilidade, portanto os logs em texto puro e em formato estruturado
são muito poderosos e garantem um controle e visibilidade no dia a dia para qualquer
sistema observável.

Continuando com as possibilidades que o uso de logs nos trazem para a

observação de sistemas complexos, temos a de ao realizar um debug, um log irá
permitir, ao contrário das métricas, visibilidade a detalhes do que está acontecendo com
a minha aplicação (ou qualquer outro elemento monitorado que gere logs). Uma
métrica nada mais é que uma sequência de dados, é um valor ao longo do tempo. Com
logs temos uma sequência de eventos ao longo do tempo, que nos permitem avaliar o
conteúdo de cada um desses eventos para entender o motivo do comportamento da
aplicação. São uma opção excelente, por exemplo, quando encontramos uma situação
onde uma taxa de falhas aumenta. Identificar evidências de eventos no mesmo
momento da degradação, como lentidões ao conectar a um serviço remoto e esse
serviço remoto não responde ou gera algum tipo de mensagem. Dessa forma é possível
ver o sintoma pela métrica e entender as evidências do problema ponto a ponto durante
o período de degradação.

15
 Outra vantagem é que dependendo da plataforma usada, os logs podem ser
uma fonte de métricas. Isso quer dizer que, além de coletar evidências, determinadas
características de um evento podem ter as ocorrências contadas. Assim esse valor se
torna uma métrica e, sendo assim, a ponte entre os dois pilares.

Continuando com a nossa análise dos logs é importante entender que da

mesma forma que com as métricas eu tenho vantagens e desvantagens, com os logs
também teremos prós e contras. Os pontos vantajosos na utilização de logs são:

 De longe eles são os elementos mais fáceis de serem gerados.

 Todo framework ou linguagem de programação possui métodos específicos

para a geração de logs.

 Para os desenvolvedores é muito simples adicionar uma nova entrada de log.

Os pontos que deixam logs em desvantagem da geração de logs são:

 Apesar da geração fácil, o armazenamento requer cuidado e planejamento:

pode ser gerado muito volume e o espaço necessário para armazenamento
será igualmente muito grande.

 Volume de dados cresce com o volume de execuções.

‒ Verificamos que com métricas há um volume de espaço necessário de

certa forma estável, independentemente do volume de requisições em
logs há um maior volume de acesso a aplicação, acarretando em um
maior volume de log gerado. Isso pode ser um problema tanto para
armazenar como processar esse volume.

16
  O excesso de logs pode gerar uma concorrência por I/O que pode impactar
aplicação.

‒ Em situações onde é necessária mais visibilidade, pode ser feita uma

geração excessiva de log da aplicação e justamente essa instrumentação
excessiva impactar ainda mais o desempenho, que já está degradado.

Desafios para a coleta de logs

Quando falamos em coleta de logs é importante estar claro que sempre

teremos desafios para essa coleta. Abaixo são apresentados um pouco desses desafios
para que tenhamos um melhor entendimento:

 Coleta por amostragem:

‒ Pode ser opção para diminuir o consumo de recursos, já que ao diminuir

o volume de informação gerado diminui-se também o consumo de
recursos para processamento e armazenamento.

‒ Deixar algumas informações ausentes da coleta impactar

negativamente em uma análise.

‒ Outro desafio é como garantir que os dados coletados sejam relevantes

e evitar uma situação bastante comum com logs: são coletados todos os
eventos que têm muita frequência e os eventos que acontecem muito
infrequentemente acabam sendo descartados, sendo assim ao se fazer
uma análise usando volume de dados em determinado período, pode-se
ter a impressão de que esses eventos infrequentes nunca existiram.

‒ Definir quais eventos vão ser coletados ou não pode ser

computacionalmente custoso, corre-se o risco de economizar em

17
 espaço e volume de logs, armazenados e processados, mas degradando
a aplicação/ambiente observado.

 Onde esses logs serão armazenados:

‒ Não podemos simplesmente colocar esses logs num disco.

‒ Colocar os logs em algum repositório pressupõe que seja possível

buscar, indexar e fatiar esses logs, e para isso precisamos de uma
plataforma de logs, abaixo algumas opções:

o Graylog.

o Elastic.

o FluentD.

o Importante salientar aqui que essas soluções sempre precisarão

de espaço para armazenamento e também vão precisar de rede
para transferência dos dados, o consumo desses recursos irá
aumentar de acordo com o volume de uso do sistema
monitorado.

Seguindo com os desafios para a coleta de logs nós temos a parte de

processamento normalização e armazenagem dos logs. Para uma estratégia de logs
consistente é preciso poder buscar e analisar esses logs de forma rápida. Dessa forma é
preciso normalizar esses dados, isto é, é necessária a transformação e indexação desses
dados antes do envio a um repositório central. Uma entrada de log é composta
normalmente por dois itens: texto (com as informações do evento de log) e um
timestamp (momento da ocorrência do evento). Dependendo de como o evento de log
é gerado, em alguns casos, a parte de texto pode ser estruturada, isso quer dizer, os

18
campos relevantes da entrada de log estão separados em campos específicos. Assim,
antes do envio dessa informação para um repositório central esses campos podem ser
facilmente separados para posterior indexação: normalizar os dados. Um exemplo de
ferramenta que faz isso é o FluentD, softwares desse tipo vão processar um evento de
log antes de enviar o repositório central para armazenamento. O armazenamento
desses logs comumente é feito em uma base de dados de eventos, como por exemplo
o Elasticsearch. Nesse tipo de base existem vários índices que permitem a rápida
consulta e análise dos dados, mas que em contrapartida vão requerer bastante espaço
e principalmente redundância, isto é, várias cópias da informação. Sendo assim o
volume de eventos coletados e armazenados impacta o sizing desse ambiente e o seu
custo final de setup e manutenção.

Os pilares da observabilidade: traces

Traces são uma tecnologia, ou tipo de dado, que já estão presentes a bastante
tempo no mercado. Ferramentas de coleta e monitoração de aplicação por traces são
opções bastante consolidadas e permitem que seja analisado o desempenho em nível
de linha de código de uma aplicação em tempo real. Ferramentas desse tipo
historicamente são classificadas de ferramentas APM (Application Performance
Management), por terem foco específico e permitir a análise em tempo real dos “bits e
bites” de uma aplicação em tempo real.

Traces historicamente sempre tiveram formato proprietário, o que dificultava

um padrão aberto de interoperabilidade entre plataformas e que determinadas
aplicações ou frameworks fossem facilmente monitorados. Sendo assim a comunidade
criou o projeto OpenTelemetry, para a padronização entre outras coletas da geração de
traces. Abaixo algumas características importantes dos traces:

 Traces são maneiras de fazer um profiling da aplicação em tempo de

execução produtiva:

19
 ‒ Visibilidade a cada etapa da execução.

‒ Permite a fácil identificação dos diversos serviços envolvidos e o seu

impacto à execução como um todo.

‒ Causam certo overhead, dependendo da estratégia de geração dos

traces, sampling pode ser necessário para diminuir overhead.

‒ Traces permitem acompanhar a execução em processos distintos,

permitindo acompanhar toda execução dentro de toda a infraestrutura.

Diante de tudo que foi exposto acima, temos duas opções básicas de geração
de traces:

 Plataformas de mercado.

‒ Traces normalmente gerados por um agente que roda junto da

aplicação sem necessidade de alteração à aplicação.

‒ Possuem certa inteligência para reconhecer tecnologias comuns de

mercado.

 OpenTelemetry.

‒ Padrão aberto definido pela indústria.

‒ Cada linguagem possui sua API e SDK para a instrumentação das

aplicações.

‒ Normalmente essa instrumentação é feita no código da aplicação.

O grande ponto importante sobre traces é que eles permitem acompanhar a

execução de uma aplicação em diversos processos separados, isto é, cada processo ou

20
serviço que desempenha um papel específico para a conclusão de uma requisição é
coletado e analisado para cada transação. Como isso é possível? A figura abaixo
exemplifica essa situação:

Figura 4 – Visão geral sobre a geração de traces.

O grande diferencial de traces, é que um id único para transação é gerado e

trafegado de um serviço a outro. Dessa forma os agentes de coleta, sejam eles opções
proprietárias ou OpenTelemetry conseguem entender essas interdependências e criar o
trace completo. Dessa forma temos uma visão única de toda a execução, mesmo que
ela tenha ocorrido em processos distintos. Além disso os traces contêm informação
detalhada de toda a execução:

 Classes e métodos executados.

21
  Comunicação com outros serviços.

 Uso de mensageria ou filas.

 Parâmetros relevantes para a execução.

 Stack traces e mensagens de erros e alertas.

O importante a destacar aqui é que um trace tem formato bastante similar a

um log, mas conteúdo mais extenso, devido à riqueza de detalhes relativos a execução
das transações. Sendo assim, a coleta e armazenamento de traces trarão desafios
semelhantes aos discutidos para logs, que abordaremos em mais detalhes a seguir.

Para finalizar este capitulo uma breve discussão sobre a real necessidade de
traces. Este é um argumento que divide bastante os profissionais e ainda hoje existem
empresas que não tem nenhuma estratégia de tracing presente. Outras adotam tracing
limitados a serviços específicos, muito críticos, enquanto a grande maioria dos serviços
são monitorados apenas com logs e métricas. Contribuindo para essa discussão estão as
arquiteturas modernas de microsserviços que são aplicações muito simples e com lógica
bastante reduzida.

O que é possível notar no mercado é que os microsserviços normalmente tem

uma lógica mais complexa e acabam possuindo certa concorrência, outro ponto
importante é que uma única transação de negócio pode passar por inúmeros
microsserviços, neste caso entender em que ponto a transação está parando é de suma
importância. Adiciona-se a isso que invariavelmente em determinado momento haverá
uma comunicação com sistemas legados, que pode sem complexa, nesses casos ter a
visão completa da execução é informação extremamente relevante para o correto
troubleshooting. Sendo assim, uma estratégia consistente de traces auxilia em qualquer

22
tipo de ambiente (microsserviços ou legado) e deve fazer parte de uma iniciativa
consistente de observabilidade.

Desafios para a coleta de traces

Pata entender os desafios para a geração de traces é preciso entender que:

 Traces trazem visibilidade sobre a execução de uma aplicação.

 Dessa forma são gerados pela própria aplicação:

‒ Agentes que rodam junto da aplica, e compartilham os seus recursos

(memória e CPU).

‒ Código adicionado pelo desenvolvedor, especificamente para a geração

de traces.

Sendo assim sempre que se fala em traces é preciso achar o limite entre
visibilidade e overhead. Traces muito complexos e grandes podem ser custosos para a
geração e impactar negativamente a aplicação observada. Importante entender que em
alguns casos o tempo de execução pode ser infinitamente menor que o tempo para a
geração dos traces, nesses casos não deve ser feita instrumentação, sob o risco de
impactar negativamente o desempenho da própria aplicação. Finalmente os traces
precisam ser enviados a um repositório central, e dependendo da estratégia adotada,
tráfego de rede pode ser um problema.

A arquitetura de coleta de traces sempre será composta por uma lógica que
gera os traces e um ponto de coleta desses traces. Em todas as plataformas vão existir
softwares coletores dessa informação. Dependendo da opção escolhida, esses coletores
são obrigatórios ou não. O padrão OpenTelemetry define a figura do collector e este
deve estar o mais próximo possível das fontes de traces, ferramentas proprietárias

23
possuem estratégias diversas nesses casos, com muitas não possuindo coletores ou
estes sendo opcionais. Importante que um coletor além de garantir melhor desempenho
e estabilidade, possa facilitar a configuração de comunicação, evitando uma explosão
de regras de firewall para cada elemento monitorado.

Figura 5 – Arquitetura simples para coleta de traces.

A imagem acima, apesar de simples, deixa claro os pontos importante da

arquitetura. É importante ressaltar aqui que o coletor, apesar de opcional em muitas
arquiteturas, é um elemento bastante recomendado. É comum que as aplicações
monitoradas estejam espalhadas em diversos datacenters sendo assim o envio de traces
invariavelmente passará por firewalls, o coletor irá facilitar o controle e administração
dessas regras.

Outro desafio que temos com traces, e que novamente, são bastante parecidos
com os desafios de logs, é que o volume de traces cresce de acordo com o volume de
execuções das aplicações monitoradas. Sendo assim a plataforma adotada para a
geração de traces deve ser inteligente o suficiente para lidar com altos volumes de
informação e o overhead gerado por esse volume. Em diversas situações o sampling será
necessário. Sampilng é a ação de descartar traces, para manter a estabilidade do
ambiente como um todo, tanto da aplicação observada como da plataforma de
observabilidade. O maior desafio aqui é manter um conjunto de traces relevante mesmo
com o descarte de parte da informação.

24
 Outro fator igualmente importante a considerar é o tempo de existência de um
trace. Traces por sua natureza devem ser efêmeros, não que não haja a necessidade de
armazenamento de traces por longos períodos, mas que a finalidade de um trace é
análise rápida em momentos de crise. Sendo assim, uma estratégia de armazenamento
somente de traces recentes é bastante bem-vinda para economia de recursos, a maioria
das plataformas comerciais de traces armazenarão os traces por cerca de 10 dias, após
esse período esses traces são descartados e apenas as métricas relativas às execuções
são armazenadas, sendo então a base para análise histórica de comportamento e
tendências.

25
Capítulo 2. Arquitetura para observabilidade

Visão geral de como planejar a observabilidade

O objetivo deste item é a discussão sobre a arquitetura para observabilidade. É

importante entender que a observabilidade vai muito além de simplesmente coletar
informações. Deve-se ter em mente que durante a coleta de informações estamos
avaliando sistemas extremamente complexos em que o volume de itens observados e
de dados gerados pode ser gigantesco. Neste caso é preciso coletar, transferir e
armazenar esses dados de forma consistente. De nada adianta os traces ficarem em um
repositório que no momento de uma crise não suporte o volume de acesso e o volume
de traces.

É importante ressaltar aqui que existem diversos desafios para a escolha de

uma arquitetura de observabilidade. É preciso entender que uma plataforma de
observabilidade terá custos de aquisição, e isso quer dizer o setup dessa plataforma.
Devem ser somados a esses gastos os custos de operação e manutenção. Muitas dessas
despesas ficam escondidas e impactam seriamente na adoção e expansão de qualquer
iniciativa de observabilidade. O primeiro ponto a ser levado em consideração aqui é que
a arquitetura necessária pode ser bem complexa: hoje é comum encontramos empresas
trabalhando com mais de um datacenter próprio, às vezes com mais de uma iniciativa
de cloud públicas e privadas. Toda informação coletada tem que trafegar e chegar a um
repositório central custos e limites nesse tráfego pode ser proibitivo. É preciso levar em
contas todos os elementos que estão auxiliando a coleta: como vimos nos itens
anteriores, existem analisadores de logs, streamers de dados e coletores de traces,
todos esses elementos consumindo recursos tanto computacionais quanto recursos de
rede, isso aumenta o custo de operação.

Outro ponto a levar em consideração é o volume de customizações necessárias

para a coleta consistente de dados. Em muitas situações, manter uma plataforma

26
própria, criada, mantida e desenvolvida por desenvolvedores próprios, trará desafios
impensáveis. É preciso entender que a expertise de qualquer empresa é o seu negócio,
sendo assim suas equipes devem estar focadas em manter o negócio e não em operar e
codificar uma plataforma de observabilidade. Esse é um fator que se não considerado
pode tornar o uso e adoção da observabilidade inviável.

Opensource ou Mercado, qual a diferença?

O ponto fundamental para avaliação dos custos de manutenção e operação de

uma plataforma de observabilidade deve levar em consideração que
independentemente da plataforma escolhida, sempre existirão custos envolvidos, não
importa se a plataforma é opensource, de mercado ou, até mesmo, uma mistura dos
dois. Os custos envolvidos podem ser muitos, mas basicamente são:

 O custo do armazenamento e acesso aos dados:

‒ Importante entender que os dados devem ser armazenados e que

estejam disponíveis de forma consistente: não adianta uma plataforma
que seja muito boa em armazenamento dos dados mas que não permite
flexibilidade na visualização e análise desses dados

 Concentradores de tráfego:

‒ Em algum momento as plataformas sendo usadas precisam enviar esses

dados a um ponto central, o uso de concentradores de tráfego vai aliviar
os custos de rede, entretanto a adoção de plataformas opensource
como OpenTelemetry pode requerer quantidade significativa de
coletores e a manutenção de todos eles pode elevar consideravelmente
os custos.

 O tráfego monitorado:

27
 ‒ Grandes volumes de traces sendo gerados, a adoção de uma plataforma
cujo tráfego não sai do seu datacenter (ou da sua cloud), o que pode ser
uma saída interessante para aliviar custos com rede.

 Custo de manutenção da plataforma adotada:

‒ Esse aqui na minha opinião é o principal ponto de atenção: muitas vezes

escolhemos uma plataforma pensando no seu custo de aquisição, mas o
custo de manutenção posterior, pode ser elevado e vai recair sobre as
equipes internas. São operações de atualização de software, correção
de problemas etc., isso tudo demanda tempo e deve ser levado em
consideração quando adotamos uma plataforma. Se escolhemos uma
plataforma cuja manutenção e todo o controle seja feita pelo provedor
escolhido, em muitas situações, colocando todos esses pontos na ponta
do lápis, descobre-se que o custo entre uma plataforma do tipo “faça-
você-mesmo” para uma plataforma de mercado, pode não ser muito
diferente. Assim a decisão sobre qual plataforma adotar deve ser o
conjunto de funcionalidades e não simplesmente custos de aquisição de
operação.

Fica evidente que a decisão sobre custos deverá ser relativa ao custo geral em
lugar de simples custo de aquisição de uma plataforma. É importante entender que
plataformas open source podem ter um custo menor de aquisição, mas toda a
arquitetura e a sua manutenção é gerenciada pela própria equipe que está implantando
a observabilidade. Dessa forma os custos dessa gestão ao longo do tempo podem ser
proibitivos. É importante lembrar que a plataforma vai crescer com a adoção e com esse
crescimento o volume de dados armazenados nessa plataforma cresce e crescem as
necessidades de manutenção e de operação.

28
 Outro fator a considerar é que é preciso trabalhar com integrações: conforme
a adoção da observabilidade aumenta nas empresas, novos processos são adicionados,
por exemplo, alertas que têm que ser enviados para sistemas de service desk, são
integrações com sistemas terceiros (CMDB, por ex.) entre outros. Nesse caso, open
source não significa que é facilmente integrável, significa que existem opções de código
aberto para que você desenvolva essa integração, portanto o custo desse
desenvolvimento deve ser considerado. Um ponto interessante é que a maioria dos
projetos open source hoje tem soluções Enterprise, dessa forma, se a norma de
determinada equipe é pelo uso de sistemas open source, pode-se optar por em lugar de
manter a uma plataforma própria, adotar uma solução Enterprise oferecida por um
desses provedores.

Outro ponto a ser considerado é que existem atualmente opções Enterprise

flexíveis. No passado a grande preocupação era que ao adquirir uma plataforma de
observabilidade ou monitoração, estaríamos presos aos padrões proprietários desse
fornecedor. Hoje com a grande flexibilidade e a grande adoção de tecnologias abertas
por grandes fornecedores Enterprise, é possível a adoção de uma plataforma robusta
sem necessariamente estar preso ou travado apenas ao que essas plataformas
oferecem. Em algumas plataformas existem opções de integração para fontes de dados
diversas do seu próprio agente. Essa flexibilidade pode desempenhar um papel
fundamental na decisão entre a funcionalidade Enterprise e a flexibilidade do mundo
open source. Algumas plataformas inclusive permitem a adoção de traces open source
juntamente com seus padrões proprietários, e isso pode permitir uma observabilidade
mais completa e menos custosa.

Por último é necessário discutir sobre onde ficará essa plataforma de

observabilidade. Hoje a grande maioria das plataformas oferecem opções rodando em
uma nuvem própria gerenciada pelo próprio fornecedor da plataforma, ou que você

29
tenha essa plataforma sendo executada dentro da sua própria infraestrutura. A decisão
de se a plataforma vai ser SaaS ou vai ser própria (OnPremisses) não deve levar em
consideração os custos e sim as necessidades da empresa. Em mercados muito
regulados é mandatório que todos os dados de monitoração/observabilidade estejam
em datacenters próprios sobre a responsabilidade da própria empresa. Nesses casos é
mandatório o uso de uma opção OnPremisses. Contudo, com o amadurecimento das
ofertas SaaS e garantia de segurança dessas plataformas, muitas empresas estão sendo
flexíveis e permitindo a adoção de plataformas SaaS mesmo em mercados
extremamente regulados. Nesses casos a adoção em uma plataforma SaaS pode ter
custo semelhante à manutenção da plataforma OnPremisses, mas tira todo o overhead
das equipes que vão operar e manter a plataforma

Para finalizar, é importante que a escolha de uma plataforma deve ser

cuidadosa. Se estamos optando por uma plataforma de mercado que roda um ambiente
SaaS, é importante que saibamos limitações de licenciamento e subscrição dessas
plataformas. Essas regras podem ser bastante complexas e envolver custos escondidos,
como por exemplo:

 Limitação de usuários.

 Limitação nas quantidades de ingestão de traces, métricas etc.

 Limitação na quantidade de itens monitorados.

 Etc.

Em muitos casos ultrapassar esses limites acarreta em custos adicionais

proibitivos para a adoção da observabilidade.

30
Padronização de coletas e como estender os dados coletados para casos específicos

Quando falamos em observabilidade é importante termos em mente que em

inúmeras vezes iremos nos deparar com sistemas que não são nativamente observáveis.
Nesses casos a variedade de desafios que podemos enfrentar pode ser grande: podemos
ir de um sistema que não é observável, mas que emite os sinais e aí teremos somente
uma questão de integração desses sinais à plataforma de observabilidade escolhida; ou
teremos sistemas que são completas caixas pretas de situação, na qual a integração vai
exigir desenvolvimento. Neste ponto é muito importante que a escolha de uma
plataforma de observabilidade leve em consideração a flexibilidade de ingestão. É
importante que quando precisarmos adicionar métricas, logs ou traces que não são
nativamente ingeridos exista uma maneira flexível que permita essa ingestão com o
mínimo overhead operacional.

Quais são, então, as opções disponíveis para expandir essa monitoração? É

importante ressaltar que hoje existem diversas tecnologias abertas e padrões da
indústria para coleta de métricas, por exemplo. Alguns exemplos desse padrão são
ferramentas como Telegraph, statsD e Prometheus que são fontes de dados com
padrões bem-definidos, que permitem a fácil integração desses dados para qualquer
outro ambiente, muitas vezes sem o desenvolvimento de código. É importante também
ressaltar que existem softwares que permitem a emissão de métricas, por exemplo uma
linha de comando que retorna o status de determinado sistema. Com um isso, um
programa simples ou script interagindo com esse comando pode enviar as métricas
emitidas para a plataforma escolhida. Aqui é importante considerar que a plataforma
exponhas APIs para ingerir esses dados. Dessa forma se a API não existe, ou se é muito
complexa, vai impactar negativamente na capacidade de expansão da observabilidade.

Integrações e expansão da monitoração trazem algumas preocupações, é

importante deixar muito claro que quanto menos código melhor, isto é, se é possível

31
integrar as minhas fontes de dados à minha plataforma de observabilidade sem
necessidade de desenvolvimento de código pelas minhas equipes. A monitoração,
coleta e armazenamento de dados parece ser uma tarefa simples, mas é preciso levar
em consideração a manutenção em longo prazo. Sempre que o sistema monitorado
muda, é necessário realizar uma atualização à integração para garantir que o sistema
continue sendo observável. Se estamos usando essas integrações de forma nativa no
próprio sistema observado, existe uma diminuição no overhead operacional, já que não
é necessário dispensar membros da operação para atualizar a monitoração. Vale
salientar que nem sempre as integrações nativas vão suprir as necessidades de
integração, portanto é importante a adoção de plataformas flexíveis e que exijam o
mínimo de código possível.

Figura 6 – Opções mais comuns de expansão da observabilidade.

32
Capítulo 3. Codificando e testando

Observabilidade vai além da produção

Para explicar os motivos de a observabilidade ir além da produção é preciso

entender um pouco o histórico sobre testes e qualidade na indústria. Historicamente os
testes sempre foram executados como parte do processo de desenvolvimento e
garantia de qualidade de uma aplicação: as aplicações tinham longos períodos de
desenvolvimento seguido por longos períodos de teste, sendo depois enviadas para a
produção. Esse processo era lento e muitas vezes pouco eficaz, pois envolvia muitos
passos manuais, muito planejamento do que pode acontecer em produção (para
definição dos casos de testes) e costumava deixar algum caso de uso não contemplado.
Dessa forma chegamos a um desafio atual: como podemos garantir um bom
desenvolvimento e testes efetivos sem que tenhamos surpresas em nossos ambientes
produtivos e com a agilidade que o mercado atual exige?

É importante deixar claro que o processo anterior não era por si só ineficiente,
mas muitas vezes não era usado de forma ótima, as aplicações eram desenvolvidas e
medidas durante o desenvolvimento por um conjunto de indicadores e eram expostas
cargas completamente diferentes quando chegavam à produção. É muito importante
que quando se esteja desenvolvendo uma aplicação, que essa aplicação seja medida em
todos os pontos do seu ciclo de vida pelos mesmos indicadores: não faz sentido analisar
uma aplicação em desenvolvimento simplesmente por tempo de resposta e, quando
essa aplicação está em produção, exigir desempenho frente a concorrência de usuários;
concorrência essa que nunca foi planejada ou medida, durante o seu ciclo de
desenvolvimento. Sendo assim, não há como garantir que essa concorrência será
atendida e principalmente não será possível garantir a estabilidade dessa aplicação
atendendo aos nossos clientes.

33
 A moral da história é que o teste de programas pode ser usado de forma
muito eficaz para mostrar a presença de bugs, mas nunca para mostrar sua ausência.

E. W. Dijkstra

Outro ponto importante de se entender aqui é que qualquer processo de

Quality Assurance bem aplicado vai garantir de forma inegável maior estabilidade da
aplicação. Mas esse processo não vai garantir uma aplicação livre de bugs. Vai garantir
simplesmente que se está verificando todos os pontos conhecidos de uma aplicação
para que esses pontos não tenham desvios ou inconsistências, mas sempre irá existir a
probabilidade de que algum caso de uso não tenha sido contemplado, e é esse caso de
uso, quando executado no ambiente produtivo, que poderá conter bugs e impactar
negativamente a minha aplicação. Sim, existe uma necessidade de Quality Assurance no
desenvolvimento, mas também existe uma necessidade de acompanhamento dessa
aplicação durante o seu ciclo produtivo, visando entender essas inconsistências e o
restabelecimento do comportamento anômalo de forma rápida e consistente.

Código orientado a falhas

Codificação orientada a falhas nada mais é que uma maneira de desenvolver

aplicações entendendo que as falhas vão acontecer e que quando elas acontecerem, é
preciso que a aplicação seja simples e fácil de bugar, não importando o quão complexa
é a lógica de negócio que essa aplicação atende. É basicamente entender que aplicação
precisa prover informações para que se entenda a sua semântica operacional, que se
possa entender as características de dependências operacionais e que o código
desenvolvido é depurável. Se não temos essas três características, sempre que existir
uma inconsistência em produção, o debug e análises se tornam tarefas extremamente
complexas e demoradas.

34
 O ponto importante aqui é entender que as características das dependências
operacionais de uma aplicação podem variar muito de acordo com o seu ambiente. Pode
acontecer, por exemplo, de que na produção de um sistema de cache, tenha TTLs muito
diferentes dos mesmos sistemas de cache em produção, e podem existir também
configurações de concorrência com comportamento completamente diferente nos
ambientes produtivos. Essas mudanças nas dependências podem fazer o
comportamento da aplicação em ambiente de Quality Assurance muito difícil de refletir
o comportamento no ambiente produtivo.

Os pontos expostos acima não significam que uma aplicação moderna não deve
ser testada, sendo simplesmente acompanhada em produção. Significa exatamente o
contrário: uma aplicação deve ter um processo de desenvolvimento, controle de
qualidade e produção cuidadosamente desenhados. Aplicação precisa ser testada,
monitorada e acompanhada sob os mesmos indicadores em todo o ciclo devida da
aplicação, observabilidade em não produção irá garantir o acompanhamento
consistente desses indicadores.

Testes e observabilidade

Como vimos nos itens anteriores, é importante entender os desafios para os

testes: garantir cobertura sempre foi uma tarefa complexa e hoje são muito mais
complexas. Aplicações são compostas de diversos pequenos componentes interagindo
entre si em malha bastante complexa: desenhar casos de uso para cobrir a variedade de
interações é demorado e no final pouco eficiente, já que sempre alguns cenários de uso
ficarão sem cobertura. Testes de carga são ainda mais desafiadores, pois além da
cobertura é necessária uma massa de dados para aplicação desses testes e é aí que
várias condições que impedem testes consistente surgem:

 Em alguns casos não existem dados suficientes para gerar uma carga efetiva.

35
  Capacidade dos meus ambientes não produtivos estão muito distantes da
capacidade de produção.

‒ É muito difícil extrapolar os resultados não produtivos e predizer o

comportamento em ambiente produtivo

 Muitas vezes o comportamento dos usuários em produção é muito distinto,

gerando concorrências e outros casos de uso difíceis de reproduzir em
ambiente não produtivo.

Sendo assim é importante que tenhamos uma visão completa do ciclo de

desenvolvimento de uma aplicação e todos os testes que estão envolvidos em cada
etapa, a partir desse ponto então definir qual é a melhor estratégia Quality Assurance
para a nossa aplicação.

Figura 7 – Testes em cada fase do ciclo de vida da aplicação.

Fonte: SRIDHARAN, C. Distributed Systems Observability, O'Reilly Media, 2018.

36
 A grande vantagem de uma estratégia de observabilidade que contemple não
somente a produção, mas também todos os pontos do ciclo de vida das aplicações, é
permitir um acompanhamento consistente da evolução dessas aplicações em todos os
ambientes: desenvolvimento, homologação e produção. Sabemos que esses ambientes
têm características muito diferentes, mas é possível acompanhar as diversas releases de
uma aplicação, tendo um histórico dos tempos de resposta e outros indicadores em cada
um desses ambientes. Torna-se possível, de forma consistente, acompanhar a evolução
de uma aplicação: não somente dos requisitos e exigências do negócio, mas também da
performance dessa aplicação. Sendo assim conseguimos garantir que determinada
aplicação é desenvolvida sempre com os mesmos objetivos da produção em mente.

Outro ponto importante está ligado à automação dos processos de qualidade

de software: é possível garantir que coletando os dados de observabilidade toda vez que
um código é publicado e testado, podemos avaliar se o código está apto a avançar na
esteira. Neste caso é possível garantir que código só evolua para um estágio mais
avançado, por exemplo, de desenvolvimento para homologação caso tenha atingido os
padrões de qualidade exigidos. Sendo assim observabilidade em ambiente não
produtivo não é simplesmente monitorar equipamentos que não estão associados à
produção é garantir um ciclo de vida consistente e maduro para o desenvolvimento de
software.

37
 Figura 8 – Automação da qualidade com observabilidade.

Testes em produção?

Testar em produção significa entender que testarem homologação, staging,

pré-produção ou qualquer outro ambiente não produtivo não é a garantia de que o
software vai se comportar como deveria em produção. É muito importante que se
entenda que no momento de colocar uma nova aplicação ou uma nova versão de
software em produção, existe uma preocupação de qual será o comportamento desse
software, então é importante que essa nova release seja testada na produção enquanto
a release anterior continua atendendo os clientes. É importante aqui termos a frase do
Djkisrtra em mente: essa frase nos deixa claro que um processo de testes e Quality
Assurance é por si só falho e que isso podendo gerar impactos imprevisíveis na
produção.

Dessa forma é sempre preciso usar um conjunto de SLOs, que vão ser a fonte
de decisão. Esses indicadores irão garantir se estamos com desempenho esperado ou
não das aplicações, garantindo o acompanhamento em ambiente não produtivo. Isso
garante a consistência em relação aos releases anteriores e quando a aplicação sobe
para a produção acompanhar esses SLOs no ambiente, tanto para a versão da aplicação
que já estava rodando e quanto para a nova versão dessas aplicações, que estão tendo

38
um desempenho consistente. A forma com a qual isso é feito varia, sendo possível a
adoção de estratégias cannary, blue green ou qualquer outra estratégia de rodar duas
versões em paralelo em ambiente produtivo. O processo aqui consiste em
gradativamente fazer com que a nova release receba tráfego e à medida que esse
tráfego aumenta, acompanhe os indicadores.

Se em algum momento os SLOs estiverem sendo violados, simplesmente

deixamos a versão original da aplicação em produção e retrocedemos o process de
deploy. Aqui temos evidências de problemas reais com uma quantidade muito pequena
de clientes impactados. Assim, é possível garantir estabilidade e inclusive as evidências
em produção se tornam a fonte para o entendimento da anomalia, alimentando todo o
processo de desenvolvimento e o processo de análise para a correção do
comportamento anômalo verificado.

Importante salientar que existem inúmeras razões para a execução de testes

em produção: muitas vezes eventos concorrentes estão acontecendo ao mesmo tempo
que um novo deploy, adicionando condições não planejadas. Por exemplo, o marketing
pode fazer uma campanha para a venda de um novo produto ou para a divulgação de
um novo canal. Muitas vezes esse tipo de evento de negócio ocorre ao mesmo tempo
que o novo deploy de uma aplicação. Simular esses dois eventos concorrentes não
produtivo é bastante difícil, dessa forma esse tipo de situação e esse tipo de
acompanhamento só pode ser consistentemente entendido e resolvido, claro no caso
de anomalias, com visibilidade consistente, garantida pela observabilidade e testes no
ambiente de produção.

Dessa forma é imperativo que se tenha um processo bem-definido de como as

aplicações são acompanhadas e observadas. A melhor prática definida pela Google é a
criação de SLOs. Estes SLOs irão garantir que estamos acompanhando os indicadores
importantes das aplicações e vão garantir também atendimento dos objetivos impostos

39
a esses indicadores. O SLO vai permitir entender o quão longe ou o quão violado está
esse indicador e inclusive eles serão a base para a tomada de decisão.

Periodicamente teremos releases com alto poder de destruição produtiva, quer

dizer, são releases que trazem mudanças significativas e que existe um risco envolvido
sobre como as mudanças vão impactar a aplicação como um todo. Se estamos numa
situação onde o SLO está violado (todo error budget consumido) é muito importante
que se espere até o próximo período onde o error budget estará renovado, para que se
possa fazer o deploy de forma mais consistente evitando impactos ao negócio. Dessa
forma fica claro que uma estratégia de observabilidade anda muito próxima de uma
estratégia de SER, onde se deve acompanhar de forma consistente os objetivos de
desempenho das aplicações.

40
Capítulo 4. Laboratório Parte 1

Deve ser acompanhado através do repositório do GitHub:

https://github.com/aborigene/otel-demo.

Nessa etapa deve ser acompanhado o arquivo Readme.MD até o fim do passo:

 2 – Setup do FluentBit.

41
Capítulo 5. Desafios da observabilidade

Qual o público da observabilidade

Quando falamos em público-alvo da observabilidade é muito importante

entender que os dados coletados de qualquer estratégia de monitoração são usados
hoje de forma muito diversa de como eram usados no passado. Há 10 anos era comum
que toda a métrica, trace e qualquer outra informação coletada do ambiente era de
finalidade e uso exclusivo das equipes de produção/operação. Hoje seu público pode ser
bastante diverso.

Como vimos nos capítulos, anteriores todo o ciclo de desenvolvimento de uma

aplicação pode se beneficiar da observabilidade. Adicionalmente a isso, podemos
coletar informações sobre a saúde do negócio a partir das aplicações que estão sendo
observadas, sendo assim, as equipes de negócio (equipes que definem e monitoram a
saúde do negócio) podem usar a observabilidade como fonte para os seus dados. Nesse
caso deixo aqui alguns exemplos de uso:

1. Equipes de marketing precisam extrair informações sobre comportamento do

usuário;

2. Equipes de negócio precisam saber em tempo real sobre o resultado de

campanhas;

3. Etc.

Um ponto interessante para exemplificar esse uso bastante diverso é o estudo

de caso de um autorizador de pagamentos. Nesse caso, a aplicação em alguns
momentos gerava um código informando que houve um erro de negócio, no caso, o
código específico era menos [-2] Saldo insuficiente. Adicionou-se a quantidade vezes
essa condição se passava e foi gerado um indicador dentro da plataforma. Com isso, as

42
equipes de negócio podiam acompanhar em tempo real esse tipo de condição. Essa
métrica foi de fundamental importância em durante uma change: uma mudança de
configuração fez com que todas as operações fossem negadas por falta de saldo.
Olhando apenas para os indicadores de saúde performance e rendimento da aplicação
não havia nenhum problema: a aplicação estava funcionando sem erros, com tempo de
resposta bastante satisfatório e se comunicando com todas as suas fontes de dados
corretamente. A configuração incorreta estava causando um comportamento anômalo.
A métrica de negócio permitiu medir o impacto ao negócio e entender que sim, havia
um problema apesar de os indicadores de saúde da aplicação indicarem o contrário.

Outro estudo de caso bastante interessante é sobre o sistema de recuperação

de crédito. Basicamente, uma empresa possuía a situação em que vários clientes
inadimplentes eram enviados para instituições parceiras de recuperação de crédito.
Estas instituições usavam os sistemas da empresa (através de APIs) e dessa forma era
possível acompanhar qual a instituição parceira estava recuperando mais crédito. Essa
informação do negócio era de suma importância, pois a regra interna era de envio das
carteiras com mais chance de recuperação para as empresas que mais transacionam e
recuperam crédito. Dessa forma foi capaz coletar essa métrica, classificada por
instituição parceira, sendo assim possível visualizar o volume de negócios fechados por
cada empresa em tempo real. A partir daí criou-se uma lista ordenada, realizando
diariamente o redirecionamento das melhores carteiras às equipes com melhor
desempenho. Esse é um exemplo bastante claro de como uma métrica coletada
diretamente da aplicação, isto é, observável, impacta diretamente uma decisão de
negócio.

Como prover os dados para cada público?

Com expansão nesses casos de uso e nesses públicos que vão consumir a
observabilidade é preciso definir corretamente como os dados serão gerados. Dados de

43
infraestrutura e performance são geralmente mais simples e fáceis de serem coletados,
enquanto dados de negócio vão requerer entendimento do negócio e apoio das equipes
que estão buscando consumir essa informação. A principal preocupação com dados de
negócios para a observabilidade é ter em mente que esses dados podem ser complexos
e sensíveis. Dessa forma, o acesso a eles deve ser direcionado a um público restrito, sob
o risco de expor dados desnecessários ou coletar informação inconsistente.

Falando um pouco mais sobre o que discutimos no parágrafo anterior,

precisamos primeiro discutir sobre dados complexos: dados de negócio podem ser bem
complexos e requerem entender que sem certas alterações ao código da aplicação será
difícil definir uma métrica apenas com instrumentação. É possível instrumentar a
plataforma de coleta e tentar trazer uma métrica de negócio, mas, muitas vezes, a regra
de negócio pode ser tão complexa, tão assíncrona que sem uma alteração de código que
forneça a métrica de forma consistente, talvez não seja possível observá-la de negócio.

Outro ponto importante sobre métricas e dados sensíveis é que muitas vezes
coletar métricas de negócio pode expor a saúde do negócio e, portanto, devem estar
restritas a grupos específicos. O acesso a esse tipo de informação, por exemplo, a saúde
de vendas de uma de uma empresa que tem ações negociadas na bolsa de valores,
quando mau utilizados pode ser destrutivo ao negócio. Nesses casos essas informações
de negócio devem estar bem restritas na plataforma, garantindo acesso a elas somente
pelo público que realmente vai tomar decisão com base nessas métricas. Dessa forma,
um controle de acesso bastante rigoroso e ao mesmo tempo flexível é importante no
momento da escolha de uma plataforma de observabilidade.

Com relação à coleta de dados e a sua privacidade, é importante entender que

alguns dados não expõem e não acarreta nenhum risco para as organizações, é o caso
de performance. Já outros dados, como métricas de negócio e logs, têm informações
muito sensíveis e que podem impactar negativamente no caso de um vazamento.

44
Quando abordamos a possibilidade de instrumentar métricas ou qualquer outra
informação de negócio temos que ter a preocupação de que elas podem impactar o
mercado (como acabamos de exemplificar parágrafo anterior), e que também podem
conter evidências de informação sensível. Um exemplo disso são logs: logs são muito
fáceis de serem gerados e, portanto, podemos ter aplicações logando exatamente tudo
o que se passa em arquivos que podem conter de tudo, desde senhas até valores de
transações dos usuários. Dessa forma, controlar o acesso a esse tipo de informação é
crucial para evitar vazamento de dados, fraudes e qualquer exposição dos nossos
clientes. Importante lembrar que se expandirmos o conceito de observabilidade para
monitorar os usuários, quer dizer, monitorar o que se passa nos seus browsers, devemos
estar atentos às regras de privacidade de dados como LGPD, GDPR, entre outras. Nesses
casos uma plataforma que atenda aos requisitos dessas leis é importantíssima para que
se possa ter uma estratégia de observabilidade 100% consistente.

Por último, para encerrar este subcapítulo, vamos abordar um caso de uso de
um banco nacional e a monitoração da sua aplicação PIX. Esse banco tinha uma
necessidade de acompanhar o volume financeiro de PIX sendo feito a partir de cada um
de seus canais. Essa informação financeira deveria ficar restrita apenas às equipes que
coordenam o PIX. Dessa forma, a plataforma que foi adotada permitia a segregação e a
criação de grupos com níveis de acesso diferentes, sendo assim, foi bastante simples a
criação de uma métrica e depois somente as pessoas que faziam parte desse grupo
poderiam acessar esse tipo de métrica. Foi garantido então que toda a monitoração de
performance e saúde da aplicação pudesse vista por todos, mas somente as métricas
relativas ao negócio estavam restritas a uma equipe de negócio.

Coleta de dados, desafios e estratégias

O que é importante quando estamos definindo a coleta de dados adicionais?

Devemos entender que dados que são alheios a performance e requerem um

45
conhecimento bastante profundo e específico da aplicação que está sendo analisada.
Para isso é imprescindível que seja adotada a participação das seguintes equipes:

 Dev;

 Arquiteto;

 PO;

 Etc.

Isso se deve ao motivo de que as regras de negócio podem ser muito

complexas, envolvendo transações assíncronas, além de processos Batch, que conclui
uma transação em um momento completamente diferente do momento da coleta.
Dessa forma, a maior preocupação não está em simplesmente coletar os dados, e sim
garantir que são consistentes e corretos.

Como exemplo desse desafio vamos abordar o caso de uso que discutimos no
subcapítulo anterior, o exemplo da recuperação de crédito. Nesse caso havia uma
inconsistência nos valores coletados. Quando foi feita a configuração inicial, foi discutido
com os desenvolvedores o ponto para a coleta da informação, entretanto, ao ser
apresentado os resultados da configuração, verificou-se uma taxa de recuperação diária
de R$ 10M em crédito, o que significava a recuperação de R$ 300M de crédito por mês.
Valores muito acima do esperado. Em uma nova rodada com os especialistas
envolvendo as equipes necessárias, identificamos que estávamos coletando a
informação em um momento onde os parceiros faziam simulações do crédito a ser
recuperado e, somente em uma etapa mais à frente, enviaram a opção efetivamente
contratada. Dessa forma, foi necessária uma reconfiguração instrumentando e
coletando as métricas do ponto correto para que o dado apresentado fosse consistente
com a realidade.

46
 O segundo estudo de caso, sobre o banco e o processo de monitoração por PIX,
é importante, pois mostra que somente a instrumentação nem sempre é suficiente. Nele
foi feita uma coleta dos valores de PIX por canal, e esta configuração, aparentemente,
estava apresentando valores consistentes. Ao fazer uma análise de como a configuração
havia sido executada, o desenvolvedor informou que:

 PIX é muito assíncrono;

 Uma transferência somente pode ser considerada bem sucedida após o

recebimento de uma mensagem PACS002, assíncrona, que pode ocorrer
diversos minutos depois da transferência;

 Dados do valor somente trafegam no momento da transferência e não na

mensagem de retorno.

Para garantir a correta recuperação desses dados, foi necessário que o

desenvolvedor alterasse a aplicação, principalmente pelo fato de a mensagem PACS002
ser assíncrona. A alteração foi feita, a aplicação agora emitia sinais desses valores, a
coleta foi instrumentalizada e o valor de negócio agora era fiel à realidade.

Armazenamento das informações coletadas, desafios e estratégias

É importante entender que o acesso aos dados se dá de diversas formas

diferentes: pela interface da plataforma escolhida, por APIs e até fisicamente, direto no
servidor. Este último em caso de manutenção ou mau uso. É importante ter isso em
mente quando planejamos uma estratégia de observabilidade que vai envolver
aplicações críticas e dados sensíveis. Garantir que não haja mau uso e o controle em
ambientes com alta carga é fundamental.

47
 Devido à natureza diversa da observabilidade, é importante entender que
teremos diversos repositórios de dados diferentes, cada um com as suas necessidades
específicas, por exemplo:

 Base SQL;

 Base TimeSeries;

 ElasticSearch;

 Arquivos;

 Etc.

Sendo assim, o controle de acesso a esses repositórios deve ser

cuidadosamente planejado, envolvendo como os dados são armazenados (tipos de
criptografia, níveis de acesos etc.) e como serão feitos backups. As regras de segurança
podem impactar de forma bastante significativa o backup, deixando duas opções:

 Backup não executado satisfatoriamente;

 Segurança de acesso aos dados acaba comprometida.

Nesse caso, é bastante importante que essa preocupação sobre os acessos aos
dados seja levada em consideração, principalmente se estamos decidindo manter a
nossa própria plataforma em lugar de contratar um serviço para observabilidade. Muitas
vezes, a redução de custos de manter a plataforma pode esconder essa dificuldade de
proteção aos dados e controle de acesso.

Outro ponto importante é como lidar com dados potencialmente sensíveis,

principalmente aqueles dados que possam identificar pessoalmente um cliente. Como
exemplo disso o CPF. Podemos adotar estratégias de mascaramento, isto é, a interface

48
não irá apresentar o CPF completo. Mas na base de dados o CPF pode estar armazenado
de forma completa. Em caso de violação de acessos, isto é, onde há acesso aos dados
diretamente na base, pode ocorrer o vazamento de informação ou uso dessa
informação de forma fraudulenta. Outro ponto importante é entender que o
comportamento que vemos na interface pode ser diferente do comportamento que
vemos em uma API de integração, por exemplo. É sempre importante planejar a coleta,
armazenamento e disponibilização de dados sensíveis. Como será a manipulação desses
dados e a disponibilização desses usuários?

Adicionalmente às dificuldades de armazenamento, temos a relevância perante

a monitoração: armazenar somente parte do dado coletado, evitando assim a
identificação do usuário real, pode ser muito interessante do ponto de vista de
privacidade, mas pode nos deixar em uma situação em que não se consiga executar o
correto troubleshooting. Importante aqui é entender que, às vezes, mascarando os
dados, ainda assim temos relevância para a monitoração. Exemplo muito comum é o IP:
um IP pode muito bem identificar pessoalmente um cliente, mas se usarmos somente
os 3 primeiros octetos garantimos que temos a informação relevante para saber de onde
vem esse cliente e até se está numa região afetada, sem expô-lo pessoalmente. Essa
estratégia pode ser adotada em diversas outras situações, como coleta parcial do CPF
ou de um CNPJ, garantindo assim que a monitoração esteja completa e consistente e a
privacidade de nossos usuários preservado.

Continuando discutindo sobre essa dificuldade no armazenamento dos dados,

é importante entender o limite entre relevância e privacidade. É muito comum situações
em que, para o correto troubleshoot, é necessário determinar a transação ou situação
específica e que para isso seja necessário o dado completo. Muitas vezes esse dado vai
permitir que um usuário específico consulte informação relevante correlata àquela
transação. Nesses casos, é importante que o dado seja coletado de forma completa. Por

49
ser um dado sensível, deve estar restrito a poucas pessoas. É o caso de um CPF ou um
número de uma conta corrente: consultando essas informações em um outro tipo de
sistema, garantimos que podemos ter informações mais relevantes sobre o que pode
ter impactado aquela transação particular, mas, por outro lado, podemos expor nossos
usuários. Dessa forma, o CPF completo só estaria acessível ao usuário sênior de uma
equipe de desenvolvimento ou operação.

Introdução a alertas

Ponto de atenção principal com relação à envio de alertas é que de nada

adianta uma plataforma de observabilidade se nós não temos maneiras de atuar em
caso de desvio de comportamento. A plataforma de observabilidade deve ser
desenvolvida de tal forma que se possa:

 Coletar os meus dados.

 Analisar os meus dados.

 Atuar em cima de desvios.

A informação deve permitir, por exemplo, identificar desvios de

comportamento, disparar notificações para as equipes responsáveis e, por fim, prover
meios para o correto troubleshoot e diagnóstico. Sem isso, a plataforma de
observabilidade não está completa.

É importante reconhecer que uma boa estratégia de alertas inclui os seguintes

itens:

 Informar as diversas equipes de um problema.

 Permitir o acompanhamento da evolução e resolução: acompanhamento de

um incidente.

50
  Ter níveis de criticidade distintos e públicos distintos.

 Ser a chave para a resolução de problemas de forma automática.

 Estabelecer padrões para lidar com o tamanho e a complexidade das

aplicações atuais.

Além disso, é preciso entender que identificar um desfio nem sempre é simples.
Um desvio pode ir desde uma métrica que simplesmente ultrapassou um determinado
valor, ou até uma composição de diversas métricas que, quando ultrapassarem valores,
vão configurar um desvio de comportamento. Dessa forma é importante que a
plataforma que está sendo escolhida seja flexível o suficiente para identificar desde
alertas simples (o desvio de apenas uma métrica) até alertas mais complexos, onde duas
ou três métricas podem ser consideradas para identificar um desvio.

Isso se deve por inúmeros fatores, desde aplicações que tem sazonalidade, por
exemplo, que são executadas em grande quantidade em determinados momentos do
dia e depois tem uma queda. Enquanto aplicação sofre carga muito excessiva, é normal
que seus tempos de resposta e outros indicadores de saúde fiquem degradados, não
necessariamente configurando um problema. Outro problema importante é que, em
momentos de crise, podemos ter uma chuva de alertas e isso desvia a atenção, além de
ser pouco relevante para o entendimento do que está acontecendo. É importante que
a plataforma escolhida consiga correlacionar vários eventos e emitir somente uma
notificação, garantindo assim maior consistência na análise do desvio.

Que sinais usar para os alertas

Notificações e alertas nada mais são de que a atuação frente ao desvio de

algum sinal. Discutiremos agora quais sinais devemos utilizar para a notificação e o
disparo de alertas para verificar uma anomalia. É necessário entender que não existe

51
uma regra única que vai funcionar em todas as situações, mas é importante que, em
uma estratégia de observabilidade consistente, tenhamos um padrão e construímos
pontos específicos em cima desse padrão. Para entender isso melhor, trago aqui duas
propostas de sinais que podem ser usadas para avaliar desvios de comportamento,
sendo elas:

 RED

‒ Proposta por Tom Wilkie baseado na sua experiência com SRE da

Google.

‒ Significa usar os seguintes sinais:.

o Request rate.

o Error rate.

o Duration of request.

o Com essas informações em conjunto é possível avaliar desvios no

comportamento da aplicação e evitar falsos positivos.

 USE:

‒ Proposta por Brendan Gregg.

‒ Significa usar os seguintes sinais:

o Utilizations.

o Saturation.

o Errors.

52
 ‒ Acaba por ser uma estratégia interessante para infraestrutura, pois
correlaciona mais de uma métrica, por exemplo:

o Consumo de memória (utilization).

o Page faults (errors).

o Fila de acesso a threads (saturação).

Outro ponto importante é entender que as métricas que são coletadas, elas
podem ter relevância e valores diferentes. Basicamente, existem duas maneiras de
coleta de dados. A primeira maneira é a maneira White Boxing, quer dizer, a coleta é
feita de dentro do item monitorado, onde é possível o acesso aos dados mais
consistentes. Outra técnica é a de black boxing: onde eu estou coletando de fora, como
um ping de Nagios, por exemplo. Essas métricas são limitadas à alertas baseados em
métricas de blackboxing, que tendem a ser menos relevantes e prover menos
informações.

Envio de aletas e notificações

Este subcapítulo é particularmente importante, pois vamos abordar a

notificação e envio de alertas. Essa é uma prática muito mais relevante do que apenas
o envio de mensagens para avisar que alguma coisa está fora. Basicamente, uma
estratégia alerta significa envolver as equipes corretas no momento de um desvio, por
exemplo, se temos certeza de que o desvio de uma aplicação é causado por código e
que não há desvios de infraestrutura. Nesse caso nós vamos enviar a notificação às
equipes responsáveis pela aplicação, pois não há necessidade de movimento das
equipes de infraestrutura.

53
 Envolvemos nossas equipes e sua atuação de forma otimizada, garantindo
assim menos desperdício de tempo e de pessoal. Outro ponto é que uma estratégia de
alertas bem-definida, onde temos problemas conhecidos bem-definidos, podemos usar
a notificação para automatizar a correção desses problemas. Outro ponto relevante a
ser considerado em uma estratégia consistente de envio de alerta e notificações é o fato
de que alguns conjuntos de itens podem ter prioridade maior do que outros, por
exemplo, a queda de um servidor em um conjunto de três servidores pode ser muito
relevante, enquanto a queda de um contêiner numa aplicação com 10 ou 20 réplicas
pode ser bem menos relevante. Tudo isso deve ser considerado na hora de notificar as
equipes: garantindo assim que você não está acordando o seu chefe de operação porque
apenas um contêiner está fora na produção.

É importante também levar em consideração as possibilidades de automação

com base em alertas. Podemos ter um conjunto de problemas conhecidos e como esses
problemas são resolvidos podemos ter inclusive ferramentas que automatizam a
correção desses problemas. Dessa forma, quando existe um alerta, este alerta pode
sensibilizar essas ferramentas e prover a correção do problema. O importante a saber
aqui é: não existe maneira de corrigir problemas que não sejam conhecidos. Para que
essa estratégia funcione, é importante que tenhamos uma base de conhecimento com
todos os problemas conhecidos e os seus RunBooks, para que a ferramenta escolhida
para automação possa atuar e fazer o restabelecimento das aplicações impactadas.

É importante também deixar muito claro que as notificações precisam ter a

informação relevante para que a plataforma de automação possa atuar. É preciso ter
uma informação sobre qual foi o processo impactado ou, de repente, até o servidor
impactado, para que essa plataforma consiga entrar em contato com cada um desses
itens e prover a correção dos problemas.

54
 Quando falamos da parte de notificações e alertas import. A notificação é o
ponto de entrada para a resolução de um problema, seja ele de forma automática, ou
de forma manual por uma equipe que vai fazer um efetivo de uma aplicação. É
importante que esse alerta ou essa notificação tenha informações relevantes que
permitam a quem vai analisar. Um processo de troubleshooting tem as seguintes fases:

‒ Análise de métricas de alto nível.

‒ Drill down para mais detalhes e informação mais granular.

‒ Com essas informações fazer deduções e testes.

‒ Fazer quantas iterações forem necessárias.

Importante que a plataforma de observabilidade escolhida permita

acompanhamento e troubleshoot de acordo com as fases exemplificadas acima, a partir
de um alerta ou a partir de uma análise qualquer dentro da própria plataforma. É
importante entender que em algum momento teremos um desvio para o qual não vai
haver alerta, mas ainda assim a nossa plataforma de observabilidade deve permitir um
troubleshoot consistente seguindo os passos acima.

“A ferramenta de depuração mais eficaz ainda é um pensamento cuidadoso,

juntamente com comandos print criteriosamente colocadas num código.”

Brian Kernighan, Unix for beginers, 1979

Por último, é importante a gente entender que, apesar das grandes

possibilidades de instrumentação e coleta de dados, se os sistemas não foram
desenvolvidos para serem observáveis, teremos sempre desafios e pontos cegos. A frase
do Brian Kernighan acima deixa muito claro que podemos ter uma estratégia de
observabilidade consistente. Inclusive que os data points providos pela observabilidade

55
vão ajudar a ter uma aplicação mais robusta, mas se não houver um trabalho para que
todos os seus sistemas sejam observáveis, sempre teremos uma estratégia de
observabilidade incompleta.

56
Capítulo 6. Laboratório Parte 2

Deve ser acompanhado através do repositório do GitHub:

https://github.com/aborigene/otel-demo.

Nessa etapa deve ser acompanhado o arquivo Readme.MD os passos:

 3 – Setup do Prometheus.

 5 – Setup do Grafana.

57
Capítulo 7. Laboratório Parte 3

Deve ser acompanhado através do repositório do GitHub:

https://github.com/aborigene/otel-demo.

Nessa etapa deve ser acompanhado o arquivo Readme.MD os passos:

 4 – Setup do Jaeger.

58
Capítulo 8. Laboratório Parte 4

Deve ser acompanhado através do repositório do GitHub:

https://github.com/aborigene/otel-demo.

Nessa etapa deve ser acompanhado o arquivo Readme.MD os passos:

 6 – Setup da Aplicação.

59
Referências

MURPHY, Niall R.; BEYER, Betsy; JONES, Chris; PETOFF, Jennifer. Site Reliability
Engineering: How Google runs production systems. O'Reilly Media, mar. 2016.

SRIDHARAN, C. Distributed Systems Observability. O'Reilly Media, Inc., jul. 2018

60