Autometrics: a developer-first observability framework that writes queries for you
Originally published on the Fiberplane Blog
Observability is useful for building reliable systems, but most tools don’t focus enough on making the data understandable and actionable for developers. Autometrics is an open source framework that makes it easy to track the most useful metrics and actually understand the data with automatically generated queries, alerts, and dashboards.
Autometrics is built on OpenTelemetry and Prometheus and extends those projects to make the experience way more developer-friendly – and hopefully even fun. There are libraries available today in Rust, Typescript, Go, and Python and we’re looking for developers to try it out and give us feedback!
Observability in code
Autometrics starts with the simple idea of tying metrics to functions in source code. Functions are the building block of code and function-level metrics provide an observability sweet spot that balances debuggability, cost, and ease of use.
The autometrics libraries make it trivial to track the request rate, error rate, and duration of any function in your code base, from HTTP or RPC handlers down to internal application logic and database methods. The libraries use metaprogramming techniques (macros, decorators, etc) in each language to generate instrumentation code using existing client libraries for OpenTelemetry and/or Prometheus.
For example, the Rust autometrics library uses a very simple macro to instrument functions:
#[autometrics]
async fn create_user() {
// Now this function will be producing metrics!
}
This gives you a useful starting point for metrics, without you needing to think about which specific metrics to track and what to name each one. In case you are interested, though, this tracks the function call and error rate using a counter called function.calls.count and it tracks the latency using a histogram called function.calls.duration, both of which have a label called function for the function name.
Writing queries for you (without AI)
The fact that autometrics generates metrics with specific names and labels makes it possible to write useful queries for you as well.
Crafting queries by hand is hard and, even after you get some data back, it’s hard to know whether you have the right data to answer a particular question. Simply by standardizing the names of metrics and labels, autometrics makes it possible to share useful queries between teams. This is actually even better than having queries generated by AI because you need confidence that the query not only looks plausible but will actually return the correct data to answer a given question.
We can build queries for specific functions or groups of functions and use them across all autometrics-instrumented projects. This is the foundation that the next couple of features build upon.
Bringing production data closer to the IDE
The most unique feature of the autometrics libraries is that they can insert links to live Prometheus charts directly into each function’s documentation. When you hover over the name of a function instrumented with autometrics, you’ll see the links to the live graphs for that specific function:
You can also watch a short demo of this experience here.
Bringing observability data into the IDE is useful because that is where developers are most at home and, more importantly, where we already have our mental model of the system. Instead of looking at a dashboard and trying to rebuild our mental model, we can start out looking at our code and jump from there to production metrics – without needing to write queries by hand!
Powerful alerting based on SLOs
Autometrics also enables you to define powerful alerts based on best practices around Service-Level Objectives (SLOs) – directly in your source code. You can create an objective for stipulating that a certain percentage of requests should return successfully and/or within a given response time and you’ll get alerts when those goals are in jeopardy.
const API_SLO: Objective = Objective::new("api")
.success_rate(ObjectivePercentile::P99)
.latency(ObjectiveLatency::Ms250, ObjectivePercentile::99_9);
#[autometrics(objective = API_SLO)]
async fn create_user() {
// ...
}
You can read more about this feature in autometrics-rs 0.3: Defining Service-Level Objectives (SLOs) in Rust source code. For an even more detailed write-up of how this feature works under the hood and the PromQL label trickery involved, take a look at An adventure with SLOs, generic Prometheus alerting rules, and complex PromQL queries.
Out-of-the-box dashboards
Autometrics uses the standardization of function-level metrics to provide Grafana dashboards that will work out of the box for any autometrics-instrumented project. This immediately makes it easy to visualize your metrics data without needing to spend time figuring out what is worth showing and writing the queries by hand.
One dashboard shows the status of any objectives you’ve configured. Another provides an overview of the functions with the highest request and error rates. And the third enables you to dive into the metrics for a specific function.
Conclusion: developer-friendly observability
Autometrics starts with the simple premise of standardizing function-level metrics and generating instrumentation from source code. That makes it trivial to get started with useful observability data while also making it easy to understand the data generated with automatically customized PromQL queries. Using these queries, the libraries insert links to the live charts directly into your IDE and they come with alerting rules and dashboards that will work out of the box.
Tying metrics to code not only makes observability super simple to set up, it also makes the data produced far more useful to developers who will inevitably be called in to debug issues. Because the metrics are related to specific functions, it’s easy to go from an alert or dashboard straight to the source code to pinpoint the source of a problem. We think this will make for a more efficient and pleasant debugging experience that will mean you can spend less time thinking about observability and more time shipping useful, performant, and reliable features.
Get involved!
If you’re interested in adding metrics to your functions, check out the open source autometrics libraries.
Also, if you’d like to help bring this to more programming languages or contribute to standardizing function-level metrics, please come get involved in the project – we would love to hear from you!
Autometrics & Fiberplane
Autometrics was originally developed at Fiberplane, and the company is investing heavily in developing the framework as a standalone open source project. We’ll be working on new language implementations, tie-ins with logs and traces, the VS Code extension and other editor integrations, and lots more.
At the same time, we’re working on related products and services to help make working with autometrics data even more efficient and developer-friendly. Stay tuned for more details!