Hacker News Reader

Comment by strofcon | Hacker News Reader

I'm hopeful that with it effectively being a KV store pointed at a "simple" object store (S3, GCS, etc), it will be dramatically simpler to manage than Jaeger, and much more performant.

Backing Jaeger with Elasticsearch or Cassandra was a nightmare. :-|

View on HN

See some more details around the motivations and history here: https://gouthamve.dev/tempo-a-game-of-trade-offs/

It will be easier and cheaper to manage compared to Jaeger but doesn't yet have any ability to search inbuilt (which is one of the reasons Jaeger is expensive).

That’s our motivation and experience over the last 6 months running it internally at Grafana Labs. Much cheaper and easier to operate.

Not to bash Jaeger though, its more powerful than tempo in that it allows you to search for traces. Tempo is about integrating with Grafana, Loki and Prometheus for finding traces.

So if you're not running Loki, you're not going to be able to find traces using tempo? We use grafana and prom, but not loki.

Since Tempo is a k/v store that can retrieve traces given a traceID, we need either a metric system that can store traceIDs in exemplars OR any logging framework to log traceIDs that can be copied over to the Tempo Query UI.

Jaeger has a local storage option (badger) that is OK for "ephemeral" tracing. I use it for development environments and in production (where each app can have it's own Jaeger instance). The data gets wiped periodically, prometheus metrics are used for trending.

> Backing Jaeger with Elasticsearch or Cassandra was a nightmare.

Unless you're already running one of these, in which case deploying Jaeger is very easy (at least, that was my experience with our Elasticsearch backend).

> much more performant.

You expect an object store to be more performant than Elasticsearch?

Reply on news.ycombinator.com