Windows
macOS
Android
iOS
节点可用性监控的核心，不是简单判断服务器是否在线，而是确认用户能否通过实际路径获得预期服务。以部署在 Kubernetes 集群中的 Nginx 服务为例，节点可能仍处于运行状态，但 DNS 配置、证书、反向代理规则或业务流程中的任一环节出现异常，用户仍会看到访问失败。
因此，较稳妥的做法是组合多种探测方式。下面将五种常见方法放在同一框架内比较，重点关注检测对象、执行步骤、优缺点和故障定位价值。
一、DNS 解析监控：先确认入口是否指向正确位置
DNS 解析监控适合发现域名无法解析、记录异常、解析链路不一致等问题。它检查的是“入口能否找到目标”，并不代表目标服务已经正常响应。
执行步骤
- 从指定探针向权威 DNS 或递归 DNS 发起 A、AAAA、CNAME 等查询。
- 记录返回状态、解析结果、TTL 以及不同网络位置的差异。
- 将结果与预期地址集合比对，发现 NXDOMAIN、超时或返回错误地址时进入告警流程。
这种节点可用性监控成本较低，适合域名迁移、容灾切换和多地域解析场景。缺点是只能说明名称解析是否正常，无法证明 Nginx 已监听请求，也不能判断应用内容是否正确。若只有部分地区异常，应分别保留各探针原始结果，不宜直接合并成一个平均值。
二、TCP 建连监控：判断服务端口是否愿意接受连接
TCP 探测比 DNS 更接近实际服务入口，适用于检查 SSH、SMTP、数据库代理或自定义服务等端口是否可以完成连接建立。它关注网络路径和监听状态，但不会验证应用层返回内容。
执行步骤
- 选择目标主机名、地址和端口，设置连接超时时间。
- 从至少两个网络位置执行建连测试，记录成功、拒绝、超时和重置等结果。
- 将连接失败与主机防火墙、负载均衡监听器及服务进程状态逐层对照。
TCP 方法的优势是响应快、实现简单，能够区分“端口未监听”和“网络路径不可达”。局限在于端口接受连接后，应用可能已经卡死或返回错误数据。因此，TCP 适合作为节点可用性监控的基础层，不宜单独承担业务可用性判断。
三、TLS 握手监控：检查加密连接能否真正建立
对于使用 HTTPS、API 网关或邮件加密通道的服务，仅确认端口开放还不够。TLS 监控可以发现证书过期、域名不匹配、协议版本不兼容以及证书链不完整等问题。
执行步骤
- 使用生产域名发起 TLS 握手，避免只用地址测试而跳过主机名校验。
- 校验证书有效期、主题名称、SAN 字段和证书链。
- 记录握手耗时、协商出的协议版本及失败原因，并设置提前提醒。
该方法特别适合证书由人工续期、跨系统部署或存在多个入口的环境。它能把“端口可连接但浏览器报安全错误”快速分离出来。缺点是无法证明后端接口或页面业务正常，证书校验也可能受探针系统时间和信任库版本影响。
四、HTTP 内容校验：从返回结果判断应用是否工作
HTTP 监控不应只看状态码。代理层、缓存层或错误页面都可能返回 200，因此更可靠的节点可用性监控需要同时检查状态码、响应头、响应长度范围和关键文本。
执行步骤
- 选择一个稳定且无副作用的只读 URL，例如版本信息页或公开配置接口。
- 设定允许的状态码、响应时间上限和必要字段。
- 对响应内容进行固定字段、JSON 类型或版本号校验，异常时保存请求链路和响应摘要。
HTTP 内容校验的定位能力明显高于单纯端口测试，可识别 Nginx 正常但上游应用报错、缓存未更新或路由配置错误等情况。缺点是需要维护校验规则；如果把易变的时间戳、随机编号写进规则，容易产生误报。
五、业务流程模拟：验证用户能否完成关键动作
业务流程模拟是最接近用户体验的方法，例如打开登录页、提交测试账号、读取个人设置，再安全退出。它验证的不只是节点，而是前端、网关、认证服务和会话存储之间能否协同工作。
执行步骤
- 选取低风险、可重复的流程，使用专用测试账号和隔离数据。
- 依次执行页面加载、表单提交、结果校验和退出操作。
- 为每一步记录耗时、失败截图或响应摘要，并区分登录失败、接口失败和页面渲染失败。
这种方法能够发现普通 HTTP 检查看不到的问题，例如按钮可见但提交接口失败、认证成功后会话丢失或前端资源加载不全。代价是维护复杂度和执行时间最高，还可能因测试账号过期、验证码或第三方依赖而误报，因此应与基础探测分层配置。
五种方法如何选择
| 方法 | 主要发现的问题 | 定位速度 | 主要局限 |
|---|---|---|---|
| DNS 解析 | 域名、记录和解析链路异常 | 快 | 无法证明服务已响应 |
| TCP 建连 | 端口关闭、防火墙和网络路径问题 | 快 | 不检查应用内容 |
| TLS 握手 | 证书、协议和加密协商问题 | 较快 | 不代表业务流程正常 |
| HTTP 内容 | 网关、接口和返回内容异常 | 中等 | 规则需要持续维护 |
| 业务流程 | 跨服务链路和真实操作失败 | 较慢 | 成本高且依赖测试数据 |
实际部署时，可以把 DNS、TCP 和 TLS 作为基础层，把 HTTP 内容校验作为服务层，再用少量业务流程作为体验层。告警策略应包含失败次数、恢复条件、探针位置和错误类型；例如同一探针短暂失败时先进入观察状态，多地点持续失败后再升级，通常比单次失败立即通知更稳妥。
常见问题
1. 五种方法是否必须全部部署？
不必。小型服务可先使用 TCP 加 HTTP 内容校验；涉及证书和复杂登录流程时，再增加 TLS 与业务流程模拟。
2. 为什么端口正常，用户仍然无法访问？
端口正常只说明连接层可达，DNS、TLS、反向代理、应用响应或前端资源仍可能异常。
3. 多个探针结果不一致时怎么办？
先按地区、运营商和协议分别查看原始结果，再检查解析差异、路由路径和入口配置，不要直接用平均值掩盖局部故障。
4. 业务流程监控适合所有页面吗？
不适合。优先选择稳定、低风险且可重复的关键流程，避免对下单、支付或数据写入操作造成真实影响。
合理的节点可用性监控应从网络入口逐步深入到加密层、应用层和业务层。通过分层探测与明确的告警策略，团队可以更快判断故障究竟发生在解析、连接、证书、服务响应还是用户操作环节。
