Aller au contenu
mcpd
aucun daemon
Source

Transfert

mcpd parle OTLP dans les deux sens. Rien de ce qui arrive ici n’y reste prisonnier.

Un seul protocole en sortie, pas onze exporters

mcpd reçoit de l’OTLP, et il peut en émettre. Cette seule propriété remplace l’essentiel de ce que fait un jeu d’exporters par éditeur : Langfuse, Datadog, Honeycomb, Grafana et toutes les autres destinations qui méritent d’être nommées acceptent l’OTLP sur HTTP. Le transfert est donc une implémentation et non onze, et il ne peut pas prendre du retard sur la sortie du SDK d’un éditeur.

Cela veut aussi dire qu’adopter mcpd est réversible. Pointez-le sur ce que vous utilisiez avant, faites tourner les deux pendant quinze jours, et décidez avec les données sous les yeux plutôt que sur une migration que vous ne pouvez pas défaire.

L’activer

stocker en local et copier plus loin

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

Le chemin est ajouté à la fin : donnez l’URL de base et non /v1/traces. Pour une destination qui exige des identifiants, ajoutez des en-têtes :

avec un en-tête d’autorisation

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

Les mêmes réglages vivent sous forward dans le fichier de configuration, où batch_size et enabled sont aussi disponibles. Une option l’emporte sur le fichier : une instance peut donc être pointée ailleurs sans modifier une ConfigMap partagée. 

{
  "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.

Le stockage local a lieu d’abord

Un span est écrit dans le stockage propre à mcpd avant tout transfert, et le transfert tourne ensuite sur sa propre tâche. Deux conséquences, toutes deux délibérées.

Une destination lente n’ajoute jamais sa latence à la requête qui a produit le span. Votre agent n’attend pas le collecteur de quelqu’un d’autre.

Une destination en panne ne se transforme jamais en ingestion refusée. mcpd continue de fonctionner et réessaie le transfert sur sa propre tâche. L’autre solution, où la panne d’une autre entreprise vous prive de toute télémétrie conservée, est exactement la défaillance que cette conception vise à éviter.

Chaque lot a droit à trois tentatives. Un 429, un 5xx ou une connexion échouée est réessayé après 250 ms, et l’attente double après chaque tentative. Un Retry-After exprimé en secondes remplace l’attente, jusqu’à 30 secondes. Tout autre 4xx est définitif dès la première réponse, parce que le lot restera mal formé pour cette destination. Quand le daemon s’arrête, il fait les tentatives restantes tout de suite. Un lot refusé pour de bon, ou toujours non livré après sa dernière tentative, est journalisé, et ses spans sont ajoutés à mcpd_forward_dropped_spans_total, pour que vous voyiez quelle part de la copie manque.

Une destination qui accepte la connexion et ne répond jamais ne peut pas non plus prendre la mémoire du daemon. Au plus 64 requêtes d’ingestion ont leur copie en attente de la destination à la fois. Tant qu’elles sont aussi nombreuses à attendre, une nouvelle copie est abandonnée aussitôt et comptée dans mcpd_forward_dropped_spans_total, et l’écriture locale n’est pas touchée.

Il n’y a pas de file de sortie durable. Un lot attend en mémoire pendant qu’il est réessayé, et quand la file de transfert est pleine, un nouveau lot est jeté et ses spans sont comptés dans la même métrique. Une file durable est un autre produit, et une file silencieuse qui prend des heures de retard est pire qu’un trou visible. S’il vous faut une livraison garantie, placez un vrai collecteur entre mcpd et la destination et laissez-le faire le travail pour lequel il a été construit.

Le masquage s’applique à ce qui sort

Le transfert a lieu après le pipeline d’ingestion, qui masque sur place avant toute écriture. Ce que mcpd a reçu l’ordre de cacher n’atteint pas non plus le saut suivant. Une règle qui protégerait votre stockage mais pas votre sortie ne serait pas un contrôle de confidentialité.

Ce qui est transféré

Les spans. Les logs, les métriques, les scores, les retours et les notes d’aspect restent dans mcpd, parce que les destinations vers lesquelles on transfère sont des backends de tracing : elles jetteraient le reste, ou le tordraient en attributs.

Les spans sont regroupés par service dans resourceSpans, la forme qu’un récepteur attend, plutôt qu’une ressource par span, qui est valide et oblige chaque système en aval à les regrouper.

mcpd qui transfère vers mcpd

Comme les deux bouts parlent le même protocole, un mcpd local peut transférer vers un mcpd partagé. Les développeurs gardent un stockage rapide sur leur machine, avec les payloads complets, et l’instance de l’équipe reçoit les mêmes exécutions, avec sa propre conservation et ses propres règles de masquage appliquées à l’arrivée.

La suite