Currently the grafana cli plugin commands are not reacting to the --config parameter. This PR make it possible to use config to define the plugin endpoints via config as an alternative to providing the --repo flag.
* Simplify proxy dialer creation
- Set new dialer on connector
- Create MSSQL connector in a similar fashion to postgres
* Update test
* Fix lint
* More lint
* Use correct driver name
* Alerting: Consistently return Prometheus-style responses from rules APIs.
This commit is part refactor and part fix. The /rules API occasionally returns
error responses which are inconsistent with other error responses. This fixes
that, and adds a function to map from Prometheus error type and HTTP code.
* Fix integration tests
* Linter happiness
* Make linter more happy
* Fix up one more place returning non-Prometheus responses
* Alerting: Implement SaveAndApplyDefaultConfig in the remote Alertmanager struct
* send the hash of the encrypted configuration
* tests, default config hash in AM struct
* add missing default config to test
* restore build directory
* go work file...
* fix broken test
* remove unnecessary conversion to []byte
* go work again...
* make things work again with latest main branch changes
* update error messages in tests for decrypting config
Preparing these functions to be used by some other part of the codebase,
which does not have a `contextmodel.ReqContext`, only the normal request
structure (`url.Values`, etc). This is slightly messy because of how
Grafana allows url parameters to be in the URL or in the request body,
so we need to make sure to invoke the form parsing logic in `ReqContext`.
* Update @lezer/lr to v1.4.0
* Update @prometheus-io/lezer-promql to v0.37.0
* Update @prometheus-io/lezer-promql to v0.38.0
* Update @prometheus-io/lezer-promql to v0.39.0
* Update @prometheus-io/lezer-promql to v0.40.0
* add jest config
* update code
* fix code to pass "handles things" test
* fix retrieving labels
* fix code to pass "handles label values" test
* fix code to pass "simple binary comparison" test
* use BoolModifier
* add changed lines as comments
* fix for ambiguous query parsing tests
* resolve rebase conflict
* fix retrieving labels, aggregation with/out labels
* add error
* fix comment
* fix "reports error on parenthesis" unit test
* fix for "handles binary operation with vector matchers" test
* fix for "handles multiple binary scalar operations" test
* fix for "parses query without metric" test
* fix indentation and import style
* remove commented lines
* add todo items and comments
* remove dependency update from tempo datasource
* apply same changes in core prometheus frontend
* prettier
* add new test case
* use old version of lezer in the root package.json
* Revert "apply same changes in core prometheus frontend"
This reverts commit 83fd6ac7
* fix indentation
* use latest version of lezer-promql v0.51.2
* Update packages/grafana-prometheus/src/querybuilder/parsing.ts
Co-authored-by: Nick Richmond <5732000+NWRichmond@users.noreply.github.com>
* enable native histogram test
---------
Co-authored-by: Nick Richmond <5732000+NWRichmond@users.noreply.github.com>
* 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
