Annanay Agarwal

No, not a new torrent for every commit. But, we need to be able to tell the torrent tracker that a new node is available for peer. As @cjb said,...

Hi @zolstein, thanks for looking into this. The visualisation is that of a trace exported from an instrumented application (https://github.com/grafana/tempo). `parquet.backendBlock.FindTraceByID` (the top line in the trace view) is a...

+1 improving performance on the read path will be very useful for us as well. From some profiles we can see that ~60-70% of CPU on our compactors is spent...

Hi @zhzure; thanks for filing this issue. Tempo releases come with a linux amd64 binary, you can find the latest one here - https://github.com/grafana/tempo/releases/tag/v1.4.1 - under the "Assets" section. I...

This smells like a bug on the Zipkin receiver, where we are not passing our authentication middleware to the zipkin server, but I will have to investigate further to confirm.

Also for our documentation, `multitenancy_enabled` is probably a better name for that config label, rather than `auth_enabled`.

Update after some preliminary digging - - Middleware authentication is not passed down to any receiver from the vendored collector - As of now, we are able to extract tenant...

> @annanay25 please remember to clean up this example when you get rid of Jaeger query. 👍 I will make sure. This work will start in coordination with the Grafana...

> good first issue Oops I already added this in the `vParquet/compactor` - https://github.com/grafana/tempo/pull/1479/commits/bc53205dbf433524449db110230f12e8b8f7bf97 Looks something like this now ``` caller=compactor.go:118 msg="error during compaction cycle" err="error iterating input blocks: error...

Hi @alburthoffman, thanks for opening this issue. Yes, we are aware and working on compaction improvements to ensure the blocklist length remains as low as possible. For now, the solution...