Metrics Generation

Overview

The Metrics Generation processor synthesizes new metrics from existing ones using a small set of arithmetic rules. Two rule types:

• calculate — combine two existing metrics (metric1, metric2) with one of add, subtract, multiply, divide, percent, producing a new metric name.
• scale — multiply a single existing metric (metric1) by a constant (scale_by), producing a new metric name.

Use it for derived KPIs that don't exist in the source data: error rate from errors / total, memory headroom from mem_total - mem_used, byte-to-bit conversion via scale, etc.

The original metrics are preserved alongside the generated ones — this is an additive processor.

Supported types: Metrics

Note: The underlying receiver type is experimental_metricsgeneration. Upstream still considers it experimental; the API may change.

Configuration

Parameter	Type	Default	Required	Description
rules	object[]	—	Yes	At least one rule. See "Rule fields" below.

Rule fields

Field	Type	Required	Description
name	string	Yes	Name of the generated metric. Must be unique.
unit	string	No	Unit string (e.g. By, s, 1) attached to the generated metric.
type	string	Yes	Either calculate or scale.
metric1	string	Yes	Name of the first source metric.
metric2	string	Yes when type=calculate	Name of the second source metric. Ignored for scale.
operation	string	Yes when type=calculate	One of add, subtract, multiply, divide, percent.
scale_by	float	Yes when type=scale (must be > 0)	Constant multiplier.

Example Configuration

{
  "rules": [
    {
      "name": "http.server.error_rate",
      "unit": "1",
      "type": "calculate",
      "metric1": "http.server.errors",
      "metric2": "http.server.requests",
      "operation": "divide",
    },
    {
      "name": "system.memory.headroom_bytes",
      "unit": "By",
      "type": "calculate",
      "metric1": "system.memory.total",
      "metric2": "system.memory.used",
      "operation": "subtract",
    },
    {
      "name": "system.network.bits_in",
      "unit": "bit",
      "type": "scale",
      "metric1": "system.network.bytes_in",
      "scale_by": 8.0,
    },
  ],
}

Notes

• Type compatibility. calculate requires both source metrics to have the same type, temporality, and (for histograms) bucket layout. Mismatches produce no output (and a runtime warning).
• Both metrics must be in the same scrape. Operations are applied per data point pair; if metric1 and metric2 are emitted by different receivers / different scrape cycles, only points that align in time produce a result.
• Order: place after any unit conversion or filtering, before aggregation/batching, so the new metric flows through the same downstream processing as its inputs.
• Cardinality: the generated metric inherits the union of metric1 and metric2's attribute sets. If those have different attribute keys, you'll get a high-cardinality result.