VictoriaMetrics中vmagent误连Alertmanager集群端口的排查与解决

在VictoriaMetrics监控系统的实际部署中，我们遇到了一个有趣的现象：vmagent组件不断尝试连接Alertmanager的集群通信端口(9094)，导致Alertmanager日志中出现大量"invalid msgType"错误。本文将详细分析这一问题的成因及解决方案。

问题现象

运维人员发现Alertmanager的pod日志中频繁出现以下错误信息：

memberlist: Received invalid msgType (71) from=[fd01:10:100:1b10:4::dadd]:53880

经过排查，这些IP地址均指向vmagent的pod实例。显然，vmagent正在尝试与Alertmanager的集群通信端口建立连接，而该端口使用的是memberlist协议，并非vmagent预期的metrics端点。

根本原因分析

通过对vmagent配置的深入检查，发现问题源于服务发现规则的调整。原本配置中包含一个关键规则：

{
  action: 'keep_if_equal',
  source_labels: [
    '__meta_kubernetes_pod_annotation_prometheus_io_port',
    '__meta_kubernetes_pod_container_port_number',
  ],
}

这条规则的作用是确保只有当Pod注解中指定的端口号与容器实际暴露的端口号匹配时，才会将该目标纳入采集范围。当这条规则被临时移除后，vmagent开始尝试采集所有发现的端口，包括Alertmanager用于集群通信的9094端口。

解决方案

1. 恢复端口匹配规则：重新启用上述过滤规则，确保vmagent只采集明确标注的metrics端口。

2. 显式定义采集目标：对于Alertmanager这类服务，可以在scrape_config中明确指定只采集metrics端口(9093)：

scrape_configs:
  - job_name: 'alertmanager'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_container_port_number]
        action: keep
        regex: 9093

3. 使用注解过滤：利用Kubernetes的标准注解来标识metrics端点：

relabel_configs:
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    action: keep
    regex: "true"
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
    action: keep
    regex: (.+)
    replacement: ${1}
    target_label: __metrics_path__

经验总结

1. 端口过滤的重要性：在Kubernetes环境中，许多服务会暴露多个端口用于不同目的，必须明确区分metrics端口和其他功能端口。

2. 防御性配置：编写scrape_config时应采用"白名单"思维，只允许明确需要的采集目标，而非默认允许所有发现的目标。

3. 日志监控：定期检查各组件的日志，特别是当出现非预期连接时，往往能发现配置问题。

4. 理解协议差异：不同组件使用的协议不同(如memberlist vs HTTP)，了解这些差异有助于快速定位问题。

通过这次事件，我们更加认识到在复杂的监控体系中，精确控制采集目标的重要性。合理的过滤规则不仅能避免无效采集，还能防止对非metrics端点的意外访问，保障整个监控系统的稳定运行。