Vai al contenuto
mcpd
nessun daemon
Codice

Inoltro

mcpd parla OTLP in tutte e due le direzioni. Niente di quello che arriva resta bloccato qui.

Un protocollo in uscita, non undici exporter

mcpd riceve OTLP, e sa emettere OTLP. Quella sola proprietà sostituisce quasi tutto quello che fa un insieme di exporter uno per fornitore: Langfuse, Datadog, Honeycomb, Grafana e ogni altra destinazione che valga la pena nominare accettano OTLP su HTTP. L’inoltro è quindi un’implementazione sola invece di undici, e non può restare indietro rispetto al rilascio dell’SDK di un fornitore.

Vuol dire anche che adottare mcpd è reversibile. Puntalo su quello che usavi prima, tieni in piedi tutti e due per due settimane, e decidi con i dati davanti invece che su una migrazione che non puoi disfare.

Accenderlo

archivia in locale e copia più avanti

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

Il percorso viene aggiunto in coda, quindi dai l’URL di base e non /v1/traces. Per una destinazione che ha bisogno di credenziali, aggiungi degli header:

con un header di autorizzazione

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

Le stesse impostazioni stanno sotto forward nel file di configurazione, dove ci sono anche batch_size ed enabled. Un’opzione batte il file, così una singola istanza si può puntare altrove senza modificare una ConfigMap condivisa. 

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

Lo storage locale viene prima

Uno span viene scritto nello storage di mcpd prima che qualcosa venga inoltrato, e l’inoltro gira dopo, su un task suo. Due conseguenze, tutte e due volute.

Una destinazione lenta non aggiunge mai la sua latenza alla richiesta che ha prodotto lo span. Il tuo agente non aspetta il collector di qualcun altro.

Una destinazione ferma non diventa mai un ingest rifiutato. mcpd continua a lavorare e ritenta l’inoltro su un task suo. L’alternativa, dove il disservizio di un’altra azienda vuol dire che la tua telemetria non viene tenuta affatto, è esattamente il guasto che questo disegno esiste per evitare.

Ogni batch ha tre tentativi. Un 429, un 5xx o una connessione fallita viene ritentato dopo 250 ms, e l’attesa raddoppia dopo ogni tentativo. Un Retry-After espresso in secondi sostituisce l’attesa, fino a 30 secondi. Qualunque altro 4xx è definitivo alla prima risposta, perché il batch resterà malformato per quella destinazione. Quando il daemon si sta fermando, fa subito i tentativi rimasti. Un batch rifiutato in modo definitivo, o ancora non consegnato dopo l’ultimo tentativo, viene segnalato nei log, e i suoi span vengono sommati a mcpd_forward_dropped_spans_total, così vedi quanta parte della copia manca.

Nemmeno una destinazione che accetta la connessione e non risponde mai può prendersi la memoria del daemon. Al massimo le copie di 64 richieste di ingest aspettano la destinazione nello stesso momento. Finché ce ne sono tante in attesa, una copia nuova viene scartata subito e contata in mcpd_forward_dropped_spans_total, e la scrittura locale non ne risente.

Non c’è una coda in uscita durevole. Un batch aspetta in memoria mentre viene ritentato, e quando la coda di inoltro è piena, un batch nuovo viene scartato e i suoi span vengono contati nella stessa metrica. Una coda durevole è un altro prodotto, e una coda silenziosa che resta indietro di ore è peggio di un buco visibile. Se ti serve la consegna garantita, metti un collector vero fra mcpd e la destinazione e lascialo fare il lavoro per cui è stato costruito.

L’oscuramento vale per quello che esce

L’inoltro avviene dopo la pipeline di ingest, che oscura sul posto prima che venga scritto qualunque cosa. Tutto quello che a mcpd è stato detto di nascondere non arriva nemmeno alla tappa successiva. Una regola che proteggesse il tuo storage ma non quello che esce non sarebbe un controllo di riservatezza.

Che cosa viene inoltrato

Gli span. Log, metriche, punteggi, feedback e note di aspetto restano in mcpd, perché le destinazioni verso cui si inoltra sono backend di tracing e scarterebbero il resto o lo storpierebbero dentro degli attributi.

Gli span sono raggruppati per servizio dentro resourceSpans, la forma che un ricevitore si aspetta, invece di una risorsa per span, che è valida e costringe chi sta a valle a raggrupparli di nuovo.

mcpd che inoltra a mcpd

Siccome i due capi parlano lo stesso protocollo, un mcpd locale può inoltrare a uno condiviso. Chi sviluppa tiene sulla sua macchina uno storage veloce con i payload interi, e l’istanza della squadra riceve le stesse esecuzioni, con la sua conservazione e le sue regole di oscuramento applicate all’arrivo.

Avanti