Ir para o conteúdo
mcpd
sem daemon
Código

Encaminhamento

O mcpd fala OTLP nos dois sentidos. Nada do que chega aqui fica preso.

Um protocolo de saída, não onze exportadores

O mcpd recebe OTLP, e ele consegue emitir OTLP. Essa única propriedade substitui a maior parte do que faz um conjunto de exportadores por fornecedor: Langfuse, Datadog, Honeycomb, Grafana e todo outro destino que valha citar aceitam OTLP sobre HTTP. O encaminhamento é, portanto, uma implementação em vez de onze, e ele não tem como ficar para trás de um lançamento do SDK de um fornecedor.

Isso também significa que adotar o mcpd é reversível. Aponte-o para o que você usava antes, rode os dois por duas semanas, e decida com os dados na sua frente, e não com base em uma migração que você não consegue desfazer.

Como ligar

armazenar local e copiar adiante

mcpd serve --forward-endpoint https://otlp.example.com

O caminho é acrescentado, então informe a URL base e não /v1/traces. Para um destino que precisa de credenciais, acrescente cabeçalhos:

com um cabeçalho de autorização

mcpd serve \ --forward-endpoint https://otlp.example.com \ --forward-header 'Authorization: Bearer $TOKEN'

Os mesmos ajustes existem sob forward no arquivo de configuração, onde batch_size e enabled também estão disponíveis. A opção de linha de comando vence o arquivo, então uma instância pode ser apontada para outro lugar sem editar um ConfigMap compartilhado. 

{
  "forward": {
    "endpoint": "https://otlp.example.com",
    "headers": [["Authorization", "Bearer sk-..."]],
    "batch_size": 256,
    "enabled": true
  }
}
Ingest pipeline

  1. Decode

    OTLP or native, gzip or plain

  2. Sample

    Decided once, at the root

  3. Redact

    Before anything is written

  4. Price

    From the configured price book

  5. Store

    One transaction per batch

Redaction is stage three, not a cleanup job. A value that a rule matches never reaches storage at all.

O armazenamento local acontece primeiro

Um span é gravado no armazenamento do próprio mcpd antes de qualquer coisa ser encaminhada, e o encaminhamento roda depois, na sua própria tarefa. Duas consequências, as duas deliberadas.

Um destino lento nunca soma a latência dele à requisição que produziu o span. O seu agente não fica esperando o coletor de outra pessoa.

Um destino fora do ar nunca vira uma ingestão recusada. O mcpd continua trabalhando e tenta o encaminhamento de novo na sua própria tarefa. A alternativa, em que a indisponibilidade de outra empresa faz a sua telemetria não ser guardada de jeito nenhum, é exatamente a falha que este desenho existe para evitar.

Cada lote tem três tentativas. Um 429, um 5xx ou uma conexão que falhou é tentado de novo depois de 250 ms, e a espera dobra a cada tentativa. Um Retry-After em segundos substitui a espera, até 30 segundos. Qualquer outro 4xx é definitivo na primeira resposta, porque o lote vai continuar malformado para aquele destino. Quando o daemon está parando, ele faz as tentativas restantes na hora. Um lote recusado de vez, ou ainda não entregue depois da última tentativa, é registrado no log, e os spans dele são somados a mcpd_forward_dropped_spans_total, para você ver quanto da cópia está faltando.

Um destino que aceita a conexão e nunca responde também não consegue tomar a memória do daemon. No máximo as cópias de 64 requisições de ingestão esperam pelo destino ao mesmo tempo. Enquanto houver tantas esperando, uma cópia nova é descartada na hora e contada em mcpd_forward_dropped_spans_total, e a gravação local não é afetada.

Não há uma fila de saída durável. Um lote espera na memória enquanto é tentado de novo, e quando a fila de encaminhamento está cheia, um lote novo é descartado e os spans dele são contados na mesma métrica. Uma fila durável é outro produto, e uma fila silenciosa que fica horas atrasada é pior que uma lacuna visível. Se você precisa de entrega garantida, coloque um coletor de verdade entre o mcpd e o destino e deixe que ele faça o trabalho para o qual foi construído.

A ocultação vale para o que sai

O encaminhamento acontece depois do pipeline de entrada, que oculta no lugar antes de qualquer coisa ser gravada. O que o mcpd foi instruído a esconder também não chega ao salto seguinte. Uma regra que protegesse o seu armazenamento e não a sua saída não seria um controle de privacidade.

O que é encaminhado

Spans. Logs, métricas, notas, feedback e notas de aspecto ficam no mcpd, porque os destinos para os quais as pessoas encaminham são backends de tracing e descartariam o resto ou o amassariam dentro de atributos.

Os spans são agrupados por serviço em resourceSpans, o formato que um receptor espera, em vez de um recurso por span, que é válido e obriga todo destino seguinte a reagrupar.

mcpd encaminhando para mcpd

Como as duas pontas falam o mesmo protocolo, um mcpd local pode encaminhar para um compartilhado. As pessoas do time mantêm um armazenamento rápido na própria máquina, com os payloads completos, e a instância do time recebe as mesmas execuções, com a retenção dela e as regras de ocultação dela aplicadas na chegada.

A seguir