> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Exploring metrics

> Browse the metric catalogue, chart series over time, and understand why a wide time range answers at a coarser resolution than a narrow one.

Metrics answer *how much, how often, how slow* — cheaply, and over windows that
would be impractical to ask of logs or traces.

<Info>
  **Before you start.** You need metrics arriving from at least one source: an
  OpenTelemetry SDK, a Collector, or
  [Prometheus remote-write](/send-data/prometheus).
</Info>

## Finding a metric

The **metric catalogue** lists every metric name seen in your organization,
discovered from what has arrived rather than declared in advance. A metric
appears the first time a sample is written and stays listed while data remains
inside retention.

Metric names arrive in two shapes and both work:

| Source                  | Shape                          |
| :---------------------- | :----------------------------- |
| Prometheus remote-write | `http_requests_total`          |
| OpenTelemetry           | `http.server.request.duration` |

<Note>
  **Nothing is normalised between them.** If the same measurement reaches you
  from both a Prometheus server and an OpenTelemetry SDK, you will see two
  metrics with two names and two sets of labels. Pick one path per measurement
  rather than reconciling them afterwards.
</Note>

## Charting

Select a metric, filter on its labels, and choose an aggregation. The chart
respects the time-range picker, which is the setting that most often explains a
surprising result.

## Resolution changes with the range

<Warning>
  **A wide range is answered from pre-aggregated data.** Metrics are
  continuously rolled up to one-minute and one-hour resolution, and a query
  reads whichever fits:

  * Recent, narrow ranges → full resolution
  * Longer ranges → the one-minute rollup
  * Months → the one-hour rollup

  So a 20-second spike is visible on a 15-minute chart and averaged away on a
  30-day one. **It is not missing — it is summarised.** No amount of zooming a
  wide range recovers it; narrow the range instead.
</Warning>

There is an opposite effect on very fresh data. A sample written seconds ago is
in the raw table before the rollups covering it are complete, so it can be
visible on "last 15 minutes" and not yet on "last 7 days". Wait a minute rather
than widening the range. See [Data retention](/concepts/retention).

## How long metrics are kept

|                   |              |
| :---------------- | :----------- |
| Full resolution   | 30 days      |
| One-minute rollup | 90 days      |
| One-hour rollup   | **365 days** |

Metrics outlive logs and traces by a year, which is what makes them the right
signal for capacity planning and trend analysis.

## Cardinality

Every distinct combination of label values is a separate stored series, and
that — not the number of samples — is what drives cost.

<Warning>
  **A label carrying a user id, request id or raw URL path turns one metric
  into millions of series.** The effect is silent: charts get slower, ingest
  grows, and nothing reports an error.

  Per-request values belong on spans and log records. See
  [cardinality](/concepts/data-model#cardinality-is-the-cost-you-cannot-see).
</Warning>

## Metrics you get without instrumenting anything

| Source                   | Provides                                          |
| :----------------------- | :------------------------------------------------ |
| Collector `hostmetrics`  | CPU, memory, disk, filesystem, network per host   |
| Collector `kubeletstats` | Per-pod and per-container usage                   |
| Collector `docker_stats` | Per-container resource usage                      |
| Derived from spans       | Request rate, error rate and duration per service |

The last is worth knowing about: **RED metrics are derived from your traces**,
so instrumenting for traces gives you the service-level metrics for free.

## Querying from your own tools

Metrics are readable through the API, and there is a **Prometheus-compatible
query API** so Grafana can use aiAxonIQ as a datasource without an adapter —
including its limits, which are worth reading before you rely on it. See
[Grafana and Prometheus clients](/guides/integrations/grafana).

## Alerting on a metric

A threshold rule compares an aggregate against a bound on a fixed 60-second
loop. Two things catch people out — only three comparators exist, and a rule
saved with an unimplemented one is created without complaint and never fires.
See [Alerting](/guides/alerts/overview).

## Next

<CardGroup cols={3}>
  <Card title="Build a dashboard" icon="table-columns" href="/guides/dashboards/overview">
    Panels, templates, versions and shareable snapshots.
  </Card>

  <Card title="Set an SLO" icon="bullseye" href="/guides/slos/overview">
    Error budgets and burn-rate alerting.
  </Card>

  <Card title="Forecast and anomalies" icon="wand-magic-sparkles" href="/guides/ai/overview">
    Where the AI features read metrics.
  </Card>
</CardGroup>