otel_increase

No division and no extrapolation — this is the answer to "how much did this counter go up", where otel_rate($raw, <window>) answers "how fast was it going" and scales a per-series rate across the whole window (bzrk extension).

The argument is a dynamic of metric shape — the field set produced by the OTel-to-bzrk mapping (timestamp, value, start_time, aggregation_temporality, metric_hash, …) — of which $raw over a metric table is the usual source. Every field the aggregate needs, the series key included, is read from that one argument.

Takes no window argument. The group is the window: by bin(timestamp, 5m) gives per-bin increase, no grouping gives the total over the query's range.

For cumulative sums, start_time identifies each counter epoch, so a restart is detected deterministically rather than inferred from a value decrease. An epoch that began inside the group started from zero, so its whole last value accrued in-group; one that predates the group's first row contributes only its rise. Within an epoch the counter is taken to be monotonic, which is what a cumulative monotonic sum means. The result is therefore never negative. For delta sums the values are already increments and are summed.

start_time is the only reset signal, so a producer that restarts a counter without minting a new one is reporting a metric this aggregate cannot total: the rise before each unsignalled reset is gone, and no bounded per-epoch state can recover it — a counter stepping 0 → P₁ → 0 → P₂ → v hides every Pᵢ. Rather than return the undercount, the aggregate returns null with a warning whenever it can prove this happened, which is when an epoch falls below its own opening value. A decrease that stays above that opening value is not detectable from per-epoch state and is neither corrected nor flagged; use otel_delta for a metric that legitimately decreases.

Series are detected via metric_hash, so a group holding many series — the usual multi-pod shape — is handled correctly, and each restarted pod counts its own contribution once instead of claiming the full window. by metric_hash is not required for correctness; add it only when you want one output row per series.

The two slivers between the group's edges and the nearest observation are not attributable from cumulative samples alone, so the total is bounded below by at most one scrape interval per edge.

A carry-over epoch contributes nothing rather than zero unless an interval was actually observed within it — two samples at different timestamps. One sample, or several sharing an instant, spans nothing, so there is no earlier in-group value to difference against and the rise is unknown (#4989). Two samples ten seconds apart that agree do prove the counter stood still over those ten seconds, and that is a zero. An epoch that began inside the group is knowable from a single observation, since it started from nothing.

Returns null if rows have mixed temporalities, null for an empty group, and null for a group in which no epoch was measurable — the same rule otel_rate follows, so the two aggregates agree about identical input.

otel_increase is itself an aggregate: use it directly as a summarize output — never nested inside another aggregate such as avg(...) or sum(...) (that is a WRONG FUNCTION CONTEXT error).

Syntax

otel_increase($raw)

Parameters

Returns: real

Examples

Example 1

// total ingest over the query's range, across every pod and restart
OtelMetrics
| where metric_name == "bzrk.nursery.bytes_ingested_uncompressed"
| summarize ingestBytes = otel_increase($raw)

Example 2

// increase per 5-minute bin, by service
OtelMetrics
| where metric_type == "sum"
| summarize inc = otel_increase($raw) by resource.service.name, bin(timestamp, 5m)

Example 3

// one row per series
OtelMetrics
| where metric_name == "http.server.request.count"
| summarize inc = otel_increase($raw) by metric_hash