Metric Rules Help

How to create threshold and composite rules to detect anomalies in derived signals, and how they interact with seasonal auto-rules.

Back to Rules
Choose a Rule Type

Use Threshold for a single signal breach. Use Composite to require two conditions to fire simultaneously. Seasonal rules are created from the Auto Rules panel.

Set Thresholds

Warning fires at the lower bound; Critical fires at the higher bound. The comparator controls whether values above or below the threshold count.

View Anomalies

Once saved, rules annotate the Metrics view and appear in the Anomaly Details page with per-point state badges and drilldown links.

Field Reference
Field Required Description
Name required Unique human-readable label shown in the rules table and anomaly badges.
Rule Type required Threshold — single condition. Composite — primary and secondary must both exceed their thresholds at the same time.
Source required Derived signal source (e.g. otel_traces, otel_logs). Populated from your ingested data.
Signal required Metric name within the source (e.g. http.server.duration).
Service optional Restrict this rule to a specific service. Leave blank to match any service.
Attr FP optional Attribute fingerprint for sub-signal targeting (e.g. a specific HTTP route or RPC method).
Comparator required value >= threshold — fires when value climbs above the threshold (latency, error rate). value <= threshold — fires when value drops below (throughput, availability).
Warning required Threshold that puts the signal into warning state.
Critical required Threshold that puts the signal into critical state. For gt rules critical must be ≥ warning; for lt rules critical must be ≤ warning.
Min Sample required Minimum number of data points in the window before the rule fires. Use a higher value to suppress noise on sparse signals. Default: 1.
Rule Interaction Semantics
  • Manual create supports threshold and composite. Seasonal rules are generated via Auto Rules.
  • Threshold, composite, and seasonal rules can coexist for the same scope (source + signal + service + attr fp).
  • If multiple rules fire at the same severity for a point, precedence is deterministic: seasonal > composite > threshold.
  • Timestamp-based seasonal bucket matching is evaluated in UTC in backend logic.
Threshold Rule — Example

Fire a warning when p95 HTTP duration exceeds 500 ms and a critical when it exceeds 1 000 ms, ignoring windows with fewer than 5 samples.

Settings
Name High p95 Latency
Rule Type threshold
Source otel_traces
Signal http.server.duration
Comparator value >= threshold
Warning 500
Critical 1000
Min Sample 5
Resulting States
  • Value < 500 ms → normal
  • 500 ms ≤ value < 1 000 ms → warning
  • Value ≥ 1 000 ms → critical
  • Fewer than 5 samples in window → skipped
Composite Rule — Example

Only flag critical when both error rate is high and request volume is significant — avoids noisy alerts during low-traffic windows.

Primary Condition
Source otel_traces
Signal error_rate
Comparator value >= threshold
Warning 0.05
Critical 0.15
Secondary Condition
Source otel_traces
Signal request_count
Comparator value >= threshold
Warning 10
Critical 50
Both conditions must independently reach at least warning level for the composite rule to activate. The effective state is the worse of the two individual states.
Anomaly States & Where to Find Them
State Badges
  • normalNo thresholds breached.
  • warningAt or above warning threshold.
  • criticalAt or above critical threshold.
  • skippedFewer data points than Min Sample.
Where States Appear
  • Metrics view — per-row state badge next to each signal row.
  • Anomaly Details page — time-series chart with coloured per-point markers and a drilldown button to logs, traces, or errors.
  • Dashboard chart badges — anomaly_overlay and derived_signal_overlay chart types surface the worst current state in the card header.