Explore and compare metrics

Use metrics to locate when and where system behavior changed. Then hold the project, environment, and time window constant while you inspect traces, logs, Issues, releases, and affected customers.

Inspect a metric

Open Explore → Metrics and work from broad scope to narrow scope:

1. Select the project and environment in the global controls.
2. Choose a metric name. The selector lists names that have been ingested for the active project.
3. Confirm the metric type, OTLP unit, aggregation temporality, description, and available label values in the metadata card. Histogram metrics also show the number of observations in the selected window.
4. Use Group by label to compare one low-cardinality dimension such as market, region, or service_name directly on the page.
5. Set the time range to Last 1 hour, 6 hours, 24 hours, or 7 days.
6. Choose a bucket interval from 1m through 1d. A wider range normally needs a wider interval.
7. Choose the aggregation that matches the values your instrument emits.
8. Turn Forecast off when you want to inspect only observed data, or leave it on to compare with the expected band. The fit card explains whether the cone is ready, lacks history, has gaps, or has no stable daily seasonality; an empty cone is never presented as an unexplained blank.

When an instrument exports OTLP exemplars with trace and span context, Trace exemplars lists up to 20 representative measurements from this exact project, metric, dimensions, and time range. Open one to move directly from the metric symptom to the trace waterfall. Exemplar-only filtered attributes follow the same ingestion redaction policy as other telemetry. Values use the selected metric’s instrument unit when one was exported, so a latency exemplar is shown as 8 ms, for example. An exporter may emit an exemplar without trace context; Anectico retains that measurement but does not show it as a trace link. Partial and all-zero trace contexts are excluded as non-drillable.

The active metric-series notice on this page is organization-wide, even while the chart is scoped to the selected project. It warns near the limit and may lag ingestion by a few minutes. At the limit, existing series continue to ingest; unseen metric names or label combinations are rejected and the rejection is non-retryable.

The environment selector is global. The metric, group-by label, aggregation, interval, and time range controls are local to the Metrics page. Refresh reruns the observed-series query and, for a histogram, its native bucket query.

Choose an aggregation deliberately

Aggregation	What it returns	Typical use
avg	Mean of scalar increments, or histogram sum divided by observation count	Gauge level or mean histogram observation
sum	Sum of independent values after temporality normalization	Counter totals or additive work
min / max	Lowest or highest stored value	Saturation bounds and spikes
count	Histogram observations; stored datapoints for other metric types	Histogram volume or export activity
p50 / p95 / p99	Percentile of scalar samples, or a weighted native-histogram bucket upper bound	Observation distributions
stddev / variance	Dispersion of stored scalar values	Dashboard variability analysis

Anectico preserves the OTLP aggregation temporality and point start timestamp. Delta points pass through unchanged. For cumulative monotonic sums and histograms, Anectico subtracts the previous point from the same metric stream before applying the selected time bucket or grouping. A changed start timestamp, decreased monotonic value, or decreased histogram count/bucket is treated as an exporter reset and the new value starts a fresh stream. This makes sum a total of independent increments instead of a sum of repeated cumulative snapshots. It does not turn that total into a per-second rate.

Native OTLP histograms preserve their bucket counts. The Metrics page shows those counts as a bucket distribution summed across the selected time range. When a label grouping is selected, the time-series cards split by that label while the distribution explicitly combines all groups. Use a dashboard Histogram or Heatmap for a reusable distribution or a time/bucket heatmap. The Metrics page’s avg for a histogram is its normalized sum divided by its normalized observation count. Histogram p50/p95/p99 use the temporality-normalized native bucket weights rather than the scalar sum of each exported point. Because an explicit histogram does not retain values inside a bucket, the result is the selected bucket’s upper bound; overflow in the terminal bucket is reported at the largest explicit bound as a documented lower-bound clamp.

Compare dimensions and build reusable views

The Metrics page provides a fast single-metric chart and one label grouping. Use Explore → Dashboards when you need filters, two grouping dimensions, multiple targets, formulas, thresholds, or a reusable view.

1. Open the dashboard selector, create or choose a custom dashboard, and select Add widget.

