Add a first-class metric emit path to the WASM plugin SDK (signal_type 'metric' / payload_kind 'otel_metric') [serviceradar#3788 REC2] #5

New issue

Open

opened 2026-06-13 23:30:25 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-06-13 23:30:25 +00:00

Owner

First-class metric emit path for the WASM plugin SDK

Part of the ServiceRadar unified metric ingestion contract (carverauto/serviceradar#3788, REC2). Today a WASM plugin can only emit metrics by embedding them in a check-result (Result.AddMetric / add_metric_spec → serviceradar.plugin_result.v1), and emit_telemetry supports only ocsf_event and otel_log payload kinds — there is no first-class metric telemetry path.

Evidence: Go sdk/signal_schema.go:15-18 + sdk/telemetry.go (only OCSF/OTEL-log constructors); Rust src/result.rs:354-357 + src/telemetry.rs (only ocsf_event/otel_log).

Ask

Add a metric signal type + otel_metric payload kind.
Add a metric telemetry constructor — Go NewMetricTelemetryRecord(...), Rust TelemetryRecord::otel_metric(...) — routed through the existing emit_telemetry host import.
The metric carries an OTLP-grade point: resource (service identity + attributes), name, kind (gauge/sum/histogram), temporality, is_monotonic, unit (UCUM), and points[] (time_unix_nano, attributes, value or histogram buckets, optional exemplars).
Keep Result.AddMetric / add_metric_spec as perfdata shims that lower to a single gauge point, so existing plugins keep working unchanged.

This is the producer half of the contract evolving serviceradar.metric.v1 to schema_version 2 (resource/kind/temporality/points[]); the gateway/core consumer side is tracked in carverauto/serviceradar#3788 and update-anomaly-evaluation-cadence (#3791). Contract reference: carverauto/serviceradar#3788

## First-class metric emit path for the WASM plugin SDK Part of the ServiceRadar unified metric ingestion contract (carverauto/serviceradar#3788, REC2). Today a WASM plugin can only emit metrics by **embedding them in a check-result** (`Result.AddMetric` / `add_metric_spec` → `serviceradar.plugin_result.v1`), and `emit_telemetry` supports only `ocsf_event` and `otel_log` payload kinds — there is **no first-class metric telemetry path**. Evidence: Go `sdk/signal_schema.go:15-18` + `sdk/telemetry.go` (only OCSF/OTEL-log constructors); Rust `src/result.rs:354-357` + `src/telemetry.rs` (only `ocsf_event`/`otel_log`). ### Ask - Add a `metric` **signal type** + `otel_metric` **payload kind**. - Add a metric telemetry constructor — Go `NewMetricTelemetryRecord(...)`, Rust `TelemetryRecord::otel_metric(...)` — routed through the existing `emit_telemetry` host import. - The metric carries an OTLP-grade point: `resource` (service identity + attributes), `name`, `kind` (gauge/sum/histogram), `temporality`, `is_monotonic`, `unit` (UCUM), and `points[]` (`time_unix_nano`, `attributes`, `value` or `histogram` buckets, optional `exemplars`). - **Keep `Result.AddMetric` / `add_metric_spec` as perfdata shims** that lower to a single gauge point, so existing plugins keep working unchanged. This is the producer half of the contract evolving `serviceradar.metric.v1` to `schema_version 2` (resource/kind/temporality/points[]); the gateway/core consumer side is tracked in carverauto/serviceradar#3788 and `update-anomaly-evaluation-cadence` (#3791). Contract reference: https://code.carverauto.dev/carverauto/serviceradar/issues/3788

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

carverauto/serviceradar-sdk-rust#5

No description provided.

Rows
Columns