Google Dapper: tracing distribuído

01 · CONTEXTO E REQUISITOS

Por que olhar um pedido por dentro

O relatório técnico apresenta o Dapper como a infraestrutura de tracing de sistemas distribuídos em produção no Google. Entender o comportamento do sistema nesse contexto exige observar atividades relacionadas em muitos programas e máquinas.

O exemplo dos autores é uma busca na web: um front-end pode distribuir a consulta a muitas centenas de servidores de consulta, cada um com sua parte do índice. Quem olha só a latência total pode saber que há um problema, mas não adivinhar qual serviço é o culpado nem por que ele se comporta mal.

Dessa situação saem dois requisitos fundamentais, implantação ubíqua e monitoramento contínuo, e três metas de projeto: baixo custo de desempenho, transparência para o código da aplicação e escalabilidade.

02 · MODELO DE DADOS

Árvore, spans e anotações

O Dapper pensa um trace como uma árvore de RPCs aninhados e o modela com árvores, spans e anotações. Os nós da árvore são os spans, as unidades básicas de trabalho; cada span tem um nome legível, um id e o id do pai, e um span criado sem pai é um span raiz.

Todos os spans de um mesmo trace compartilham um trace id comum, e os ids servem para reconstruir as relações causais entre os spans de um trace distribuído.

1. No exemplo do paper, o pedido do usuário, o iniciador, chega ao front-end A.

2. O front-end envia RPCs aos servidores B e C.

3. B pode responder de imediato, mas C precisa de trabalho dos backends D e E antes de responder a A.

4. Em um trace típico há um span por RPC, e cada camada adicional de infraestrutura soma um nível de profundidade à árvore.

Os autores descrevem duas classes de solução para associar os registros de mensagens a um pedido de origem. A tabela resume o contraste.

No ambiente do Google, como todas as aplicações usam o mesmo modelo de threads, fluxo de controle e RPC, foi possível restringir a instrumentação a poucas bibliotecas comuns e obter um monitoramento efetivamente transparente para quem desenvolve.

03 · INSTRUMENTAÇÃO

Transparência em poucas bibliotecas

O Dapper segue caminhos de controle distribuídos com quase nenhuma intervenção de quem desenvolve, porque depende quase só da instrumentação de algumas bibliotecas comuns. Uma thread que trata um caminho rastreado guarda o contexto de trace no armazenamento local da thread, e callbacks guardam o contexto de quem os criou, de modo que os ids acompanham caminhos assíncronos.

Quase toda a comunicação entre processos passa por um único framework de RPC, e os ids de span e de trace seguem do cliente ao servidor nos RPCs rastreados.

Quem quiser pode enriquecer o trace com anotações com carimbo de tempo, por uma API simples. Cada span tem um limite superior configurável de volume de anotações, e as anotações da aplicação não deslocam a informação estrutural do span nem a de RPC.

04 · COLETA

Do log local ao repositório

A coleta é um pipeline de três estágios. Primeiro, os dados do span são gravados em arquivos de log locais; depois, daemons do Dapper e a infraestrutura de coleta os puxam dos hosts de produção e, por fim, os gravam em um dos repositórios regionais em Bigtable. Um trace ocupa uma linha da tabela, com uma coluna por span.

1. Os processos instrumentados gravam os dados de span em arquivos de log locais.

2. Os daemons do Dapper puxam esses dados dos hosts de produção.

3. A infraestrutura de coleta grava os dados em um dos repositórios regionais em Bigtable.

4. Ferramentas de análise leem os traces pela Depot API, que dá acesso direto aos repositórios regionais.

5. No modo de dados em tempo real, a interface fala direto com os daemons de cada máquina e os dados ficam disponíveis em segundos.

A latência mediana para os dados irem dos binários instrumentados ao repositório central é menor que 15 segundos.

A coleta é feita fora da banda, separada da árvore de requisições. Os autores dão dois motivos: enviar os dados de trace de volta nos cabeçalhos de resposta dos RPCs pode afetar a dinâmica de rede da aplicação, e esquemas dentro da banda assumem que todos os RPCs são perfeitamente aninhados.

A maior parte do uso ocorre na interface web interativa. Quem consome os traces de forma programática usa a Depot API, que oferece acesso por trace id, acesso em lote com MapReduce e acesso indexado. O índice acabou composto por nome do serviço, máquina e carimbo de tempo, nessa ordem.

05 · AMOSTRAGEM

Quanto rastrear sem atrapalhar

Os autores consideram a amostragem necessária para manter baixo o custo. Segundo eles, uma amostra de apenas uma em milhares de requisições dá informação suficiente para muitos usos comuns do dado de tracing.

No cluster de busca usado como exemplo, a amostragem de traces era necessária para evitar degradação perceptível da latência. As penalidades de latência e de vazão com frequências menores que 1/16 ficaram dentro do erro experimental, e ainda havia dado adequado para serviços de alto volume com taxa tão baixa quanto 1/1024.

O daemon de coleta, em um teste de carga descrito como irrealisticamente pesado, nunca usa mais de 0,3% de um núcleo de uma máquina de produção.

1. A primeira amostragem acontece nos processos instrumentados, para limitar o custo dentro das aplicações.

2. Na coleta há uma segunda amostragem: o hash do trace id decide se a coleta mantém ou descarta o trace inteiro.

3. Um único parâmetro de configuração ajusta a taxa global de escrita no repositório.

A segunda amostragem existe porque a equipe também precisa controlar o volume total gravado nos repositórios centrais, e porque não é viável ajustar rapidamente a configuração de amostragem em todos os binários implantados.

Em serviços de alto volume, um padrão de execução notável que aparece uma vez aparecerá milhares de vezes. Serviços de volume menor podem rastrear toda requisição, e isso motivou a amostragem adaptativa, que também registra junto ao trace a probabilidade de amostragem usada.

06 · LIÇÕES E LIMITES

O que o Dapper virou

O Dapper começou como uma ferramenta de tracing autocontida e evoluiu para uma plataforma de monitoramento, que viabilizou ferramentas não previstas por seus projetistas. Ele não pretende substituir as outras ferramentas: os dados do sistema todo costumam focar a investigação para que outras ferramentas sejam aplicadas localmente.

O tracing ficou desligado por padrão no início, até haver confiança na estabilidade e no baixo custo. As mudanças em que donos de serviço o desligaram foram revertidas após medir o overhead real, que foi imaterial.

Os autores notam ainda que a transparência é mais fácil de obter porque o ambiente de implantação tem certo grau de homogeneidade.