Uptrace is an all-in-one tool that supports distributed tracing, metrics, and logs. It uses OpenTelelemetry observability framework to collect data and ClickHouse database to store it.<p>You can ingest data using OpenTelemetry Protocol (OTLP), Vector Logs, and Zipkin API. You can also use OpenTelemetry Collector to collect Prometheus metrics or receive data from Jaeger, X Ray, Apache, PostgreSQL, MySQL and many more.<p>The latest Uptrace release introduces support for OpenTelemetry Metrics which includes:<p>- User interface to build table-based and grid-based dashboards.<p>- Pre-built dashboard templates for Golang, Redis, PostgreSQL, MySQL, and host metrics.<p>- Metrics monitoring aka alerting rules inspired by Prometheus.<p>- Notifications via email/Slack/PagerDuty using AlertManager integration.<p>There are 2 quick ways to try Uptrace:<p>- Using the Docker container - <a href="https://github.com/uptrace/uptrace/tree/master/example/docker" rel="nofollow">https://github.com/uptrace/uptrace/tree/master/example/docke...</a><p>- Using the public demo - <a href="https://app.uptrace.dev/play" rel="nofollow">https://app.uptrace.dev/play</a><p>I will be happy to answer your questions in the comments.
Nice to see so many new projects in the area of APM in the last few months.<p>We recently tried Signoz and Grafana Tempo and while I can't say something about uptrace yet (will definitely try it out) I want to list some pros and cons about them.<p>Grafana Tempo<p>Pros:<p>- Easy and smooth integration into our existing Grafana instance, no additional frontend needed<p>- No new storage engine needed (No additional Clickhouse, Postgres, etc) as it saves its data to S3<p>- Supports OTLP<p>Cons:<p>- Search is limited by param size and unique params (as its baked to be indexed)<p>- Ingestion is not in real time, but configurable (time to finish span)<p>Signoz:<p>Pros:<p>- Supports OTLP<p>- Integrates Logs and Metrics within the same service (for Grafana you need Loki then)<p>- Supports real time querying<p>Cons:<p>- Uses new storage engines (or extends the software stack) with adding ClickHouse<p>- Adds an additional frontend (might not be relevant for everyone)<p>- Doesn't provide SSO yet, so you need to manage users differently<p>Interesting to see, that UpTrace also chose ClickHouse (btw I love ClickHouse!)<p>Some questions:<p>- Can I easily disable certain features? (e.g. alerting)<p>- Is there support for SSO for self-hosted installation?<p>- Are there any recommendations for scaling (e.g. benchmarks) on how many spans/s are supported on what hardware?<p>Thanks in advance!
You can ingest data using OpenTelemetry Protocol (OTLP), Vector Logs, and Zipkin API. You can also use OpenTelemetry Collector to collect Prometheus metrics or receive data from Jaeger, X Ray, Apache, PostgreSQL, MySQL and many more.<p>The latest Uptrace release introduces support for OpenTelemetry Metrics which includes:<p>- User interface to build table-based and grid-based dashboards.<p>- Pre-built dashboard templates for Golang, Redis, PostgreSQL, MySQL, and host metrics.<p>- Metrics monitoring aka alerting rules inspired by Prometheus.<p>- Notifications via email/Slack/PagerDuty using AlertManager integration.<p>There are 2 quick ways to try Uptrace:<p>- Using the Docker container - <a href="https://github.com/uptrace/uptrace/tree/master/example/docker" rel="nofollow">https://github.com/uptrace/uptrace/tree/master/example/docke...</a><p>- Using the public demo - <a href="https://app.uptrace.dev/play" rel="nofollow">https://app.uptrace.dev/play</a><p>I will be happy to answer your questions in the comments.
I see lots of new tracing options these days, and that seems to have taken over the "APM" term.<p>I still have yet to see new profiling options. When I think of APM, I think of CPU profiling and automatic instrumentation of black box systems, not request tracing. I should be able to see which function calls are slow/problematic, without having to add code to the application.
Before you try, please make sure you are comfortable with their license - <a href="https://github.com/uptrace/uptrace/blob/master/LICENSE" rel="nofollow">https://github.com/uptrace/uptrace/blob/master/LICENSE</a> (Business Source License 1.1), which as License says "The Business Source License (this document, or the “License”) is not an Open Source license"
This seems like a pretty cool project!<p>Currently using Apache Skywalking myself, because it's reasonably simple to get up and running, as well as integrate with some of the more popular stacks: <a href="https://skywalking.apache.org/" rel="nofollow">https://skywalking.apache.org/</a><p>I do wonder how ClickHouse (which Uptrace uses) would compare with something like ElasticSearch (which is used by Skywalking and some others) and how badly/well an attempt to use something like MariaDB/MySQL/PostgreSQL for a similar workload would actually go.<p>I mean, something like Matomo Analytics already uses a traditional RDBMS for storing its data, albeit it might be an order of magnitude or two off from the typical APM solution.
I think the log interface should be optimized for keyboard navigation and larger screens. On my 4k monitor it only takes up 1/2 the width and only shows 10 lines at a time, id expect closer to ~100
I wonder if anyone can answer some question on distributed tracing for me.<p>The difference between old days of APM vs. tracing as I understand is two things.<p>1. Originally APM was single process and it was language aware, usually do sampling stacktrace to find where times are being taken and some very well know place to instrument for exact timing say response time or query time.<p>Tracers are more working by instrumenting methods of framework/servers/runtime at well known point and getting the timing. In man ways it's a lot more coarse as it might know of a hot loop that I have in my code. But it can trace very well with exact timing at framework boundary like web, cache, db etc.<p>2. The APM were primarily single process and couldn't really show a different service/process which doesn't work in a micro-service/distributed world.<p>The way I understand it is that Tracers would allow me to narrow down to the service/component very easily. Whether I can find out why that component is slow might not be as easy (not sure what granularity tracing happens inside a component).<p>I wonder if this understanding of mine is correct.<p>The second thing I am really unsure about is sampling and overhead. What's the usual overhead of a single tracing (I know it's variable) but generally are they more expensive at a single request level. Also do they usually sample and is there a good/recommend way to sample this. I forgot exactly who but (probably NewRelic) was saying they collect all traces (like every request?) and discard if they are not anomalous (to save on storage). But does that mean taking a trace is very cheap? And is that end of the request sampling decision something that's common or that's a totally unique capability some have.
False Advertising!<p>BSL Licensed is not Open Source. To Be fair Utrace restrictions are relatively light but it is still Source Available project not Open Source