Skip to content

feat(otap): native sketch protocol with runnable create-merge-estimate demo - #10

Closed
zzylol wants to merge 10 commits into
mainfrom
feat/otap-sketch-create-merge-estimate-demo
Closed

feat(otap): native sketch protocol with runnable create-merge-estimate demo#10
zzylol wants to merge 10 commits into
mainfrom
feat/otap-sketch-create-merge-estimate-demo

Conversation

@zzylol

@zzylol zzylol commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Why

Implements the SCHEMA / DICTIONARY / LABELS / RECORD model on native OTAP metrics, with a runnable scalar -> create sketch -> merge sketch -> estimate flow.

Wire format

Sketch records use OTLP Summary semantics. SummaryDpAttrs["sketch.envelope"] carries the canonical self-describing ASAPv1 format from asap_sketchlib.

The codec validates the ASAPv1 magic, version, kind ID, and exact framed lengths. The demo uses KLL because its ASAPv1 format is implemented in asap_sketchlib.

Multi-process demo

cd asap-precompute-rs
cargo run --bin asap-otap-demo --features otap-engine

The two create processors, merge processor, and estimate processor each run in a separate child OS process with their own real OTAP RuntimePipeline. Process boundaries carry standard protobuf ExportMetricsServiceRequest messages and reconstruct native OtapPdata inside each worker.

Each worker routes output through the official urn:otel:processor:debug in detailed metrics mode. Intermediate payload/type views go to per-worker trace files, not stdout. The obsolete private sketch batch/dictionary/wire/lifecycle implementation is deleted.

Verification

  • multi-process demo: four distinct child PIDs, p50 = 100, p99 = 198
  • official debug output identifies sketch records as Summary and shows sketch.envelope
  • cargo test --features otap-engine (144 passed)
  • cargo clippy --features otap-engine --all-targets -- -D warnings
  • cargo fmt --all -- --check
  • git diff --check

zzylol and others added 5 commits August 31, 2026 08:04
Extend the real-RuntimePipeline E2E to three independently configured
`urn:asap:processor:asap_sketches` nodes sharing one stable URN:

- create   (transmit_sketch=true)  scalar gauges -> self-describing DDSketch
- merge    (transmit_sketch=true)  merges the envelope as sketch state,
                                   never re-expanding it to scalar samples
- estimate (transmit_sketch=false, quantiles=[0.5,0.99]) -> scalar p50/p99

Assertions are made at the exporter boundary: p50/p99 relative accuracy,
genuinely-scalar output shape, output metric name, and `route` label
preserved across all three processor hops plus three timer flushes.

Thread the estimate- and wire-control knobs through
`AsapSketchesUserConfig` -> `PluginConfig` (transmit_sketch, quantiles,
encoding, delta_transmission, default_key, omit_resource_attrs,
global_aggregation, emit_window_stats) and account for the
series-identity / factory-affecting ones in `requires_precompute_rebuild`
so a runtime `NodeControlMsg::Config` push rebuilds the Precompute when
it must. Document them in sample.toml and the plugin README.

Add docs/demo-guide.md: a presentation-ready walkthrough of the demo.

Verified: cargo test --features otap-engine (all pass), clippy
--all-targets --features otap-engine -D warnings, cargo fmt --check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTn742jM8FKwqdTDXGSz3p
Replace the plain-text topology sketch in demo-guide.md with a mermaid
flowchart matching df-processor-topology.md's style: the five nodes in
one RuntimePipeline subgraph, each processor labelled with its config,
edges labelled with the payload that crosses them. Drop the now-duplicated
"test nodes vs. real implementations" sentence.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTn742jM8FKwqdTDXGSz3p
@zzylol zzylol changed the title otap: demo sketch create → merge → estimate in one YAML pipeline feat(otap): native sketch protocol with runnable create-merge-estimate demo Aug 31, 2026
@zzylol

zzylol commented Aug 31, 2026

Copy link
Copy Markdown
Contributor Author

Split into the following review stack:

  1. 1/6 feat(otap): add create-merge-estimate pipeline E2E #13 — pipeline configuration and create/merge/estimate E2E
  2. 2/6 feat(otap): map sketches onto native metrics joins #15 — native OTAP metrics joins
  3. 3/6 feat(demo): add runnable two-source sketch pipeline #14 — runnable two-source demo
  4. 4/6 feat(otap): carry sketches as ASAPv1 OTLP summaries #12 — OTLP Summary + self-describing ASAPv1 envelopes
  5. 5/5 refactor(otap): isolate processors and use official debugging #11 — separate OS processes, official debug tracing, and old transport removal

Please review and merge in the order above. Closing this aggregate PR to avoid duplicate merging.

@zzylol

zzylol commented Aug 31, 2026

Copy link
Copy Markdown
Contributor Author

Final review stack (supersedes the earlier 5-layer index):

  1. 1/6 feat(otap): add create-merge-estimate pipeline E2E #13 — pipeline configuration and create/merge/estimate E2E
  2. 2/6 feat(otap): map sketches onto native metrics joins #15 — native OTAP metrics joins
  3. 3/6 feat(demo): add runnable two-source sketch pipeline #14 — runnable two-source demo
  4. 4/6 feat(otap): carry sketches as ASAPv1 OTLP summaries #12 — OTLP Summary + self-describing ASAPv1 envelopes
  5. 5/6 refactor(otap): remove obsolete private sketch transport #16 — remove obsolete private transport/lifecycle
  6. 6/6 refactor(otap): isolate processors and use official debugging #17 — separate OS processes and official OTAP debug output

#11 is closed because its two scopes were separated into #16 and #17. Review/merge in the order above.

@zzylol

zzylol commented Aug 31, 2026

Copy link
Copy Markdown
Contributor Author

Benchmark follow-up: #18 is stacked on top of #17. It adds the internal OTAP-style nightly/compare methodology, semantic-convention-shaped metrics, correctness checks, Criterion throughput, CPU/peak-RSS capture, and profiling guidance. It is intentionally outside the six functional review layers and should receive separate manual review.

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