ferrisetw
autometrics-rs
| ferrisetw | autometrics-rs | |
|---|---|---|
| 2 | 8 | |
| 56 | 778 | |
| - | 1.0% | |
| 5.5 | 8.3 | |
| 4 days ago | 4 months ago | |
| Rust | Rust | |
| GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ferrisetw
autometrics-rs
- Show HN: Autometrics – open-source observability stack
- Show HN: Autometrics Explorer – A Contextual UI for Prometheus
-
Ask HN: Are You Using OpenTelemetry?
I’ve been working on an open source project built on OpenTelemetry and Prometheus client libraries (https://autometrics.dev). The DX of the OTel libraries is pretty painful in all the languages we’ve used. Granted, we’re using them for metrics while traces are more common, but still.
I think the fundamental issue for the DX is that it’s trying to do everything everyone might want out of all of the observability signals. That’s a useful and laudable goal but it means that everything is configurable and relatively difficult to use.
-
What are good options for observability for tiny startup?
If you go with Prometheus, we’re building Autometrics to make producing and querying metrics easier for developers. It makes it trivial to instrument functions to track the request rate, error rate, and latency and then writes PromQL for you. The Autometrics libraries are thin layers on top of existing Prometheus and OpenTelemetry libraries.
-
Autometrics 0.4: Spot commits that introduce errors or slow down your application
Autometrics is an open source observability framework that makes it trivial to add useful metrics to your code and writes Prometheus queries for you to help you understand the data. This feature shows the power that comes from pairing code instrumentation with automatically writing queries (and the queries it writes are a whole lot more complicated than what you'd want to write by hand!).
-
Minimal, allocation-free OpenMetrics implementation for no-std/embedded Rust
How do people tend to get metrics off of embedded devices?
I’m working on https://github.com/autometrics-dev/autometrics-rs and people asked whether it could be used in embedded contexts but I wasn’t sure how you’d hook up the device to something like Prometheus.
-
autometrics: easily add metrics to any function -- and jump to live Prometheus charts directly from your IDE (links with automatically customized PromQL queries are inserted into each function's doc comments)
I just opened these two issues for [supporting `prometheus-client`](https://github.com/fiberplane/autometrics-rs/issues/25) and another for [supporting exemplars](https://github.com/fiberplane/autometrics-rs/issues/26).
What are some alternatives?
minitrace-rust - Extremely fast tracing library for Rust
OpenMetrics - Evolving the Prometheus exposition format into a standard.
tracing-indicatif - Tracing layer that automatically creates and manages progress bars for active spans.
eclss - Environmental Controls and Life Support Systems
tracing-newrelic - New Relic integration for tracing
tracing - Application level tracing for Rust.
metrics - A metrics ecosystem for Rust.
rust-kafka-producer-partitioner-example - Example Code for "How to Build a Kafka Producer in Rust with Partitioning"
hs-opentelemetry - OpenTelemetry support for the Haskell programming language
ansible - Ansible Collection for Prometheus