Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: f41gh7 <nik@victoriametrics.com>
4.0 KiB
weight | title | menu | aliases | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
4 | VMAlertmanagerConfig |
|
|
The VMAlertmanagerConfig
provides way to configure VMAlertmanager
configuration with CRD. It allows to define different configuration parts, which will be merged by operator into config.
It behaves like other config parts - VMServiceScrape
and etc.
Read Usage and Special case before using.
Specification
You can see the full actual specification of the VMAlertmanagerConfig
resource in
the API docs -> VMAlertmanagerConfig.
Also, you can check out the examples section.
Validation
The operator performs validation of VMAlertmanagerConfig
. In case of any misconfiguration it adds corresponding validation fail message into status.lastSyncError
field and updates status.status
field to failed
status.
For example VMAlertmanagerConfig
without required fields:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlertmanagerConfig
metadata:
name: invalid-config
namespace: default
spec:
receivers:
- name: blackhole
- name: pagerduty
pagerduty_configs:
- url: http://example
route:
group_by:
- alertname
receiver: blackhole
routes:
- matchers:
- alertname="pd"
receiver: pagerduty
status:
lastErrorParentAlertmanagerName: default/example-alertmanager
lastSyncError: 'receiver at idx=2 is invalid: at idx=0 pagerduty_configs one of
''routing_key'' or ''service_key'' must be configured'
lastSyncErrorTimestamp: 1722950290
status: failed
Usage
VMAlertmanagerConfig
allows delegating notification configuration to the kubernetes cluster users.
The application owner may configure notifications by defining it at VMAlertmanagerConfig
.
With the combination of VMRule
and VMServiceScrape
it allows delegating configuration observability to application owners, and uses popular GitOps
practice.
Operator combines VMAlertmanagerConfig
s into a single configuration file for VMAlertmanager
.
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlertmanagerConfig
metadata:
name: example-email-web
namespace: production
spec:
route:
receiver: email
group_interval: 1m
routes:
- receiver: email
matchers:
- {severity =~ "warning|critical", app_name = "blog"}
receivers:
- name: email
email_configs:
- to: some-email@example.com
from: alerting@example.com
smarthost: example.com:25
text: ALARM
Special Case
VMAlertmanagerConfig has enforced namespace matcher. Alerts must have a proper namespace label, with the same value as name of namespace for VMAlertmanagerConfig.
It can be disabled, by setting the following value to the VMAlertmanager: spec.disableNamespaceMatcher: true
.
Examples
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlertmanagerConfig
metadata:
name: example
namespace: default
spec:
inhibit_rules:
- equals: []
target_matchers: []
source_matchers: []
route:
routes:
- receiver: webhook
continue: true
receiver: email
group_by: []
continue: false
matchers:
- job = "alertmanager"
group_wait: 30s
group_interval: 45s
repeat_interval: 1h
mute_time_intervals:
- name: base
time_intervals:
- times:
- start_time: ""
end_time: ""
weekdays: []
days_of_month: []
months: []
years: []
receivers:
email_configs: []
webhook_configs:
- url: http://some-other-wh
pagerduty_configs: []
pushover_configs: []
slack_configs: []
opsgenie_configs: []
victorops_configs: []
wechat_configs: []