Reenvío
mcpd habla OTLP en los dos sentidos. Nada de lo que llega se queda atascado aquí.
Un protocolo de salida, no once exportadores
mcpd recibe OTLP, y puede emitir OTLP. Esa sola propiedad sustituye casi todo lo que hace un juego de exportadores por proveedor: Langfuse, Datadog, Honeycomb, Grafana y cualquier otro destino que valga la pena nombrar aceptan OTLP sobre HTTP. El reenvío es por tanto una implementación en lugar de once, y no puede quedarse atrás respecto a la versión del SDK de un proveedor.
También significa que adoptar mcpd es reversible. Apúntalo a lo que estabas usando antes, ejecuta los dos durante quince días y decide con los datos delante en lugar de con una migración que no puedes deshacer.
Cómo activarlo
almacena en local y copia hacia adelante
mcpd serve --forward-endpoint https://otlp.example.com
La ruta se añade al final, así que da la URL base y no
/v1/traces. Para un destino que necesita credenciales, añade
cabeceras:
con una cabecera de autorización
mcpd serve \
--forward-endpoint https://otlp.example.com \
--forward-header 'Authorization: Bearer $TOKEN'
Los mismos ajustes viven bajo forward en el archivo de
configuración, donde también están disponibles batch_size y
enabled. Un flag gana al archivo, así
que se puede apuntar una instancia a otro sitio sin editar un ConfigMap
compartido.
{
"forward": {
"endpoint": "https://otlp.example.com",
"headers": [["Authorization", "Bearer sk-..."]],
"batch_size": 256,
"enabled": true
}
}-
Decode
OTLP or native, gzip or plain
-
Sample
Decided once, at the root
-
Redact
Before anything is written
-
Price
From the configured price book
-
Store
One transaction per batch
Redaction is stage three, not a cleanup job. A value that a rule matches never reaches storage at all.
El almacenamiento local va primero
Un span se escribe en el almacén propio de mcpd antes de reenviar nada, y el reenvío corre después en su propia tarea. Dos consecuencias, ambas deliberadas.
Un destino lento nunca suma su latencia a la solicitud que produjo el span. Tu agente no espera al colector de otra persona.
Un destino caído nunca se convierte en una ingesta rechazada. mcpd sigue funcionando y reintenta el reenvío en su propia tarea. La alternativa, en la que la caída de otra empresa significa que tu telemetría no se guarda en absoluto, es exactamente el fallo que este diseño existe para evitar.
Cada lote tiene tres intentos. Un 429, un 5xx o una conexión fallida se
reintenta tras 250 ms, y la espera se duplica después de cada intento. Un
Retry-After en segundos sustituye a la espera, hasta 30
segundos. Cualquier otro 4xx es definitivo a la primera respuesta, porque el
lote seguirá siendo inválido para ese destino. Cuando el daemon se está
deteniendo, hace los intentos restantes de inmediato. Un lote rechazado de
forma definitiva, o aún sin entregar tras su último intento, se anota en el
log, y sus spans se suman a mcpd_forward_dropped_spans_total,
para que veas cuánto falta de la copia.
Un destino que acepta la conexión y nunca responde tampoco puede quedarse
con la memoria del daemon. Como mucho, las copias de 64 solicitudes de
ingesta esperan al destino a la vez. Mientras haya tantas esperando, una
copia nueva se descarta en el acto y se cuenta en
mcpd_forward_dropped_spans_total, y la escritura local no se ve
afectada.
No hay una cola de salida duradera. Un lote espera en memoria mientras se reintenta, y cuando la cola de reenvío está llena, un lote nuevo se descarta y sus spans se cuentan en la misma métrica. Una cola duradera es otro producto, y una silenciosa que se retrasa horas es peor que un hueco visible. Si necesitas entrega garantizada, pon un colector de verdad entre mcpd y el destino y déjalo hacer el trabajo para el que fue construido.
La ocultación se aplica a lo que sale
El reenvío ocurre después del pipeline de entrada, que oculta en el sitio antes de escribir nada. Lo que se le dijo a mcpd que escondiera tampoco llega al siguiente salto. Una regla que protegiera tu almacenamiento pero no tu salida no sería un control de privacidad.
Qué se reenvía
Spans. Los logs, las métricas, las puntuaciones, el feedback y las notas de aspecto se quedan en mcpd, porque los destinos a los que la gente reenvía son backends de trazas y descartarían el resto o lo retorcerían para meterlo en atributos.
Los spans se agrupan por servicio dentro de resourceSpans, que
es la forma que espera un receptor, en lugar de un recurso por span, que es
válido y obliga a todo lo que hay aguas abajo a reagruparlo.
mcpd reenviando a mcpd
Como los dos extremos hablan el mismo protocolo, un mcpd local puede reenviar a uno compartido. Cada persona mantiene un almacén rápido en su propia máquina con los payloads completos, y la instancia del equipo recibe las mismas ejecuciones con su propia retención y sus propias reglas de ocultación aplicadas al llegar.
A continuación
- Apuntar a mcpd una instalación de OpenTelemetry que ya tienes: OpenTelemetry.
- Qué se quita antes de almacenar o enviar un span: Ocultación y retención.
- Cada opción y ajuste de archivo: Configuración.