mirror of
https://github.com/grafana/grafana.git
synced 2025-02-25 18:55:37 -06:00
* Alerting: Optimize rule status gathering APIs when a limit is applied. The frontend very commonly calls the `/rules` API with `limit_alerts=16`. When there are a very large number of alert instances present, this API is quite slow to respond, and profiling suggests that a big part of the problem is sorting the alerts by importance, in order to select the first 16. This changes the application of the limit to use a more efficient heap-based top-k algorithm. This maintains a slice of only the highest ranked items whilst iterating the full set of alert instances, which substantially reduces the number of comparisons needed. This is particularly effective, as the `AlertsByImportance` comparison is quite complex. I've included a benchmark to compare the new TopK function to the existing Sort/limit strategy. It shows that for small limits, the new approach is much faster, especially at high numbers of alerts, e.g. 100K alerts / limit 16: 1.91s vs 0.02s (-99%) For situations where there is no effective limit, sorting is marginally faster, therefore in the API implementation, if there is either a) no limit or b) no effective limit, then we just sort the alerts as before. There is also a space overhead using a heap which would matter for large limits. * Remove commented test cases * Make linter happy |
||
---|---|---|
.. | ||
api | ||
apimachinery | ||
apis | ||
apiserver | ||
build | ||
bus | ||
cmd | ||
codegen | ||
components | ||
events | ||
expr | ||
extensions | ||
generated | ||
ifaces/gcsifaces | ||
infra | ||
kinds | ||
login/social | ||
middleware | ||
mocks/mock_gcsifaces | ||
models | ||
modules | ||
plugins | ||
promlib | ||
registry | ||
server | ||
services | ||
setting | ||
tests | ||
tsdb | ||
util | ||
web | ||
README.md | ||
ruleguard.rules.go |
This directory contains the code for the Grafana backend.
The contributor documentation for Grafana's backend is in /contribute/backend/README.md.