* Alerting: Add expression type to webhook valueString
- Add Type field to NumberValueCapture struct
- Implement AlertQuery.GetExpressionType() method
- Update valueString format to include type information
* Alerting: Add expression type to webhook valueString
- Fix tests
* Alerting: Add expression type to webhook valueString
- Update default annotations in notifier templates to include type field
* Alerting: Add expression type to webhook valueString
- Add type='math' to webhook and email test expectations
* update alerting module
* replace compat with ones from alerting
* update type references Receiver and Integration to *Status
* update route in provisioning test that is invalid after recent change
* use right type for LINE ingtegration
* update tests to assert against snapshot
* remove channel_config package replaced by schemas from alerting module
* update references to use new schema
* generate schema for mimir integrations from schema on front-end
* review and fix the settings
* Update GetAvailableNotifiersV2 to return mimir as v0
* add version argument to GetSecretKeysForContactPointType
* update TestGetSecretKeysForContactPointType to include v0
* add type alias field to contain alternate types that different from Grafana's
* add support for msteamsv2
* update ConfigForIntegrationType to look for alternate type
* update IntegrationConfigFromType to use new result of ConfigForIntegrationType
* add reference to parent plugin to NotifierPluginVersion to allow getting plugin type by it's alias
* add tests to ensure consistency
* make API response stable
* add tests against snapshot + omit optional fields
Rules created in the new api makes the rule have no group in the database, but the rule is returned in the old group api with a sentinel group name formatted with the rule uid for compatiblity with the old api.
This makes the UI continue to work with the rules without a group, and the ruler will continue to work with the rules without a group.
Rules are not allowed to be created in the provisioning api with a NoGroup sentinel mask, but NoGroup rules can be manipulated through both the new and old apis.
Co-authored-by: William Wernert <william.wernert@grafana.com>
* Replace remaining calls to testing.Short where possible.
* Update style guide.
* Revert change in TestAlertmanager_ExtraDedupStage, as it doesn't work.
* Make TestAlertRulePostExport into integration test.
* Add better type handling when correlation is created from provisioning and fix documentation
* add external example
* change error when deprecated key is used
* Add config provider and integrate with wire setup
* Refactor quota service to use config provider for configuration management
* Enhance OSSConfigProvider to include logging and update ProvideService to return an error. Refactor server initialization to handle potential errors from config provider. Remove unnecessary wire binding for OSSConfigProvider.
* Update CODEOWNERS to include the configprovider package under the grafana-backend-services-squad.
* Refactor quota service initialization to include context in multiple service providers. Update tests and service implementations to ensure proper context handling during service creation.
* Alerting: Move some tests to full integration tests
* add back two error handling tests
* imports
---------
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* WIP
* Update yarn.lock
* Align uuid dependency
* Add e2e test and update
* Update cue version
* Fix lint
* Update snapshot test
* Fix test that was importing from coupled module
* Fix lint
* Update public/app/plugins/datasource/loki/package.json
Co-authored-by: Zoltán Bedi <zoltan.bedi@gmail.com>
---------
Co-authored-by: Zoltán Bedi <zoltan.bedi@gmail.com>
What is this feature?
Implements the POST endpoint for deleting imported Mimir Alertmanager configurations:
POST /api/convert/api/v1/alerts
The API endpoint creates the extra Alertmanager configuration with the provided identifier and matchers.
* declare dingding url as secret
patch raw settings before parsing because DingDing's config parser does not know about secrets
* fix integration test
---------
Co-authored-by: Yuri Tseretyan <yuriy.tseretyan@grafana.com>
What is this feature?
Fixes a bug when group-level query_offset and labels parameters are ignored and not saved
Why do we need this feature?
In the import API Prometheus YAML rule definitions are supported:
groups:
- name: group-1
interval: 1m
query_offset: 10m
labels:
severity: "warning"
rules:
- alert: Alert 0 > 0
expr: vector(0) > 0
But applying group-level labels and query_offset is broken and they are not saved right now because during the conversion of the API model to PrometheusRuleGroup they aren't saved to the new structure.
