refactor(bloom planner): Compute gaps and build tasks from metas and TSDBs

[salvacorts]

What this PR does / why we need it:
This PR copies logic from the bloom compactor to the new bloom planner component. This is what it does:

1. Every planning_interval:
2. Load all TSDB tables from today() - MaxTableOffset (default 2) to today() - MinTableOffset (default 1). For each:
3. Parse the tenants on each table and for each
4. Check if building blooms is enabled for the tenant
5. Split the FP keyspace into a per-tenant configurable set of bounds
6. Fetch all the metas for the given tenant and find gaps comparing the TSDB against the metas
7. Create a task for each set of gaps within each FP bound

This is the definition of a task:

• Table name
• Tenant ID
• FP Ownership bounds
• TSDB file ID
• List of gaps along with block refs overlapping the gaps

Special notes for your reviewer:

• Most of the logic and tests are copied right away from the bloom compactor implementation.
• This is how I'd review this PR:
  • Skim through the copied files (no changes were made):
    • tsdb.go and tasb_test.go
    • At ultil.go I moved the findGaps function from the compactor controller and renamed to FindGapsInFingerprintBounds. I also copied its test to util_test.go
    • At tableIterator.go I extracted the dayRangeIterator. The code is the same as the one from the compactor.
  • Focus on planner.go.
    • Note that the following functions and their tests were directly copied from the compactor:
      • planner.tables
      • gapsBetweenTSDBsAndMetas
      • blockPlansForGaps
    • So I'd focus on:
      • planner.runOne
      • planner.loadWork
  • Also look at the config and docs generated.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[chaudum]

nit: IMO, 10m is too frequent, it's more frequent than the TSDB index is compacted.

[salvacorts]

I changed it to 8 hours, so it runs three times a day. Wdyt

[chaudum]

Any error would stop the planner service. Is this by intention?

[chaudum]

I would expect an error to be logged and an error counter to be increased, but not the service to be shut down.

[salvacorts]

That looked a bit weird to me as well when I copied it from the bloom compactor:

loki/pkg/bloomcompactor/bloomcompactor.go

Lines 146 to 148 in a9345d0

	if err := c.runOne(ctx); err != nil {
	return err
	}

I'll log the error instead.

error counter to be increased

That's already done inside the runOne function:

loki/pkg/bloombuild/planner/planner.go

Lines 102 to 105 in bb6b3d9

	status = statusFailure
	)
	defer func() {
	p.metrics.buildCompleted.WithLabelValues(status).Inc()

[chaudum]

What is min() used for here with a single argument?

[salvacorts]

I copied over that function. I think that min is probably a leftover. Removed.

[chaudum]

nit: Personally I find the name factor not quite right, because it implies that it is used to multiply with something.
I would name it something with series shard size.

[salvacorts]

I wouldn't use shard since it's not sharding at all. What about bloom_split_series_keyspace_by: 256. I think it reads good enough.

Note that wi'll likely replace this keyspace split by something smarter using TSDB stats soon, so I wouldn't worry too much about naming here.