Recent submissions

Comment · 1 year ago
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.

Links:

- Blog & details: https://uptrace.dev/blog/uptrace-v20.html

- Install guide: https://uptrace.dev/get/hosted/install

- GitHub: https://github.com/uptrace/uptrace

Comment · 3 years ago
Comment · 4 years ago
Echarts which we use supports exporting charts as images so it probably can be added relatively easy. Embedding is another possible option.
Comment · 4 years ago
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.

Comment · 4 years ago
Thanks for the feedback. Any projects that you could recommend that do it right?
Comment · 4 years ago
Comment · 4 years ago
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.

Hopefully that helps.

Comment · 4 years ago
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.

Comment · 4 years ago
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.

Thanks for the comment!

Comment · 4 years ago
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.

Comment · 4 years ago
>the possibility they will be restricted further

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.

None is safe! :)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton