veneur
proposal-async-context
veneur | proposal-async-context | |
---|---|---|
2 | 3 | |
1,714 | 449 | |
0.1% | 3.6% | |
3.5 | 6.3 | |
about 1 month ago | 23 days ago | |
Go | HTML | |
MIT License | Creative Commons Zero v1.0 Universal |
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
proposal-async-context
-
OpenTelemetry in 2023
You can follow [0] which is currently stage 2 to fix this
[0]: https://github.com/tc39/proposal-async-context
-
React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds
Yeah in the stream they talk about using AsyncContext to sorta do that.
-
Updates from the 94th TC39 meeting
Async Context: proposal is to provide a mechanism to ergonomically track async contexts in JavaScript.
What are some alternatives?
opstrace - The Open Source Observability Distribution
terraform-aws-jaeger - Terraform module for Jeager
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
proposal-symbols-as-weakmap-keys - Permit Symbols as keys in WeakMaps, entries in WeakSets and WeakRefs, and registered in FinalizationRegistries
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
proposal-symbol-proto - TC39 proposal for mitigating prototype pollution
loki - Like Prometheus, but for logs.
proposal-symbol-predicates - A proposal to introduce ways to differentiate symbols
influxdb-apply - Define InfluxDB users and databases with a yaml file.
community - OpenTelemetry community content
b3-propagation - Repository that describes and sometimes implements B3 propagation
proposal-import-assertions - Proposal for syntax to import ES modules with assertions [Moved to: https://github.com/tc39/proposal-import-attributes]