veneur
signoz
veneur | signoz | |
---|---|---|
2 | 310 | |
1,714 | 16,955 | |
0.1% | 1.5% | |
3.5 | 9.9 | |
about 1 month ago | 5 days ago | |
Go | TypeScript | |
MIT License | GNU General Public License v3.0 or later |
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
signoz
-
Show HN: OneUptime β open-source Datadog Alternative
You should also check out SigNoz [1], we are an open-core alternative to DataDog - based natively on OpenTelemetry. We also have a cloud product if you don't want to host yourself
[1] https://signoz.io
-
Indexing one petabyte of logs per day with Quickwit
You might want to have a look at SigNoz [1] as well. We have also published some perf benchmark wrt Elastic & Loki [2] and have some cool features like logs pipeline for manipulating logs before ingestion
[1] https://github.com/signoz/signoz
- Open-Source Observability β SigNoz
-
Tools used by the top 1% of Platform Engineers and their Commercial Open Source Alternatives
Check Signoz's repo on GitHub
-
Show HN: Quickwit β OSS Alternative to Elasticsearch, Splunk, Datadog
SigNoz maintainer here.
We also have traces, metrics and logs in a single application which makes correlation across them much easier. From what I can understand from Quickwit website, they use Grafana and Jaeger for UI.
Here'e our github repo if you want to check it out. https://github.com/signoz/signoz
-
Sentry new TOS to use data to train AI with no opt-out
Using user's private with no opt-out option is unethical.
If anyone is looking self-hosted for alternatives then they should try SigNoz: https://github.com/SigNoz/signoz
-
Top 11 New Relic Alternatives & Competitors
SigNoz is a great New Relic alternative that is open-source and provides three signals in a single pane of glass. You can monitor logs, metrics, and traces and correlate signals for better insights into application performance.
-
Share your DevOps setups
If anyone wants to check the project, here's our github repo - https://github.com/signoz/signoz
-
Amazon EKS Monitoring with OpenTelemetry [Step By Step Guide]
You need a backend to which you can send the collected data for monitoring and visualization. SigNoz is an OpenTelemetry-native APM that is well-suited for visualizing OpenTelemetry data.
-
Spring Boot Monitoring with Open-Source Tools
Once the data is collected, it needs to be sent to a backend. Thatβs where SigNoz comes into the picture. SigNoz is an open-source OpenTelemetry-native APM that provides logs, metrics and traces under a single pane of glass.
What are some alternatives?
opstrace - The Open Source Observability Distribution
skywalking - APM, Application Performance Monitoring System
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
prometheus - The Prometheus monitoring system and time series database.
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
uptrace - Open source APM: OpenTelemetry traces, metrics, and logs
loki - Like Prometheus, but for logs.
jaeger - CNCF Jaeger, a Distributed Tracing Platform
influxdb-apply - Define InfluxDB users and databases with a yaml file.
zipkin - Zipkin is a distributed tracing system
b3-propagation - Repository that describes and sometimes implements B3 propagation
Sentry - Developer-first error tracking and performance monitoring