Skip to content

feat(deploy): three-axis sweep driver - #193

Merged
zzylol merged 1 commit into
mainfrom
feat/three-axis-sweep-driver
Apr 23, 2026
Merged

zzylol merged 1 commit into
mainfrom
feat/three-axis-sweep-driver

Conversation

@zzylol

@zzylol zzylol commented Apr 23, 2026

Copy link
Copy Markdown
Contributor

(Re-opened from #192 which GitHub auto-closed when its base branch was squash-merged.)

Summary

New run-three-axis-sweep.sh that iterates the (W, L, agg_type) grid from docs/sdk-aggregation-three-axis-design.md. Each paper §6.2 sub-sweep is a thin wrapper fixing two axes and varying the third:

Sub-sweep WINDOWS PROJECTIONS AGGS
6.2a time 1s 15s 60s 300s : dd-full
6.2b label 60s : zone,rack zone - dd-full
6.2c encoding 60s zone,rack raw-buffer dd-full dd-delta kll cms-full hll-full

: = keep all labels (bash-friendly escape for empty string); - = drop all.

How it works

  1. For each cell, docker compose downup with EXPORTER_SDK_WINDOW/PROJECTION/AGG set in env.
  2. Uses baseline-b0a-raw-stream.yml as the agent shape (OTLP → batch(1s) → OTLP) — neutral, keeps the agent from doing sketch work on top.
  3. Soaks for SOAK_S (default 180s), then invokes measure-baseline.py for one CSV row.
  4. Row tag is w${W}-l${PROJ_RAW}-a${AGG}.

Verified locally

$ WINDOWS=5s PROJECTIONS=":" AGGS=raw-buffer SOAK_S=30 \
  CARDINALITY=50 FREQ_HZ=5 BYTES_WIN=3 \
  ./deploy/scripts/run-three-axis-sweep.sh > /tmp/sweep.csv

baseline,scale,rate,cardinality,producer_cpu_cores,...
w5s-l:-araw-buffer,N1,,50,0.025,9.754,322.269,...

Not in this PR

Numeric validation of the aggregator shapes (is raw-buffer really emitting every sample? is gzip compressing everything to ~0?) belongs to the §6.2c sub-sweep PR that uses this driver.

🤖 Generated with Claude Code

New sweep driver that iterates the `(W, L, agg_type)` grid defined
in docs/sdk-aggregation-three-axis-design.md, bringing up the
compose stack once per cell, soaking, calling measure-baseline.py,
and tearing down.

Each of the paper's §6.2 sub-sweeps is a thin wrapper fixing two
axes and varying the third:

  6.2a time:     WINDOWS="1s 15s 60s 300s" PROJECTIONS=":" AGGS="dd-full"
  6.2b label:    WINDOWS="60s"  PROJECTIONS=": zone,rack zone -"
                 AGGS="dd-full"
  6.2c encoding: WINDOWS="60s"  PROJECTIONS="zone,rack"
                 AGGS="raw-buffer dd-full dd-delta kll cms-full hll-full"

Implementation notes:
- PROJECTIONS uses ":" as a bash-friendly escape for "keep all
  labels" (the natural empty-string would be awkward to pass
  through a space-separated list) and "-" for "drop all".
  decode_projection() maps those back to what
  fake-exporter's EXPORTER_SDK_PROJECTION expects.
- Uses baseline-b0a-raw-stream.yml as a neutral agent shape
  (OTLP → batch(1s) → OTLP), which keeps the agent from running
  a sketch pipeline on top and conflating the SDK-side
  measurement. The SDK axis is the one under study.
- Row tag is "w${W}-l${PROJ_RAW}-a${AGG}" so the resulting CSV
  is trivially splittable back into the grid for plotting.

Smoke-tested locally against the PR #189/#190/#191 stack:

  $ WINDOWS=5s PROJECTIONS=":" AGGS=raw-buffer SOAK_S=30 \
    CARDINALITY=50 FREQ_HZ=5 BYTES_WIN=3 \
    ./deploy/scripts/run-three-axis-sweep.sh > /tmp/sweep.csv

  baseline,scale,rate,cardinality,producer_cpu_cores,...
  w5s-l:-araw-buffer,N1,,50,0.025,9.754,322.269,...

Driver brings up/down correctly, producer-side columns populate,
CSV is well-formed. Numeric validation of the aggregator output
(e.g., "does raw-buffer really emit every sample under gzip
compression?") belongs to the §6.2c sub-sweep PR that uses this
driver to collect actual data.

Stacked on feat/measure-baseline-producer-columns (#191) — that
PR adds the producer columns this script relies on.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@zzylol
zzylol merged commit 6f0976d into main Apr 23, 2026
@zzylol
zzylol deleted the feat/three-axis-sweep-driver branch April 23, 2026 17:51
zzylol added a commit that referenced this pull request Apr 23, 2026
…iner (#194)

base.yml was hard-coding EXPORTER_RATE=1000 and ignoring the new
EXPORTER_SDK_* knobs introduced in PR #190. Smoke-testing
run-three-axis-sweep.sh (#193) produced suspiciously-low
producer_bytes_out_per_s values because every cell of the sweep
was silently running the SDK at its defaults (window=15s,
agg=default, projection="") instead of the swept values.

Switches the fake-exporter container's environment block to
`${VAR:-default}` interpolation for every sweep-relevant knob so
the sweep driver's env assignments actually reach the container:

  EXPORTER_FREQ_HZ
  EXPORTER_SDK_WINDOW
  EXPORTER_SDK_PROJECTION
  EXPORTER_SDK_AGG
  EXPORTER_MAX_BUFFER_PER_SERIES

Legacy EXPORTER_RATE is kept but drops to empty by default so the
deprecation warning doesn't fire spuriously.

Before/after on the same cell (W=5s, card=50, freq=5,
agg=raw-buffer, no gzip, 60s soak):

                        before     after
  sdk config logged   default/15s  raw-buffer/5s
  producer_bytes_out    1923 B/s   48546 B/s  (×25)
  gateway_points_per_s   3.18      280.4
  backend_samples_per_s  2.91      247.9

48 KB/s matches the naive estimate (50 card × 5 Hz × 2 instruments
× ~80 B/datapoint ≈ 40 KB/s), confirming AggregationRawBuffer is
emitting the expected per-event stream. Before the fix, the SDK was
running Sum aggregation on the Counter instead — one data point per
attribute set per 15s tick = ~7 pts/s, which matches the low
gateway rate seen.

Also adds `deploy/fake-exporter/sdk_emit_test.go` as a regression
test for the aggregator contract: a ManualReader + AggregationRawBuffer
should emit exactly `cardinality × instruments × samples_each`
data points. This is the counterpart of the unit test in
opentelemetry-go-patch/sdk/metric/internal/aggregate/ but runs at
the MeterProvider+View level, catching wiring mistakes like the one
above.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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