You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have set up a small Tempo cluster, and it’s running mostly fine.
However, we are getting compactor errors almost every compaction cycle):
googleapi: Error 404: No such object: /single-tenant/<block_id>/meta.json, notFound
The error message (msg field) is sometimes slightly different:
failed to mark block compacted during retention
unable to mark block compacted
failed to clear compacted block during retention
but the inner error (err field) is always the above
Based on what we can find about these errors (#2560, #1270, https://community.grafana.com/t/cannot-find-traceids-in-s3-blocks/45423/10 ), it would appear that the compactor ring is not (correctly) formed.
I have also seen occurrences where 2 nodes where trying to compact the same block, so that checks out.
However, the ring status page looks fine (all three nodes show as active).
The ingester ring has formed and we haven't seen any problems with that.
To Reproduce
I haven't been able to reproduce this in a different environment yet.
We're using Tempo version 2.5.0, with Consul as the kv store, GCS as block storage. We're running 3 nodes in scalable-single-binary mode, on a Nomad cluster.
Our configuration insofar it seems relevant to the issue:
# We run Grafana Tempo in ScalableSingleBinary mode. target: "scalable-single-binary"ingester:
lifecycler:
id: "tempo-ingester@${NOMAD_ALLOC_ID}"ring:
kvstore:
store: "consul"prefix: "tempo/ingesters/"consul:
host: "127.0.0.1:8500"compactor:
ring:
instance_id: "tempo-compactor@${NOMAD_ALLOC_ID}"instance_addr: "0.0.0.0"# The default value is 60s, but we want to be able to restart Tempo a bit quicker.wait_stability_min_duration: "10s"kvstore:
store: "consul"prefix: "tempo/compactors/"consul:
host: "127.0.0.1:8500"storage:
trace:
backend: "gcs"gcs:
bucket_name: "<some bucket>"
TBH, I'm a bit lost. I'm now wondering about the address that the compactors are advertising in the ring instance_addr: "0.0.0.0", that might be messing up something.
I have also seen occurrences where 2 nodes where trying to compact the same block, so that checks out.
Describe the bug
We have set up a small Tempo cluster, and it’s running mostly fine.
However, we are getting compactor errors almost every compaction cycle):
The error message (
msg
field) is sometimes slightly different:but the inner error (
err
field) is always the aboveBased on what we can find about these errors (#2560, #1270, https://community.grafana.com/t/cannot-find-traceids-in-s3-blocks/45423/10 ), it would appear that the compactor ring is not (correctly) formed.
I have also seen occurrences where 2 nodes where trying to compact the same block, so that checks out.
However, the ring status page looks fine (all three nodes show as active).
The ingester ring has formed and we haven't seen any problems with that.
To Reproduce
I haven't been able to reproduce this in a different environment yet.
We're using Tempo version 2.5.0, with Consul as the kv store, GCS as block storage. We're running 3 nodes in scalable-single-binary mode, on a Nomad cluster.
Expected behavior
No compaction errors
Environment:
Additional Context
Our configuration insofar it seems relevant to the issue:
The compaction summary looks fine to me:
The text was updated successfully, but these errors were encountered: