veneur
opentelemetry-js-contrib
veneur | opentelemetry-js-contrib | |
---|---|---|
2 | 8 | |
1,714 | 597 | |
0.1% | 1.5% | |
3.5 | 9.5 | |
about 1 month ago | 6 days 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
opentelemetry-js-contrib
-
OpenTelemetry in 2023
[2] https://github.com/open-telemetry/opentelemetry-js-contrib/t...
- OpenTelemetry-based traces for every web page with zero code change.
- How to trace database query with OpenTelemetry and Zipkin for a Node.js app?
-
How to Instrument AWS Services with OpenTelemetry
@opentelemetry/instrumentation-aws-lambda
-
How to solve "Cannot redefine property: handler" on AWS Lambda
As suggested in both opentelemetry-js-contrib and aws-otel-lambda issues, the solution is changing ES6 export to CommonJS module.exports.
-
How To Use OpenTelemetry With AWS Lambda
More information about this can be found here and in the instrumentation docs.
-
GraphQL - Diving Deep
Opentelemetry has recently made support for GraphQL available. You can find it here
-
The Stack #3
Now, the exciting thing is that there is now a reference implementation to the same using GraphQL which you can find here and also an example to help you out with the same here
What are some alternatives?
opstrace - The Open Source Observability Distribution
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
mercurius - Implement GraphQL servers and gateways with Fastify
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
Hasura - Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.
loki - Like Prometheus, but for logs.
react-relay - Relay is a JavaScript framework for building data-driven React applications.
influxdb-apply - Define InfluxDB users and databases with a yaml file.
Hoppscotch - Open source API development ecosystem.
b3-propagation - Repository that describes and sometimes implements B3 propagation
aws-otel-lambda - AWS Distro for OpenTelemetry - AWS Lambda