docs: Update docs for structured metadata blooms #14555
Conversation
The bloom compactor component has been removed in favor of the bloom planner/builder/gateway, none of which use hash rings.
Replace references to bloom compactor with the new bloom planner and bloom builder components.
github-actions
bot
added
the
type/docs
Update the Query Acceleration with Blooms topic to reference structured metadata blooms over the removed line blooms. Documentation on how to configure bloom components has been temporarily removed while the architecture is still under active changes.
rfratto
force-pushed
the
docs-structured-metadata-blooms
branch
from
6c94ad6
to
0117f2b
Compare
| The reason is that bloom filters also come with a relatively high cost for both building | ||
| and querying the bloom filters that only pays off at large scale deployments. | ||
| {{< /admonition >}} | ||
| ## Adding data to blooms |
There was a problem hiding this comment.
I re-read the live content and it does seem correct to me; maybe I misunderstood what the team was saying we should do to the docs.
cc @chaudum Should I keep the content for the bloom components? Or was there a reason we wanted to remove it in the short term?
There was a problem hiding this comment.
Unless Blooms are enabled by default now, we should keep the content about how to enable it.
There was a problem hiding this comment.
@JStickler I brought back the old content, with some changes to make it accurate (some of it was outdated after all).
I also divided the document into a using/operating section, since the most important content for us at the moment is how to guide users to use query acceleration in Grafana Cloud.
rfratto
force-pushed
the
docs-structured-metadata-blooms
branch
from
a8acc16
to
4561c6f
Compare
| statistical confidence that the string might be present. | ||
| The underlying blooms are built by the [Bloom Builder](#bloom-planner-and-builder) component | ||
| and served by the new [Bloom Gateway](#bloom-gateway) component. | ||
| ### Query blooms |
There was a problem hiding this comment.
I would put the query section AFTER the section about how to enable blooms.
There was a problem hiding this comment.
Hm, can we discuss options here?
It's likely that there are going to be many more people going to this page who aren't Loki operators but need to know the rules for using blooms, like a cloud user or someone on a team that uses Loki but does not operate it themselves. I'm concerned that moving information for how to take advantage of blooms after all the operator content would hurt discoverability.
Do you think that's a risk? Would there be another way to organize the content?
There was a problem hiding this comment.
Well, you can't really query blooms if they're not enabled yet....
Also I don't think this topic has so many headings that the secondary TOC (on the right) that the query section would be hidden if you don't scroll.
There was a problem hiding this comment.
Right, but the audience using blooms and the audience managing advantage of blooms are sometimes distinct. How can we educate people on how to write queries which take advantage of the enabled blooms without forcing them to scan through information about how to enable them?
Or is this problem not worth solving?
(For example: if I was a Grafana Cloud user, only the information about sending structured metadata and how to write queries to use blooms is relevant to me)
There was a problem hiding this comment.
Maybe we need to split the information out about querying blooms and put it in a topic under Query instead?
Co-authored-by: J Stickler <[email protected]>
What this PR does / why we need it:
Documentation for how to configure the new bloom components has been temporarily removed as we are still actively making changes to the architecture.
Which issue(s) this PR fixes:
Closes #14414
Special notes for your reviewer:
Checklist
CONTRIBUTING.mdguide (required)featPRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.docs/sources/setup/upgrade/_index.mddeprecated-config.yamlanddeleted-config.yamlfiles respectively in thetools/deprecated-config-checkerdirectory. Example PR