Kube-Prometheus Stack中AlertManager配置及Teams告警问题咨询

方向确认 #

你的整体思路是正确的：通过ConfigMap挂载自定义AlertManager配置、配置路由和Webhook接收器对接Teams，是kube-prometheus-stack中自定义AlertManager告警行为的标准实现方式，问题出在配置细节的匹配上。

问题排查与修复步骤 #

1. 修正配置文件名匹配 #

当前配置存在文件名后缀不一致的核心问题：

• ConfigMap中定义的配置文件key是alertmanager.yml（.yml后缀）
• AlertManager启动参数中指定的路径是/etc/alertmanager/alertmanager.yaml（.yaml后缀）

AlertManager会严格按照指定路径查找文件，这直接导致它无法找到目标配置文件。二选一修正即可：

方案A：修改启动参数匹配ConfigMap文件名

调整alertmanagerSpec的args配置，同时必须保留AlertManager默认的存储路径参数：

alertmanager:
  alertmanagerSpec:
    image:
      repository: {{ .Values.spec.monitoring.images.altermanager.repository }}
      tag: {{ .Values.spec.monitoring.images.altermanager.tag }}
    args:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager' # 不可省略，这是AlertManager默认存储目录参数
    volumeMounts:
    - name: config-volume-alertmanager
      mountPath: /etc/alertmanager
    tolerations:
    - key: "monitoring"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
    volumes:
    - name: config-volume-alertmanager
      configMap:
        name: alertmanager

方案B：修改ConfigMap的文件key匹配启动参数

调整ConfigMap的data部分，将配置文件后缀改为.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager
  namespace: {{ .Values.shared.global.namespace }}
data:
  alertmanager.yaml: |- # 将原key从alertmanager.yml改为alertmanager.yaml
    global:
      resolve_timeout: 5m
      route:
        group_wait: 30s
        group_interval: 10s
        repeat_interval: 10s
        receiver: app-prometheus-msteams
        routes:
          - match:
              alertname: Watchdog
            receiver: 'app-prometheus-msteams'
      receivers:
      - name: 'null'
      - name: app-prometheus-msteams
        webhook_configs: 
        - send_resolved: true
          url: {{ .Values.shared.global.alertmanager.webhook }}

2. 优化挂载方式（可选但更安全） #

直接将ConfigMap挂载到/etc/alertmanager会覆盖整个目录的原有内容，建议采用子路径挂载仅替换目标配置文件，避免意外破坏原有文件：

volumeMounts:
- name: config-volume-alertmanager
  mountPath: /etc/alertmanager/alertmanager.yml # 直接挂载到具体文件路径
  subPath: alertmanager.yml # 对应ConfigMap中的文件key

3. 验证配置文件语法正确性 #

AlertManager会拒绝加载有语法错误的配置，可使用amtool工具本地验证：

# 将ConfigMap中的配置内容保存到本地文件（如local-alert.yml）
amtool check-config local-alert.yml

若输出SUCCESS: local-alert.yml is valid configuration file则说明语法无误。

4. 触发配置生效 #

• 确认ArgoCD应用已完成同步，修改后的配置已推送到集群
• 手动重启AlertManager Pod强制加载新配置：

kubectl rollout restart statefulset alertmanager-kube-prometheus-stack-alertmanager -n {{ .Values.shared.global.namespace }}

5. 验证配置加载状态 #

查看AlertManager Pod启动日志，确认配置文件成功加载：

kubectl logs <alertmanager-pod-name> -n {{ .Values.shared.global.namespace }} | grep "Loading configuration file"

若看到类似level=info ts=xxxxxx caller=main.go:xxxxx msg="Loading configuration file" file=/etc/alertmanager/alertmanager.yml的日志，说明配置已生效。

内容的提问来源于stack exchange，提问作者Mahnoor Fatima