veneur
opstrace
veneur | opstrace | |
---|---|---|
2 | 8 | |
1,714 | 1,153 | |
0.1% | - | |
3.5 | 9.9 | |
about 1 month ago | over 2 years ago | |
Go | TypeScript | |
MIT License | 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.
veneur
-
OpenTelemetry in 2023
This was the idea behind Stripe's Veneur project - spans, logs, and metrics all in the same format, "automatically" rolling up cardinality as needed - which I thought was cool but also that it would be very hard to get non-SRE developers on board with when I saw a talk about it a few years ago.
https://github.com/stripe/veneur
-
Launch HN: Opstrace (YC S19) – open-source Datadog
One pain point with Prometheus is that is has relatively weak support for quantiles, histograms, and sets[1]:
- Histograms require manually specifying the distribution of your data, which is time-consuming, lossy, and can introduce significant error bands around your quantile estimates.
- Quantiles calculated via the Prometheus "summary" feature are specific to a given host, and not aggregatable, which is almost never what you want (you normally want to see e.g. the 95th percentile value of request latency for all servers of a given type, or all servers within a region). Quantiles can be calculated from histograms instead, but that requires a well-specified histogram and can be expensive at query time.
- As far as I know, Prometheus doesn't have any explicit support for unique sets. You can compute this at query time, but persisting and then querying high-cardinality data in this way is expensive.
Understanding the distribution of your data (rather than just averages) is arguably the most important feature you want from a monitoring dashboard, so the weak support for quantiles is very limiting.
Veneur[2] addresses these use-cases for applications that use DogStatsD[3] by using clever data structures for approximate histograms[4] and approximate sets[5], but I believe its integration with Prometheus is limited and currently only one-way - there is a CLI app to poll Prometheus metrics and push them into Veneur, but there's no output sink for Veneur to write to Prometheus (or expose metrics for a Prometheus instance to poll).
It would be extremely useful to have something similar for Prometheus, either by integrating with Veneur or implementing those data structures as an extension to Prometheus.
[1] https://prometheus.io/docs/practices/histograms/
[2] https://github.com/stripe/veneur
[3] https://docs.datadoghq.com/developers/dogstatsd/
[4] https://github.com/stripe/veneur#approximate-histograms
[5] https://github.com/stripe/veneur#approximate-sets
opstrace
- Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF
-
What is everyone using for monitoring and logging
Never had any luck maintaining monitoring stacks over time, until I found https://opstrace.com
-
Kubernetes Podcast episode 156: Opstrace, with Sebastien Pahl
Sebastien Pahl is a pioneer of container technology, building the predecessor to Docker as a co-founder of Dotcloud. After working at some big tech companies, he's back to the startup life as co-founder of Opstrace, a fully open source observability distribution, built on top of the tools you know and love.
- Opstrace: self hosted alternative to datadog; handles administrator of exporters and Prometheus for you.
-
Launch HN: Opstrace (YC S19) – open-source Datadog
Jan-Philip from Opstrace here, good morning. Would love to hear more, after all, when you know more :-). By the way, we had been asked about VictoriaMetrics before, here: https://github.com/opstrace/opstrace/discussions/98.
What are some alternatives?
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
loki - Like Prometheus, but for logs.
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
ApplicationInsights-node.js - Microsoft Application Insights SDK for Node.js
influxdb-apply - Define InfluxDB users and databases with a yaml file.
pixie - Instant Kubernetes-Native Application Observability
b3-propagation - Repository that describes and sometimes implements B3 propagation
skywalking - APM, Application Performance Monitoring System
kiali-ui - Frontend part of Kiali (use github.com/kiali/kiali to report issues)