veneur
community
veneur | community | |
---|---|---|
2 | 7 | |
1,714 | 695 | |
0.1% | 1.4% | |
3.5 | 9.0 | |
about 1 month ago | 5 days ago | |
Go | Python | |
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
community
-
All you need is Wide Events, not "Metrics, Logs and Traces"
otel is working on their events spec https://github.com/open-telemetry/community/issues/1688
- Open-Telemetry Donation Proposal: Continuous Profiling Agent
- Elastic offers donation of profiling agent to OpenTelemetry project
-
OpenTelemetry in 2023
1. Agreed. It's the sink and the house attached to it, and the docs are thin and confusing as a result.
2. I had a similar experience to you. I wanted to implement a simple heartbeat in our app to get an idea of usage numbers. This is surprisingly not possible, which greatly confuses me given the name of the project. The low engagement on my question put me off and I abandoned my OpenTelemetry planning completely. [1][2]
[1] https://github.com/open-telemetry/community/discussions/1598
- Decision about public video recordings
-
Frontend Overhaul of OTel Demo: Go to Next.js
One of the OpenTelemetry Project's many Special Interest Groups (SIG) is the OpenTelemetry Community Demo SIG which gives support to a set of instrumented backend microservices and a web frontend app that are primarily used to showcase how to instrument a distributed system using OpenTelemetry. The application's main focus is to demonstrate the implementation process to instrument an application no matter what programming language, platform, or operating system your team is using, as well as providing different approaching techniques (automatic and manual instrumentation, metrics, baggage). All of this while following the standards and conventions defined by the official OpenTelemetry Documentation. More about the specific requirements can be found here. At Tracetest, we have always focused on becoming part of and embracing the OpenTelemetry community. One of our goals this summer was to get more involved with a core OpenTelemetry project where we could provide a meaningful contribution. The OTel demo became the best match for achieving that goal as it would not only help the community, but we at Tracetest needed a good example to test and showcase what can be done with our tool. During the version 0.7 project cycle, we created two specific tickets to get us closer to the community and start looking for things to pick up:
- community/mission-vision-values.md at main · open-telemetry/community
What are some alternatives?
opstrace - The Open Source Observability Distribution
Airline-Microservices - Airline Microservice is a simple Airline application for online reserving flight ticket. This application based on different software architecture and technologies like .Net Core, CQRS, DDD, Vertical Slice Architecture, Docker, kubernetes, tye, masstransit, RabbitMQ, Grpc, yarp reverse proxy, Identity Server, Redis, SqlServer, Entity Framework Core, Event Sourcing and different level of testing.
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
trouble-training - FullStack DDD/CQRS with GraphQL workshop including distributed tracing and monitoring. This shows the configuration from React frontend to .Net backend.
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
b3-propagation - Repository that describes and sometimes implements B3 propagation
loki - Like Prometheus, but for logs.
docs - Prometheus documentation: content and static site generator
influxdb-apply - Define InfluxDB users and databases with a yaml file.
tracetest - 🔭 Tracetest - Build integration and end-to-end tests in minutes, instead of days, using OpenTelemetry and trace-based testing.
opentelemetry-proto - OpenTelemetry protocol (OTLP) specification and Protobuf definitions