appscope
autometrics-rs
| appscope | autometrics-rs | |
|---|---|---|
| 2 | 8 | |
| 257 | 771 | |
| 1.6% | 0.9% | |
| 9.0 | 8.3 | |
| about 2 months ago | 3 months ago | |
| C | Rust | |
| Apache License 2.0 | 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.
appscope
- Show HN: Instrument any Linux application or command without code modification
-
Tool for debugging a node: process list, tcpdump, etc
Tool called AppScope https://github.com/criblio/appscope has some supper interesting use cases for debugging K8. It translates syscalls to clean well formatting logging so you can see everything including transaction payloads, network traffics and app logs in and me place with the option to output to DD, Elastic or Splunk.
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?
Netdata - The open-source observability platform everyone needs
OpenMetrics - Evolving the Prometheus exposition format into a standard.
pyroscope - Continuous Profiling Platform. Debug performance issues down to a single line of code
eclss - Environmental Controls and Life Support Systems
teletrace - Open-Source Tracing Platform
minitrace-rust - Extremely fast tracing library for Rust
netshoot - a Docker + Kubernetes network trouble-shooting swiss-army container
metrics - A metrics ecosystem for Rust.