2. Choose a visualization such as Time series, Stat, Bar, Gauge, Histogram, or Heatmap.

3. Under Query, keep the target source as Metric and enter the metric name.

4. Choose the aggregation and interval.

5. Add up to two filter dimensions. Separate alternative values with |, for example:

   service_name=checkout-api|checkout-worker, environment=production

6. Group by up to two dimensions, such as service_name, region.

7. Use the live preview, then configure display unit, decimals, legend, thresholds, comparison, forecast, and refresh behavior as needed.

A widget can contain up to five targets and safe arithmetic expressions such as B / A * 100. Grouped metric queries return at most 50 series. If a query crosses that bound, narrow its filters or remove a high-cardinality grouping dimension.

Histogram and heatmap widgets accept only native OTLP histogram metrics with preserved buckets. They do not support group-by or expressions. An empty distribution panel usually means the selected name is a gauge, counter, summary, or an older histogram without stored bucket data.

Compare observed and expected behavior

The Forecast overlay is an expected band learned from the selected metric’s recent average history. It is useful for seeing whether a value departed from its baseline; it is not a root-cause claim or a guarantee about future capacity. Anectico requires evenly spaced buckets, at least two full daily seasons, and a stable daily pattern. Missing buckets are not compressed. The shown fit score is deterministic seasonal variance explained, not probability, and the band is additive Holt-Winters widened by seasonal deviation. For irregular history, the fit card reports the number of expected grid buckets skipped by forward gaps; duplicate or out-of-order points are irregular but are not misreported as missing buckets. Forecast fit updates are announced politely to assistive technology.

Open Explore → Anomalies for recorded unusual-series findings. Confirm the metric, service, environment, history window, and labels before treating a finding as customer impact. Deployments, traffic changes, seasonality, and instrumentation changes can all move a series.

Query the same data from the CLI

anectico metrics list
anectico metrics labels checkout.duration_ms --since 24h
anectico metrics query checkout.duration_ms \
  --agg p95 \
  --env production \
  --group-by service_name
anectico metrics forecast checkout.duration_ms \
  --interval 5m \
  --env production

The current CLI query adapter does not forward --since, --until, or --interval; it uses the service defaults for the query window and bucket. Use the Metrics REST API when explicit bounds are required. Label discovery does forward its time-window flags, and forecast does forward --interval.

Use --json when another tool needs the response. The complete flag contract is in the CLI command reference.

Turn a symptom into an investigation

When a chart changes:

1. Record the project, environment, metric, labels, and exact time window.
2. Compare services or regions to find where the change begins.
3. Check releases and feature rollouts in that window.
4. Open representative traces from the same service and time range.
5. Follow error spans into logs and Issues.
6. Use linked customer and account evidence to measure who was affected.

Metrics locate the symptom. Traces, logs, errors, replay, and customer timelines provide the causal and human context.

Create an alert only after validating the query

Build and inspect the metric query first. Then create an alert with the same project, environment, metric name, aggregation, threshold, and evaluation window. Use a sustained For duration for noisy series and test the notification route before enabling the rule.

For anomaly conditions, include a metric_name filter so the rule editor can preview the expected band. Treat anomaly and change conditions as approximate signals and keep a conventional threshold for hard service limits.

Resolve empty or misleading results

• No metrics found: verify ingestion, the active project, and the export interval.

• No data in range: widen the time range or select the environment that emitted the series.

• Too many points: use a larger interval; metric queries are bounded to 500 points per series.

• Too many series: remove a group-by dimension or filter to fewer label values.

• Unexpected totals: confirm the instrument type is correct, the label set is stable, and the exporter sends valid OTLP aggregation temporality and point start timestamps.

• Percentile disagrees with a heatmap: use native histogram buckets for the distribution.

• Forecast unavailable: follow the fit card—widen the history for insufficient history, use a wider interval or repair exporter gaps for irregular history, and do not force a cone for a nonseasonal series.

• A service is missing: make service.name and deployment.environment consistent at the resource level.

• Record application metrics

• Metrics REST API

• Review detected anomalies

• Create useful alerts