Linux 服务可用性监控实战：端口、进程、接口怎么监控？

在上一篇《Linux 主机监控实战：CPU、内存、磁盘到底怎么看？》中，我们解决了一个问题：服务器这台"机器"是不是健康的。

在真实运维场景中，你很快就会发现：

机器活着
资源正常
用户却访问不了服务

👉 这正是因为：主机可用 ≠ 服务可用。

这一篇，我们正式进入 服务可用性监控。

一、什么是服务可用性监控？

服务可用性监控，只关心一件事：

👉 这个服务，现在到底还能不能被用？

它不是站在"系统"的角度，而是站在：

用户
调用方
业务系统

的视角来判断。

二、为什么"进程在 ≠ 服务可用"？

很多刚接触运维的同学，判断服务状态的第一反应是：

复制代码

ps -ef | grep nginx

只要看到进程在，就觉得服务没问题。

但现实中，下面的情况非常常见：

进程存在，但端口未监听
进程存在，但监听在 127.0.0.1
进程存在，但线程卡死
进程存在，但接口早已超时

👉 结论：

进程在，只能说明程序没死；

端口通，才说明服务对外；

接口正常，才说明真的可用。

三、第一层：进程监控（服务程序还活着吗？）

1️⃣ 进程监控解决什么问题？

进程监控关注的是：

服务是否崩溃
是否频繁重启
是否资源占用异常

2️⃣ 常用进程监控命令

🔹 ps：查看进程是否存在

复制代码

ps -ef | grep nginx

看是否有主进程 / worker 进程
是否异常消失

🔹 top：观察实时状态

复制代码

top

重点关注：

服务进程 CPU / 内存是否异常
是否长期占用资源

🧠 实战案例：进程监控能发现什么？

**场景：**服务时好时坏。

排查发现：

复制代码

ps -ef | grep java

进程不断退出又被拉起。

👉 说明：应用本身存在异常，而不是系统问题。

四、第二层：端口监控（服务是否对外提供能力）

1️⃣ 为什么端口监控比进程更重要？

在 Linux 中：

一个对外服务 = 一个监听端口

Web → 80 / 443
MySQL → 3306
DNS → 53

👉 端口不通，服务一定不可用。

2️⃣ 常用端口监控命令

🔹 ss（强烈推荐）

复制代码

ss -lntp

参数说明：

-l：监听状态
-n：数字方式显示
-t：TCP
-p：显示进程信息

示例：

复制代码

LISTEN 0 128 0.0.0.0:80

表示 Web 服务正在正常监听。

🔹 netstat（老系统常见）

复制代码

netstat -lntp

🧠 实战案例：端口监控直接定位问题

场景：网页打不开。

复制代码

ss -lntp | grep 80

没有任何输出。

👉 结论：不是网络问题，不是防火墙问题，服务根本没有对外监听。

五、第三层：接口监控（服务真的能用吗？）

1️⃣ 为什么端口通了，服务还是"不可用"？

因为可能存在：

接口返回 500
响应时间极慢
请求直接超时

👉 所以必须做接口级监控。

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

脚本说明

curl：模拟真实用户访问
--connect-timeout：防止卡死
状态码异常 → 直接告警

👉 这正是几乎所有监控系统的底层思想。

八、服务可用性监控在监控体系中的位置

完整监控体系是分层的：

复制代码

主机监控（资源）
   ↓
服务可用性监控（端口 / 探活） ← 本篇
   ↓
应用监控（错误率 / 性能）
   ↓
业务监控（成功率 / 用户体验）

这一层，是：

告警是否有意义的分水岭。

九、写在最后：端口通不通，比服务在不在更重要

很多"无效告警"，根本原因是：

只看进程
不看端口
不做真实探活

而成熟运维一定会先问一句：

现在，端口到底通不通？接口到底能不能用？

💬 互动话题

当你发现服务不可用时，第一步通常会做什么？

看进程
看端口
curl 探接口
直接重启 😅