端口检测成功不代表服务健康？多节点拨测先分清是网络还是服务器
全绿，我写了「服务正常」
一次端口检测全部成功，我在日报里写「服务正常，无异常」。第二天应用报错，翻出报告，发现它只证明了端口能连。
「端口通」和「服务健康」之间，还隔着一整层应用。报告没说服务健康，是我替它说了。那次之后我不再在日报里写「服务正常」。
它证明了什么
三次握手完成，端口有程序监听，链路可达。
就这三件事。换成一句话：这台机器的这个端口，现在愿意接你的连接。
对排查防火墙、安全组、端口开放这些场景，这个结论已经够了。握手只走到连接建立，后面还有请求和响应，都不在里面。
TCP 检测：填域名和端口，多节点看连通与握手耗时
它没证明什么
应用能不能处理请求、返回的内容对不对、用户能不能登录、数据库连接是否正常。
这些它一概不知道。服务可能握手后立刻断开，也可能返回一个错误页，端口后面可能是一个死掉的应用，只剩监听进程。有些服务只在前几次握手正常，后续全部失败，单次检测特别容易漏，连续测才抓得到。
容量、延迟、并发，同样不在它的结论范围内。
报告里该写清什么
第一，探测的范围：哪些节点、哪些运营商、测了哪些端口。
第二，时间：什么时候测的，持续了多久。单次检测只代表那个瞬间。
第三，协议：TCP 还是 UDP。DNS 这类服务两种都用，只测一种说明不了全部。
第四，结论的边界：端口可达，不代表业务可用。用宝塔拨测的 TCP 测速跑出来的结果，也要按这个边界去解读。把这些写进去，报告会变长一点，但更可信，检查项也要列出来，别只写「端口正常」，写清哪个端口、什么协议、哪几个节点。
怎么补齐
用 HTTP 或对应协议再测一层，看状态码和响应内容。
关键业务接口单独加一条检查，带一点内容校验，返回值和预期对得上才算通过。
也可以配多个任务，把端口检查和业务检查分开，告警也分开，端口告警和应用告警的处理人可能不同，分开之后责任更清楚，响应也更快。
复测和表述
连测几次，看端口状态是否稳定。
报告里把「已验证」和「未验证」分开写。已验证的是端口可达，未验证的是应用健康。报告里写清探测时间、节点和样本数，别人才能判断可信度，没有样本数，结论就是玄学。
说清楚这两件事，比给一个漂亮的「正常」更有价值。报告是给决策用的，不是给自己看的，看报告的人才知道还能信到哪一步，这比事后补救便宜得多。
