Skip to content

feat: per-processor encoding config — MSGPACK wire format option (3/4) - #162

Merged
zzylol merged 1 commit into
mainfrom
feat/processor-msgpack-encoding
Apr 15, 2026
Merged

zzylol merged 1 commit into
mainfrom
feat/processor-msgpack-encoding

Conversation

@zzylol

@zzylol zzylol commented Apr 15, 2026

Copy link
Copy Markdown
Contributor

Adds an encoding: msgpack config option to countminsketchprocessor, countsketchprocessor, and hllprocessor so operators can opt into the cross-language MessagePack wire format as an alternative to the default sketchlib proto path.

This makes real MessagePack traffic flow on the modified-OTLP data plane — ASAPQuery-backend already accepts it (#9, pmetric constants in #157), sketchlib-go already emits it (#51), but no processor selected it until now.

Scope: 3 of 4 sketch processors

Processor Call site Encoding tag
countminsketchprocessor ws.cms.SerializeMsgpack() CountMinSketchEncodingMsgpack
countsketchprocessor ws.cs.SerializeMsgpack() CountSketchEncodingMsgpack
hllprocessor series.sketch.SerializeMsgpack() via new serializeHLLSketch(sketch, enc) helper HLLSketchEncodingMsgpack

ddsketchprocessor is intentionally deferred — it uses github.com/DataDog/sketches-go, not sketchlib-go, so it can't call SerializeMsgpack directly. Enabling MSGPACK there requires a conversion shim that walks the DataDog sketch's buckets, builds a sketchlib-go DDSketchState proto (the shape sketchlib-go #52 introduced via NewFromStateProtoBytes), and calls SerializeMsgpack on the reconstructed sketchlib-go sketch. Tracked as a separate follow-up because (a) the conversion is ~100 lines, (b) DataDog's proto doesn't carry Sum/Min/Max so msgpack emission is lossy from that source, and (c) the long-term fix is a full ddsketchprocessor migration to sketchlib-go internally.

Delta transmission stays proto-only

All three processors keep delta transmission on the proto path when delta_transmission: true. Sketchlib-go has SerializeMsgpack for full state but no matching delta wire format. encoding: msgpack + delta_transmission: true emits proto deltas for sparse windows and never falls back to msgpack-full for those. Tracked upstream until sketchlib-go grows an apply_delta parallel.

Config shape

Each processor's Config gains:

encoding: msgpack   # \"proto\" (default) or \"msgpack\"

New SketchEncoding string type + EncodingProto / EncodingMsgpack constants per processor. Validate() rejects unknown values with a clear error rather than silently falling back.

Validation

Same pre-existing go.opentelemetry.io/collector/processor/selfmonitor module-resolution issue as the earlier typed-DP refactor PRs (#158/#159/#160/#161) blocks local go build.

  • gofmt -l: clean on all 6 modified files
  • ✅ All API methods available:
    • sketchlib-go CountMinSketch.SerializeMsgpack (#51)
    • sketchlib-go CountSketch.SerializeMsgpack (#51)
    • sketchlib-go HyperLogLog.SerializeMsgpack (#51)
    • pmetric CountMinSketchEncodingMsgpack (#157)
    • pmetric CountSketchEncodingMsgpack (#157)
    • pmetric HLLSketchEncodingMsgpack (#157)

Follow-ups

  • ddsketchprocessor MSGPACK option via DataDog→sketchlib-go conversion shim (or a full internal migration)
  • Delta msgpack wire format (requires sketchlib-go upstream work)
  • Full ddsketchprocessor migration from DataDog/sketches-go to sketchlib-go — bigger refactor

Stack

  • sketchlib-go #51 (merged) — SerializeMsgpack on each sketch type
  • sketchlib-go #52NewFromStateProtoBytes (used by the DDSketch follow-up)
  • #157 (merged) — pmetric MSGPACK enum constants
  • #158/#159/#160/#161 (merged) — typed data point emission refactors (prerequisite)
  • This PR — per-processor encoding config option

🤖 Generated with Claude Code

Adds an `encoding: msgpack` config option to countminsketchprocessor,
countsketchprocessor, and hllprocessor so operators can opt into the
cross-language MessagePack wire format as an alternative to the
default sketchlib proto path. This makes real MessagePack traffic
flow on the modified-OTLP data plane — ASAPQuery-backend already
accepts it (PRs #9, pmetric constants in #157), sketchlib-go already
emits it (PR #51), but no processor selected it until now.

## Scope

Three of four sketch processors are wired in this PR:

  * `countminsketchprocessor` — calls `ws.cms.SerializeMsgpack()` when
    `encoding: msgpack`, tags the data point with
    `CountMinSketchEncodingMsgpack`.
  * `countsketchprocessor`    — calls `ws.cs.SerializeMsgpack()`,
    tags with `CountSketchEncodingMsgpack`.
  * `hllprocessor`            — calls `series.sketch.SerializeMsgpack()`
    via a new `serializeHLLSketch(sketch, enc)` helper that returns
    `(payload, encodingTag, err)`, tags with
    `HLLSketchEncodingMsgpack`.

`ddsketchprocessor` is intentionally **deferred** — it uses
`github.com/DataDog/sketches-go`, not sketchlib-go, so it can't call
`SerializeMsgpack` directly. Enabling MSGPACK for ddsketchprocessor
requires a conversion shim that walks the DataDog sketch's buckets,
builds a sketchlib-go `DDSketchState` proto (the same shape sketchlib-go
[PR #52](ProjectASAP/sketchlib-go#52) introduced via
`NewFromStateProtoBytes`), and calls `SerializeMsgpack` on the
reconstructed sketchlib-go sketch. Tracked as a separate follow-up
because (a) the conversion code is ~100 lines of bucket flattening,
(b) DataDog's proto doesn't carry Sum/Min/Max so msgpack emission
from that source is lossy, and (c) the long-term fix is a full
ddsketchprocessor migration to sketchlib-go internally, which is a
much bigger refactor.

## Delta transmission stays proto-only

All three processors keep delta transmission on the proto path when
`delta_transmission: true` is set. Sketchlib-go has
`SerializeMsgpack` for full sketch state but no matching delta wire
format — tracked upstream until sketchlib-go grows an `apply_delta`
API parallel to its proto one. The net effect: `encoding: msgpack` +
`delta_transmission: true` emits proto deltas for sparse windows and
never falls back to msgpack-full for those.

## Config shape

Each processor's `Config` gains:

```yaml
encoding: msgpack   # "proto" (default) or "msgpack"
```

New `SketchEncoding` string type + `EncodingProto` / `EncodingMsgpack`
constants per processor. `Validate()` rejects unknown values with a
clear error rather than silently falling back.

## Validation

Same pre-existing `go.opentelemetry.io/collector/processor/selfmonitor`
module-resolution issue as the earlier typed-DP refactor PRs blocks
local `go build`. gofmt is clean on all 6 modified files. All API
methods used (`SerializeMsgpack` on each sketch type,
`*SketchEncodingMsgpack` on the pmetric patch) are already available:

  * sketchlib-go `CountMinSketch.SerializeMsgpack` — PR #51
  * sketchlib-go `CountSketch.SerializeMsgpack`    — PR #51
  * sketchlib-go `HyperLogLog.SerializeMsgpack`    — PR #51
  * pmetric `CountMinSketchEncodingMsgpack`        — PR #157
  * pmetric `CountSketchEncodingMsgpack`           — PR #157
  * pmetric `HLLSketchEncodingMsgpack`             — PR #157

## Follow-ups

  * `ddsketchprocessor` MSGPACK option via a DataDog→sketchlib-go
    conversion shim (or a full internal migration). Tracked.
  * Delta msgpack wire format (requires sketchlib-go upstream work).
  * Full ddsketchprocessor migration from DataDog/sketches-go to
    sketchlib-go DDSketch — bigger refactor, not in this PR's scope.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@zzylol
zzylol merged commit 8191111 into main Apr 15, 2026
@zzylol
zzylol deleted the feat/processor-msgpack-encoding branch April 15, 2026 22:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant