We’ve just released Uptrace v2.0, a major re-architecture of our open-source observability platform (traces, logs, metrics).
This release focuses on performance and scalability:
- 5–10x faster queries using ClickHouse’s new JSON column type (nested fields can be queried directly with dot-notation, no ETL or flattening required)
- Multi-project support – manage projects, users, and orgs via UI or YAML seed files
- Real-time data transformations (rename, filter, enrich spans/logs, sample dynamically) using an [Expr-based](https://github.com/expr-lang/expr) scripting system
- Redesigned dashboards and query builder for faster incident response and exploration
- Handles massive traces (10k–1M spans) with tunable resource limits
It’s still open-source and free to self-host. We’ve published migration guides, Ansible and Kubernetes deploy instructions, and full [release details](https://uptrace.dev/blog/uptrace-v20.html).
Would love feedback from the HN crowd — especially from folks scaling ClickHouse or building custom observability pipelines.
Uptrace is an open-source APM tool that supports distributed tracing, metrics, and logs. You can use it to monitor applications and set up alerts to receive notifications via email, Slack, Telegram, and more.
In v1.4 release Uptrace got built-in alerting capabilities that allow to monitor metrics, manage alerts, and receive notifications without using AlertManager. But AlertManager is still supported.
While OpenTelemetry remains to be the main source of telemetry data, Uptrace also provides integrations for Prometheus metrics, Vector logs, FluentBit, Sentry, and CloudWatch.
Hi there, Right now Uptrace seems to be supporting only Clickhouse sink only. Is there any future roadmap to support other Exporters supported on OpenTelemetry ?
I use memory profiling with Go and it is indeed very useful. I think that whatever Go already provides is enough, but I guess Uptrace could try to automate some things and/or provide some fancy UI.
But I find CPU profiling a lot less useful, because production profiles tend to be too broad and it is hard to make sense from them, for example, Uptrace profile mostly consists of memory allocations and network calls.
So I would not say that CPU profiling is superior/better/can replace tracing.
When compared with ElasticSearch, ClickHouse can handle the same amount data using 10x less resources and that is not an exaggeration. It is even worse with MariaDB/MySQL/PostgreSQL.
I guess ElasticSearch is still relevant when it comes to searching text, but ClickHouse is much faster when it comes to filtering and analyzing the data.
Give ClickHouse a try and you won't be disappointed.
My understanding is that APM became or always was a marketing term which is used rather freely. For that reason I try to avoid it, but search engines love it and I don't know a better alternative.
>Whether I can find out why that component is slow might not be as easy (not sure what granularity tracing happens inside a component).
It is true that you can't always guess what operation going to be slow and instrument it, but it is almost always a network or a database call. There is still no way to tell *why* it is slow, but the more data you have the more hints you get.
>What's the usual overhead of a single tracing
Depending on what is your base comparison point the answer can be very different.
Usually, you trace or instrument network/filesystem/database calls and in those cases the overhead is negligible (few percents at most).
>But does that mean taking a trace is very cheap?
What you've described is tail-based sampling and it only helps with reducing storage requirements. It does not reduce the sampling overhead. Check https://uptrace.dev/opentelemetry/sampling.html
But is taking a trace cheap? Definitely. Billions of traces? Not so.
>request sampling decision something that's common or that's a totally unique capability some have.
It is a common practice to reduce cost of sampling when you have billions of traces, but it is an advanced feature because it requires backends to buffer incoming spans in memory so you can decide if the trace is anomalous or not.
Besides, you can't store only anomalous traces because you will lose a lot of useful details and you can't really detect anomaly without knowing what is the norm.
By traditional APM I primarily meant stacktrace sampling based monitoring of applications.
As for overhead of tracing I wanted roughly compare (obviously it depends on the application a lot) stacktrace sampling vs. tracing based one. Are they usually of similar overhead or say tracing is lighter?
I was thinking tail based sampling could be a lot more expensive because say a head based sampling is doing trace for 10% request whereas regardless of how many sample are kept a tail based one is dong 100% trace. So tracing overhead would be much higher right?
I'm not sure why head based sampling is being called accurate in your doc? Isn't it the least accurate in a sense that it's purely statistical and rare outlier like latency spike or error could be missed?
And yes obviously a tail based sampling has to be something like (trace 5% random request or 1 every five + any outlier that gets calculated based on the captured trace)/
It is the same license used by MariaDB, Sentry, CockroachDB, Couchbase and many others. Technically it is not open source and instead is called source available, but you can enjoy pretty much the same benefits.
Out of curiosity, what makes you uncomfortable about the license?
Er, MariaDB is GPL2, and will forever be since it is derived from MySQL.
I'm guessing they aligned the license terms on those of ClickHouse, which is the underlying data store for Uptrace. From my understanding, if you use Uptrace and ClickHouse to manage your internal telemetry and don't offer it to clients, you should be fine. Still, non-standard license terms give pause, as there is always the possibility they will be restricted further in a bait-and-switch operation like that done by MongoDB or ElasticSearch.
It is true for all licenses, for example, it is possible to keep old code available under old permissive license but release all new code under a more restricted license.
This not correct. There's a difference between OSS projects with shared copyright (every individual contributor holds the copyright to their contributions) and oss projects where the copyright is required to be transferred to some company.
In the second case, this company then holds the copyright to the entire source tree and can re-license it at will. Mongo and Elastic did this and they are good examples of why you should not transfer copyright because they then have the right to re-license your contributions as they please. That's the reason they insist on copyright transfers. They reserve the right to change the license on future versions of the software. You can still use the old versions under the license that applied at the time.
So, Opensearch is a fork of the last Apache 2.0 licensed version of Elasticsearch. Versions after that are licensed under a non OSS license whereas Opensearch is a proper open source project where copyright belongs to individual contributors, which ironically is still mostly Elastic plus whatever individual opensearch contributors added.
Most projects don't insist on copyright transfers however and given enough external contributors it becomes increasingly hard for them to get permission to change he license.
Regardless of the license, there is absolutely zero chance of something like mysql, linux, or other long existing OSS projects ever being re-licensed because it would require tracing down tens of thousands of copyright holders (or their surviving relatives) to get permission for that most of whom would probably not be willing to do that. This is so impractical that it will never happen. And even if it happened, anyone could continue using and contributing under the old license. All you'd have is a fork that is cut off from those contributions (because licenses like Gpl v2 don't allow mixing with proprietary code). So given a permission you will never get, you'd have a fork that is effectively yours of an original source tree that still belongs to all the original contributors and is licensed under the original license.
OSS done properly builds communities that exist for as long as people continue to be willing to use and contribute to the software. Some OSS projects are now decades old.
I am not a lawyer so I can't keep up the discussion on the necessary level so I will just clarify few things.
Uptrace uses the BSL license to forbid or rather not allow other companies creating a cloud service using Uptrace code, because that is how we are planning to monetize. But you can self-host Uptrace and use it as you want to monitor your (production) application. I think this is fair enough.
I am sure there are many complications with re-licensing, but it happens in practice, for example, Sentry now uses BSL license. And you can't do anything about it except to fork old Sentry. But then you will have to maintain it yourself.
And I am not arguing with anything you've said, but there are not that many financially thriving truly OSS projects. That's why people like me have to complicate their lives with BSL, AGPL, and others.
> Technically it is not open source and instead is called source available, but you can enjoy pretty much the same benefits.
Since you already aware about it, could you update the OP from open source to source available, for the sake of transparency? If edit option is not available, you can request mods / dang
> Out of curiosity, what makes you uncomfortable about the license?
I can't speak for the OP, but my view is that all these semi-open (AGPL,BSL etc.) licenses do is muddy the waters. Its essentially giving the developer's lawyers enough grey area to work with in order to find something they can pin you on.
IMHO a company's code should either be closed source or open source. Wishy-washy no-mans-land wordings in the middle don't really help anyone (except the lawyer's bank balance, of course).
Uptrace uses the BSL license to forbid or rather not allow other companies creating a cloud service using Uptrace code, because that is how we are planning to monetize. But you can self-host Uptrace and use it as you want to monitor your (production) application. I think this is fair enough.
If there is another license that better reflects our intentions, let us know.
You can self-host Uptrace and use it in production environment. This is explicitly stated in the FAQ - https://github.com/uptrace/uptrace#faq . But you can't resell Uptrace to others.
I can only repeat that the same BSL license is used by MariaDB, Sentry, CockroachDB, Couchbase, and others. I am not a lawyer and thus not qualified to discuss details.
DataDog has a high learning curve and can be rather expensive if you need to monitor a lot of hosts and microservices.
Uptrace tries hard to stay simple while providing almost the same set of features. It can also be self-hosted without paying anything which can save a lot of money.
Uptrace aims to be an open source alternative to DataDog, but realistically we are not there yet.
This release focuses on performance and scalability:
- 5–10x faster queries using ClickHouse’s new JSON column type (nested fields can be queried directly with dot-notation, no ETL or flattening required)
- Multi-project support – manage projects, users, and orgs via UI or YAML seed files
- Real-time data transformations (rename, filter, enrich spans/logs, sample dynamically) using an [Expr-based](https://github.com/expr-lang/expr) scripting system
- Redesigned dashboards and query builder for faster incident response and exploration
- Handles massive traces (10k–1M spans) with tunable resource limits
It’s still open-source and free to self-host. We’ve published migration guides, Ansible and Kubernetes deploy instructions, and full [release details](https://uptrace.dev/blog/uptrace-v20.html).
Would love feedback from the HN crowd — especially from folks scaling ClickHouse or building custom observability pipelines.
Links:
- Blog & details: https://uptrace.dev/blog/uptrace-v20.html
- Install guide: https://uptrace.dev/get/hosted/install
- GitHub: https://github.com/uptrace/uptrace