Metrics are the quantitative backbone of observability—the numbers that tell us how our systems are performing. This is the third post in our OpenTelemetry naming series, where we’ve already explored how to name spans and how to enrich them with meaningful attributes. Now let’s tackle the art of naming the measurements that matter.
Unlike spans that tell stories about what happened, metrics tell us about quantities: how many, how fast, how much. But here’s the thing—naming them well is just as crucial as naming spans, and the principles we’ve learned apply here too. The “who” still belongs in attributes, not names.

OpenTelemetry's platform is an observability framework, offering insights into distributed tracing, metrics collection, and log management for cloud-native applications. Through documentation, tutorials, and community contributions, OpenTelemetry provides insights into instrumenting applications to monitor performance and troubleshoot issues. Developers and DevOps teams can learn about distributed tracing standards, telemetry data formats, and integration with observability tools to gain visibility into complex distributed systems.

OpenTelemetry

OpenTelemetry metrics should focus on what is being measured rather than who is measuring it. Service names, units, and deployment context belong in attributes, not metric names. This approach enables cross-service aggregation, reduces namespace clutter, and creates reusable dashboards. Clean metric names like 'transaction.count' with service.name attributes are more maintainable than traditional patterns like 'payment_service_transaction_total'.

How to Name Your Metrics

The core anti-pattern: Service names in metric names