PrometheusAlertmanager连接被拒，端口占用排查指南

Alertmanager 报“connection refused”错误常被误认为端口被占用，实则根本原因在于服务未成功响应连接请求——可能是进程根本未启动、监听地址配置为127.0.0.1导致外部不可达、网络策略或防火墙拦截、配置文件语法错误引发静默崩溃，甚至系统资源耗尽；本文系统梳理五大排查维度，从进程状态、监听配置、网络连通性、配置校验到系统限制，帮你精准定位真因，快速恢复告警通路，避免在“端口占用”的误区中徒劳折腾。

如果您在 Prometheus 部署中观察到 Alertmanager 报出 connection refused 错误，例如 dial tcp 127.0.0.1:9093: connect: connection refused，该错误**并不直接表明端口被占用**，而是明确指示客户端尝试连接 Alertmanager 的监听地址（默认 9093）时，**目标服务未响应连接请求**。常见原因包括 Alertmanager 进程未启动、监听地址配置错误、网络隔离或防火墙拦截，而非端口处于“已绑定但拒绝连接”的占用状态。

一、验证 Alertmanager 进程是否实际运行

该步骤用于确认 Alertmanager 是否处于活动状态。若进程不存在，则连接必然失败，与端口是否被其他程序占用无关。

1、执行命令检查 Alertmanager 进程是否存在：ps aux | grep alertmanager。

2、若输出中无 alertmanager 主进程（非仅 grep 自身），说明服务未启动。

3、若进程存在，继续检查其监听端口是否为预期值：lsof -i :9093 或 netstat -tulnp | grep :9093。

4、若命令返回空结果，表明 Alertmanager 虽运行，但未在 9093 端口监听——需检查其启动参数或配置文件中的 --web.listen-address 值。

二、检查 Alertmanager 启动参数与监听地址配置

Alertmanager 默认监听 0.0.0.0:9093，但若显式指定为 127.0.0.1:9093 或其他受限地址，Prometheus 或其他组件从外部 IP 访问时将触发 connection refused。

1、查看 Alertmanager 启动命令或 systemd service 文件，定位 --web.listen-address 参数值。

2、若该值为 127.0.0.1:9093，则仅允许本地回环访问；Prometheus 若运行于不同容器或主机，必须改为 0.0.0.0:9093 或对应网卡 IP。

3、修改后重启 Alertmanager：systemctl restart alertmanager 或重新运行二进制命令。

4、再次执行 lsof -i :9093，确认监听地址已更新为通配或目标接口。

三、排查 Prometheus 到 Alertmanager 的网络连通性

当 Alertmanager 运行且监听正确地址后，仍报 connection refused，说明中间存在网络层阻断，如防火墙、SELinux、Kubernetes NetworkPolicy 或 Pod 网络路由异常。

1、若在 Kubernetes 中，进入 Prometheus Pod 执行：telnet alertmanager-operated 9093（或使用 nc -zv alertmanager-operated 9093）。

2、若连接失败，检查 Service 是否存在且 Endpoints 正常：kubectl get endpoints -n monitoring alertmanager-operated。

3、若 Endpoints 为空，说明 Alertmanager Pod 未就绪或标签选择器不匹配；检查 Pod 状态：kubectl get pod -n monitoring -l app.kubernetes.io/name=alertmanager。

4、若 Pod 处于 CrashLoopBackOff，需进一步查看日志：kubectl logs -n monitoring alertmanager-main-0 -c alertmanager。

四、确认 Alertmanager 配置文件语法与模板有效性

Alertmanager 启动失败时可能静默退出，导致端口未监听。典型诱因是配置文件（alertmanager.yaml）或引用的告警模板（如 wechat.tmpl）存在语法错误，使进程无法完成初始化。

1、手动验证配置文件是否可解析：./alertmanager --config.file=alertmanager.yaml --test.config。

2、若报错指向某行模板文件（如 template: wechat.tmpl:7: unclosed action），说明该模板存在未闭合的 {{ }} 或语法错误。

3、临时注释掉 alertmanager.yaml 中的 templates 字段或整个模板路径，再次运行测试命令。

4、若测试通过，逐个恢复模板并验证，定位具体损坏文件并修复语法。

五、检查系统级限制与资源状态

极端情况下，内核连接数限制、OOM Killer 终止进程或磁盘满导致 Alertmanager 启动失败，均会表现为 connection refused。

1、检查系统日志中是否有 Alertmanager 被强制终止记录：dmesg -T | grep -i "killed process" | grep alertmanager。

2、检查根分区及 Alertmanager 数据目录磁盘使用率：df -h 和 df -h /var/lib/alertmanager。

3、检查当前打开文件数限制是否过低：cat /proc/$(pgrep alertmanager)/limits | grep "Max open files"；若 soft limit 小于 4096，需调整 systemd service 的 LimitNOFILE。

4、若发现 OOM 或磁盘满，清理资源后重启服务。

今天关于《PrometheusAlertmanager连接被拒，端口占用排查指南》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！