Open-Source Observability · autometrics-dev

autometrics-rs

Autometrics is a Rust library that automatically instruments functions with production-ready metrics (request rate, error rate, latency) via a simple macro decorator. It integrates with Prometheus and OpenTelemetry, generates pre-built Prometheus queries, and includes Grafana dashboards—but the project is no longer actively maintained.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/autometrics-dev/autometrics-rs

834

GitHub stars

Forks

Rust

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	autometrics-dev/autometrics-rs
Owner	autometrics-dev
Primary language	Rust
License	Apache-2.0 — OSI-approved
Stars	834
Forks	33
Open issues	14
Latest release	v3.0.0 (2025-09-18)
Last updated	2025-09-18
Source	https://github.com/autometrics-dev/autometrics-rs

What autometrics-rs is

A procedural macro (`#[autometrics]`) that wraps functions to emit standardized metrics through pluggable backends (Prometheus, OpenTelemetry, metrics crate). It correlates metrics with code versions, supports SLO-based alerts and trace exemplars, and produces ~140-2100 ns overhead depending on the backend used.

Quickstart

Get the autometrics-rs source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/autometrics-dev/autometrics-rs.git2cd autometrics-rs3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Rapid instrumentation of existing Rust services

Quickly add production metrics to functions without writing custom prometheus queries. Ideal for teams adopting observability in codebases where metrics were previously sparse.

Function-level SLO definitions and alerting

Define alert thresholds and SLO targets directly in source code as part of function signatures, keeping observability concerns co-located with business logic.

Greenfield Rust microservices with Prometheus/Grafana

New services designed to use Prometheus from the start can benefit from auto-generated dashboards and pre-configured metric shapes without manual PromQL tuning.

Implementation considerations

Verify the exact version of the underlying metrics library (prometheus-0_14, prometheus-client-0_21, etc.) matches your codebase; mismatches cause metrics registry duplication and data loss.
Configure the metrics exporter endpoint early (e.g., /metrics) and ensure Prometheus scrape config targets it; no automatic service discovery is provided.
Benchmark overhead with your chosen backend (140 ns for prometheus-0_14 up to ~2100 ns for opentelemetry-0_20); validate against your function call frequency and latency budgets.
Plan cardinality: function-level metrics are granular but still bounded; avoid instrumenting generated/dynamic function names to prevent label explosion.
Decide whether to instrument all public functions or selectively add the macro; the examples show both patterns but systematic adoption requires a team convention.

When to avoid it — and what to weigh

Requires active upstream support and rapid bug fixes — Project is explicitly no longer actively maintained. Security patches, breaking dependency updates, and compatibility fixes are not guaranteed.
Need metrics backends other than Prometheus/OpenTelemetry/metrics — Autometrics is tightly coupled to specific metric collection libraries. Custom or proprietary backends require significant additional integration work.
Prefer minimal macro-based code generation — The macro modifies function signatures and behavior. Teams uncomfortable with procedural macros or their compile-time overhead should use explicit instrumentation libraries.
Existing complex, heterogeneous observability stack — If your organization already has custom metric schemas, labeling conventions, or non-standard collectors, Autometrics' opinionated standardization may create conflicts.

License & commercial use

Licensed under Apache-2.0, a permissive OSI license allowing commercial use, modification, and distribution with minimal restrictions (requires attribution and a copy of the license).

Apache-2.0 permits commercial use, but the project is no longer actively maintained. For production deployments, assess your tolerance for unmaintained dependencies: no vendor support, no guarantee of security patches, and potential incompatibility with future Rust toolchain or ecosystem changes.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Stale
Documentation	Strong
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Possible
Assessment confidence	High

Security considerations

Standard library security hygiene applies. No built-in metrics authentication; the /metrics endpoint must be protected separately (e.g., firewall, reverse proxy). Metrics themselves can leak information about application behavior; use appropriate access controls. Unmaintained status means security advisories for transitive dependencies may not be promptly addressed.

Alternatives to consider

tracing + metrics crates (manual instrumentation)

Lower-level, actively maintained, and gives full control over metric schemas and cardinality. More boilerplate but no macro-based coupling or unmaintained risk.

OpenTelemetry Rust SDK + otel-prometheus (manual setup)

Industry-standard, vendor-neutral, and actively maintained. Requires more configuration but offers richer context (traces, logs, metrics) and direct supplier support.

Prometheus client libraries (prometheus-rs)

Direct, battle-tested, and actively maintained. No automation, but full transparency and control; better for teams with established observability practices.

Software development agency

Build on autometrics-rs with DEV.co software developers

Autometrics offers quick instrumentation but is no longer maintained. Assess your risk tolerance and consider actively-maintained alternatives before production adoption.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

client_rust opentelemetry-rust pgmetrics

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability API Development DevOps & Observability Application Development Talk to DEV.co

autometrics-rs FAQ

Is autometrics still supported?

No. The README explicitly states 'Autometrics is no longer actively maintained.' Expect no bug fixes, security updates, or feature development. Use at your own risk in production.

What is the performance overhead?

Depends on the metrics backend: ~140–150 ns (prometheus-0_14), ~550–650 ns (metrics), ~1700–2100 ns (opentelemetry). Benchmark with your target backend before committing.

Can I use autometrics with my existing Prometheus setup?

Yes, if the underlying Prometheus crate version matches exactly. Set the feature flag for your version (e.g., `prometheus-0_14`); mismatches cause registry duplication and lost metrics.

Do I need to set up Grafana?

No, but it is recommended. Autometrics generates PromQL queries viewable in the IDE and Prometheus UI; Grafana dashboards (from autometrics-shared) provide a polished visualization layer but are optional.

Work with a software development agency

From first prototype to production, DEV.co delivers software development services around tools like autometrics-rs. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source observability and beyond.

Evaluate Autometrics for your Rust observability

Autometrics offers quick instrumentation but is no longer maintained. Assess your risk tolerance and consider actively-maintained alternatives before production adoption.

Talk to DEV.co Schedule a Consultation