From ad40bcb8f947df71486195a3184482f9714807ce Mon Sep 17 00:00:00 2001 From: Jack Baldry Date: Wed, 10 Jul 2024 15:17:29 +0100 Subject: [PATCH] docs: Fix broken link (#13470) --- docs/sources/operations/query-acceleration-blooms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/sources/operations/query-acceleration-blooms.md b/docs/sources/operations/query-acceleration-blooms.md index c7449074c0289..038a625492b26 100644 --- a/docs/sources/operations/query-acceleration-blooms.md +++ b/docs/sources/operations/query-acceleration-blooms.md @@ -196,7 +196,7 @@ Loki will check blooms for any log filtering expression within a query that sati whereas `|~ "f.*oo"` would not be simplifiable. - The filtering expression is a match (`|=`) or regex match (`|~`) filter. We don’t use blooms for not equal (`!=`) or not regex (`!~`) expressions. - For example, `|= "level=error"` would use blooms but `!= "level=error"` would not. -- The filtering expression is placed before a [line format expression](https://grafana.com/docs/loki //query/log_queries/#line-format-expression). +- The filtering expression is placed before a [line format expression](https://grafana.com/docs/loki//query/log_queries/#line-format-expression). - For example, with `|= "level=error" | logfmt | line_format "ERROR {{.err}}" |= "traceID=3ksn8d4jj3"`, the first filter (`|= "level=error"`) will benefit from blooms but the second one (`|= "traceID=3ksn8d4jj3"`) will not. @@ -218,4 +218,4 @@ as well as evenly distributes the amount of chunks each sharded query will need [gateway-cfg]: https://grafana.com/docs/loki//configure/#bloom_gateway [compactor-cfg]: https://grafana.com/docs/loki//configure/#bloom_compactor [microservices]: https://grafana.com/docs/loki//get-started/deployment-modes/#microservices-mode -[ssd]: https://grafana.com/docs/loki//get-started/deployment-modes/#simple-scalable \ No newline at end of file +[ssd]: https://grafana.com/docs/loki//get-started/deployment-modes/#simple-scalable