在上一篇《Linux 主机监控实战：CPU、内存、磁盘到底怎么看？》中，我们解决了一个问题：服务器这台“机器”是不是健康的。
但在真实运维场景中，你很快就会发现：
👉 这正是因为：主机可用 ≠ 服务可用。
这一篇，我们正式进入 服务可用性监控。
一、什么是服务可用性监控？
服务可用性监控，只关心一件事：
👉 这个服务，现在到底还能不能被用？
它不是站在“系统”的角度，而是站在：
的视角来判断。
二、为什么“进程在 ≠ 服务可用”？
很多刚接触运维的同学，判断服务状态的第一反应是：
ps -ef | grep nginx
只要看到进程在，就觉得服务没问题。
但现实中，下面的情况非常常见：
👉 结论：
进程在，只能说明程序没死；
端口通，才说明服务对外；
接口正常，才说明真的可用。
三、第一层：进程监控（服务程序还活着吗？）
1️⃣ 进程监控解决什么问题？
进程监控关注的是：
2️⃣ 常用进程监控命令
🔹 ps：查看进程是否存在
ps -ef | grep nginx
🔹 top：观察实时状态
top
重点关注：
🧠 实战案例：进程监控能发现什么？
场景：服务时好时坏。
排查发现：
ps -ef | grep java
进程不断退出又被拉起。
👉 说明：应用本身存在异常，而不是系统问题。
四、第二层：端口监控（服务是否对外提供能力）
1️⃣ 为什么端口监控比进程更重要？
在 Linux 中：
一个对外服务 = 一个监听端口
👉 端口不通，服务一定不可用。
2️⃣ 常用端口监控命令
🔹 ss（强烈推荐）
ss -lntp
参数说明：
示例：
LISTEN 0 128 0.0.0.0:80
表示 Web 服务正在正常监听。
🔹 netstat（老系统常见）
netstat -lntp
🧠 实战案例：端口监控直接定位问题
场景： 网页打不开。
ss -lntp | grep 80
没有任何输出。
👉 结论： 不是网络问题，不是防火墙问题，服务根本没有对外监听。
五、第三层：接口监控（服务真的能用吗？）
1️⃣ 为什么端口通了，服务还是“不可用”？
因为可能存在：
👉 所以必须做接口级监控。
2️⃣ 常用接口监控命令
🔹 curl：最重要的工具
curl -I http://127.0.0.1
返回：
HTTP/1.1 200 OK
说明接口可以正常响应。
🔹 监控接口响应时间
curl -o /dev/null -s -w "time:%{time_total}\n" http://127.0.0.1
用于判断：
🧠 实战案例：接口监控发现性能问题
场景： 用户反馈“能打开，但很慢”。
curl -o /dev/null -s -w "time:%{time_total}\n" http://service
响应时间 6 秒。
👉 结论： 服务没挂，但已经不可用（性能故障）。
六、健康检查的本质是什么？
很多系统、负载均衡、监控平台都有一个概念：
Health Check（健康检查）
它的本质其实非常简单：
模拟一次最小可用请求，验证服务是否能正常响应
健康检查 不是功能测试，而是确认：
七、Shell + curl：一个完整的服务监控示例
下面是一个极简但非常经典的服务可用性监控脚本。
示例：Web 服务可用性监控
#!/bin/bash
URL="http://127.0.0.1"
TIMEOUT=3
# 使用 curl 访问服务，获取 HTTP 状态码
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout $TIMEOUT$URL)
# 判断服务状态
if [ "$HTTP_CODE" -eq 200 ]; then
echo"Web 服务正常，状态码：$HTTP_CODE"
else
echo"Web 服务异常，状态码：$HTTP_CODE"
fi
脚本说明
👉 这正是几乎所有监控系统的底层思想。
八、服务可用性监控在监控体系中的位置
完整监控体系是分层的：
主机监控（资源）
↓
服务可用性监控（端口 / 探活） ← 本篇
↓
应用监控（错误率 / 性能）
↓
业务监控（成功率 / 用户体验）
这一层，是：
告警是否有意义的分水岭。
九、写在最后：端口通不通，比服务在不在更重要
很多“无效告警”，根本原因是：
而成熟运维一定会先问一句：
现在，端口到底通不通？接口到底能不能用？
💬 互动话题
当你发现服务不可用时， 第一步通常会做什么？
欢迎在评论区分享你的真实习惯 👇
