Skip to main content
Axiom’s dedicated MetricsDB provides a purpose-built metrics database that handles high-cardinality time-series data without the cost penalties and performance degradation common in traditional metrics systems. This section explains how to work with OpenTelemetry (OTel) metrics in Axiom.
Support for OTel metrics is currently in private preview. For more information, see Feature states.

​
What makes MetricsDB different

MetricsDB is engineered from the ground up to embrace dimensional complexity:
  • High-cardinality as a design principle: Store metrics with high-cardinality dimensional tags. Where other metrics databases penalize you with higher costs or degraded performance, MetricsDB treats high cardinality as a core capability.
  • Intentional architecture: The storage format, query engine, and compression algorithms are specifically optimized for time-series metrics workloads. These design constraints are thoughtful trade-offs that deliver exceptional performance and cost-efficiency for real-world metrics use cases.
  • Unified observability: Query metrics alongside logs and traces, enabling powerful correlations across all your telemetry data without switching tools or learning multiple query languages.

​
Prerequisites

You must use a dedicated dataset for OTel metrics. When you create a dataset, select the type of OTel data you want to send to it. For more information, see Create dataset.

​
Ingest metrics

You can ingest OTel metrics the same way you ingest logs and traces. For more information, see Send OpenTelemetry data to Axiom.
The /v1/metrics endpoint only supports the application/x-protobuf content type. JSON format isn’t supported for metrics ingestion.

​
Query metrics

You can query metric data using the Axiom Console. For more information, see Query metrics.
Example metrics query

​
Dashboards and monitors

You can use OTel metrics in dashboards and monitors the same way you use logs and traces.
  • Build visualizations using metrics queries.
  • Set alerts on derived metrics such as error rate or latency percentiles.
  • Combine multiple signals in a single panel.
For more information, see Dashboards and Monitors.
OTel metrics dashboard

OTel metrics dashboard

​
Design choices and constraints

MetricsDB makes intentional architectural trade-offs to optimize for the most common metrics use cases while maintaining exceptional performance at scale.

​
Query scope

You can query one dataset per query.

​
Supported data types

MetricsDB focuses on the core OpenTelemetry metric types that cover the vast majority of observability scenarios. Axiom supports the following OpenTelemetry metric types:
  • Counter: Monotonically increasing values. For example, request count.
  • UpDownCounter: Values that can increase or decrease. For example, active connections.
  • Gauge: Point-in-time measurements. For example, CPU usage or temperature.
  • Histogram: Distribution of values with configurable buckets. For example, request latency.
Axiom doesn’t currently support the following data types:
  • Exponential histograms
  • bytes, kvlist, and array tag value types
  • Exemplar, baggage, and context data
  • Nanosecond-precision timestamps

​
Data model optimizations

MetricsDB applies the following transformations to improve query performance and reduce storage costs:
  • Timestamp precision: Truncate nanosecond timestamps to second precision. Second-level granularity is sufficient for metrics analysis (unlike traces which need finer resolution), and this optimization significantly improves compression ratios and query speed.
  • Unified tag namespace: Flatten resource, scope, and metric tags into a single namespace. This simplification makes queries more straightforward and enables faster dimensional filtering. You don’t need to remember which tags came from which scope.
  • Unit normalization: Convert the unit attribute to otel.metric.unit for consistent handling across all metric types.
  • Histogram handling: Assume equal-width histograms and don’t preserve histogram metadata. This trade-off supports the most common histogram analysis patterns (percentiles, distribution visualization) while reducing storage requirements.
These design choices reflect real-world metrics usage patterns. If your use case requires capabilities not currently supported, contact Axiom to discuss your requirements. Your feedback helps shape MetricsDB’s evolution.