전달
mcpd는 양쪽 방향으로 OTLP를 말합니다. 도착한 것 중 여기에 갇히는 것은 없습니다.
나가는 프로토콜은 하나, 익스포터 열한 개가 아닙니다
mcpd는 OTLP를 받고, OTLP를 내보낼 수 있습니다. 이 한 가지 성질이 벤더별 익스포터 묶음이 하는 일의 대부분을 대신합니다. Langfuse, Datadog, Honeycomb, Grafana를 비롯해 이름을 댈 만한 목적지는 모두 HTTP 위의 OTLP를 받습니다. 그래서 전달은 열한 가지가 아니라 한 가지 구현이고, 어느 벤더의 SDK 릴리스에 뒤처질 일도 없습니다.
이것은 mcpd를 도입하는 일이 되돌릴 수 있는 일이라는 뜻이기도 합니다. 전에 쓰던 곳으로 전달을 걸어 두고 2주 동안 둘 다 돌린 다음, 되돌릴 수 없는 이전 작업이 아니라 눈앞의 데이터를 보고 결정하십시오.
켜기
로컬에 저장하고 바깥으로도 복사하기
mcpd serve --forward-endpoint https://otlp.example.com
경로는 뒤에 붙으므로 /v1/traces가 아니라 기본 URL을 주십시오.
자격 증명이 필요한 목적지라면 헤더를 추가합니다.
authorization 헤더와 함께
mcpd serve \
--forward-endpoint https://otlp.example.com \
--forward-header 'Authorization: Bearer $TOKEN'
같은 설정이 설정 파일의 forward 아래에도 있으며, 거기에서는
batch_size와 enabled도 쓸 수 있습니다. 플래그가
파일을 이기므로, 공유하는 ConfigMap을 고치지 않고도 인스턴스 하나만 다른 곳을
가리키게 할 수 있습니다.
{
"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.
로컬 저장이 먼저입니다
스팬은 무엇이든 전달되기 전에 mcpd 자신의 저장소에 먼저 기록되고, 전달은 그 뒤에 별도의 태스크에서 실행됩니다. 결과는 두 가지이며, 둘 다 의도한 것입니다.
느린 목적지가 그 스팬을 만들어 낸 요청에 자기 지연 시간을 더하는 일이 결코 없습니다. 에이전트가 남의 컬렉터를 기다리지 않습니다.
죽어 있는 목적지가 수집 거부로 이어지는 일도 결코 없습니다. mcpd는 계속 일하고, 전달은 별도의 태스크에서 재시도됩니다. 다른 회사의 장애가 곧 내 텔레메트리를 아예 남기지 못한다는 뜻이 되는 쪽이야말로, 이 설계가 피하려는 바로 그 실패입니다.
배치마다 세 번 시도합니다. 429, 5xx, 또는 실패한 연결은 250 ms 뒤에 재시도하고,
대기 시간은 시도할 때마다 두 배가 됩니다. 초 단위로 준 Retry-After는
30초를 넘지 않는 한 그 대기 시간을 대신합니다. 그 밖의 4xx는 첫 응답으로
확정됩니다. 그 배치는 그 목적지에서 계속 잘못된 형식일 것이기 때문입니다. 데몬이
멈추는 중이면 남은 시도를 곧바로 합니다. 끝내 거부되었거나 마지막 시도 뒤에도
전달되지 않은 배치는 로그에 남고, 그 스팬은
mcpd_forward_dropped_spans_total에 더해집니다. 그래서 사본이
얼마나 빠졌는지 볼 수 있습니다.
연결을 받아 놓고 끝내 응답하지 않는 목적지도 데몬의 메모리를 차지할 수 없습니다. 목적지를 동시에 기다릴 수 있는 것은 수집 요청
64건의 사본까지입니다. 그만큼 기다리는 동안 새 사본은 즉시 버려지고
mcpd_forward_dropped_spans_total에 집계되며, 로컬 쓰기는 영향을 받지 않습니다.
지속성 있는 발신 큐는 없습니다. 배치는 재시도되는 동안 메모리에서 기다리고, 전달 큐가 가득 차 있으면 새 배치는 버려지며 그 스팬은 같은 메트릭에 셉니다. 지속성 있는 큐는 다른 제품이고, 몇 시간씩 조용히 뒤처지는 큐는 눈에 보이는 빈틈보다 나쁩니다. 전달을 보장해야 한다면 mcpd와 목적지 사이에 진짜 컬렉터를 두고, 그 일을 하도록 만들어진 것에 맡기십시오.
마스킹은 밖으로 나가는 것에도 적용됩니다
전달은 수집 파이프라인 뒤에 일어나고, 그 파이프라인은 무엇이든 기록되기 전에 제자리에서 마스킹합니다. mcpd에 감추라고 일러 둔 것은 다음 구간에도 닿지 않습니다. 저장소는 보호하면서 밖으로 나가는 것은 보호하지 않는 규칙은 개인정보 보호 수단이라고 할 수 없습니다.
전달되는 것
스팬입니다. 로그, 메트릭, 점수, 피드백, 관점 노트는 mcpd에 남습니다. 사람들이 전달하는 목적지는 트레이싱 백엔드이고, 나머지는 버리거나 속성으로 뭉개 놓을 것이기 때문입니다.
스팬은 서비스별로 resourceSpans에 묶입니다. 이것이 수신 측이
기대하는 모양입니다. 스팬마다 리소스를 하나씩 두는 것도 규격에는 맞지만, 그러면
하류의 모든 곳이 다시 묶어야 합니다.
mcpd에서 mcpd로 전달하기
양쪽 끝이 같은 프로토콜을 말하므로, 로컬 mcpd가 공용 mcpd로 전달할 수 있습니다. 개발자는 자기 머신에 페이로드가 온전한 빠른 저장소를 두고, 팀의 인스턴스는 같은 실행을 받아 도착 시점에 자기 보존 기간과 자기 마스킹 규칙을 적용합니다.
다음
- 기존 OpenTelemetry 구성을 mcpd로 향하게 하기: OpenTelemetry.
- 스팬이 저장되거나 보내지기 전에 지워지는 것: 마스킹과 보존 기간.
- 모든 플래그와 파일 설정: 설정.