5 ms·

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,

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. :-|

gouthamve 6y ago
See some more details around the motivations and history here: https://gouthamve.dev/tempo-a-game-of-trade-offs/ 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).
netingle 6y ago
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.
- SEJeff 6y ago
  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.
  - annanay 6y ago
    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.
candiddevmike 6y ago
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.
retzkek 6y ago
> 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?

gouthamve 6y ago

See some more details around the motivations and history here: https://gouthamve.dev/tempo-a-game-of-trade-offs/ 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).

netingle 6y ago

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.

SEJeff 6y ago
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.
- annanay 6y ago
  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.

candiddevmike 6y ago

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.

retzkek 6y ago

> 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?