监控的第一步不是安装 Prometheus，而是先知道一个 Linux 系统和其中的服务究竟应该观察什么。
本文从 Linux 主机和服务本身出发，介绍进程、systemd、CPU、内存、磁盘、网络、负载、文件描述符等基础监控指标，并建立一套基础的服务故障定位方法。
一、Linux 服务监控概述
1.1 什么是服务监控
在 Linux 服务器上运行着大量服务：
NginxMySQLRedisDockerSSHKubernetesJava Application...服务出现问题时，可能表现为：
进程消失端口关闭请求超时CPU 过高内存不足磁盘写满网络异常因此监控并不是单纯地：
“这个进程还在不在？”而是需要同时观察：
服务状态进程状态CPUMemoryDiskNetworkLoadConnectionLogs可以简单抽象成：
Linux Server │ ┌─────────────────┼─────────────────┐ │ │ │ ▼ ▼ ▼ Service Resource Network │ │ │ │ ┌──────┼──────┐ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ systemd CPU Memory Disk Socket │ ▼ Process1.2 监控与故障排查
监控和故障排查并不是一回事。
监控更关注：
“现在是否正常？”“最近有没有异常？”“趋势是否发生变化？”故障排查则关注：
“为什么异常？”例如：
CPU = 95%这是一个监控结果。
接下来还需要排查：
哪个进程占用 CPU？为什么占用？是不是流量增加？是不是程序死循环？是不是频繁 GC？是不是磁盘 I/O 等待？因此：
监控→ 发现问题
排查→ 定位原因
处理→ 恢复服务
复盘→ 找出长期改进方案二、Linux 服务与 systemd
2.1 服务是什么
Linux 中的“服务”通常是长期运行、为其他程序或用户提供功能的进程。
例如：
sshdnginxredis-servermysqlddocker现代 Linux 发行版中，很多系统服务由 systemd 管理。
systemd 官方文档： systemd
2.2 systemctl
最常用的服务管理命令：
systemctl status nginx启动：
sudo systemctl start nginx停止：
sudo systemctl stop nginx重启：
sudo systemctl restart nginx重新加载配置：
sudo systemctl reload nginx设置开机启动：
sudo systemctl enable nginx取消开机启动：
sudo systemctl disable nginx查看是否设置了开机启动：
systemctl is-enabled nginx查看当前是否运行：
systemctl is-active nginx2.3 service 与 process 的区别
需要注意：
Service≠Process例如：
systemctl status nginx描述的是 systemd 管理的服务单元。
而：
ps aux | grep nginx查看的是实际进程。
可以理解为：
systemd │ ▼Service Unit │ ▼Process因此遇到服务故障时，通常需要同时查看：
systemctl+process三、服务健康状态
3.1 Active / Inactive / Failed
查看：
systemctl status nginx常见状态包括：
activeinactivefailed其中：
active→ 服务当前处于活动状态
inactive→ 当前没有运行
failed→ 启动或运行过程中发生失败但：
active≠业务一定正常例如：
Nginx Process │ ▼systemd = active但：
后端服务不可用最终用户仍然可能：
HTTP 502所以更完整的健康判断应该是：
Service │ ├── Process ├── Port ├── Dependency └── Application Response3.2 自动重启
systemd 可以配置服务失败后的自动重启，例如：
[Service]Restart=on-failureRestartSec=5这样：
Process ↓Crash ↓systemd ↓Restart可以提高服务的自恢复能力。
但需要注意：
自动重启≠问题已经解决如果服务不断：
启动 ↓崩溃 ↓启动 ↓崩溃可能会形成持续重启。
因此还需要观察：
systemctl status nginxjournalctl -u nginx四、进程监控
4.1 ps
最基础的进程查看工具：
ps aux查看指定进程：
ps aux | grep nginx更适合查看完整进程关系：
ps -ef例如：
root 100 1 ...nginx 200 100 ...nginx 201 100 ...可以帮助分析：
PIDPPIDUserCPUMemoryCommand4.2 top
实时查看系统和进程：
top可以看到：
CPUMemoryLoad AverageProcesses以及各进程：
PIDUSER%CPU%MEMTIMECOMMAND这是 Linux 服务故障排查中非常常用的工具。
4.3 htop
如果系统安装了 htop：
htop它提供更加直观的交互式进程查看界面。
不过运维环境中仍然应该掌握：
top因为它更加常见且通常预装。
4.4 pstree
查看进程树：
pstree例如：
systemd ├─ sshd │ └─ sshd │ └─ bash │ └─ nginx ├─ nginx └─ nginx当服务存在：
父进程子进程workerdaemon等关系时，进程树非常有帮助。
五、CPU 监控
CPU 是最常见的系统资源之一。
5.1 CPU 使用率
例如：
CPU = 95%首先需要确定：
UserSystemI/O WaitIdle这些 CPU 时间的来源不同。
例如：
User 高→ 用户态程序计算较多
System 高→ 内核态工作较多
I/O Wait 高→ CPU 正在等待 I/O 完成
Idle 高→ CPU 大量空闲因此：
CPU 高不能直接等价于：
应用有 bug5.2 top 查看 CPU
运行：
top可以看到类似：
%Cpu(s): 20.0 us, 5.0 sy, 0.0 ni, 70.0 id, 5.0 wa可以重点关注：
ussywaid5.3 mpstat
安装 sysstat 后可以使用：
mpstat查看更细粒度的 CPU 统计：
mpstat -P ALL 1其中：
-P ALL表示查看所有 CPU。
这在多核服务器上尤其有用，因为：
整体 CPU 不高并不意味着：
所有核心都正常例如：
CPU 0 = 100%CPU 1 = 10%CPU 2 = 8%CPU 3 = 9%也可能造成某些单线程应用性能问题。
六、内存监控
6.1 free
查看内存：
free -h例如：
total used free shared buff/cacheMem: 16G 10G 1G ... 5GSwap: 2G 500M 1.5G现代 Linux 中：
used并不能简单理解成：
“程序真正占满的内存”因为 Linux 会利用空闲内存作为：
Page CacheBuffers提高 I/O 性能。
因此更重要的是关注：
available而不是只盯着：
free6.2 Swap
查看：
free -h如果发现：
Swap持续增长，需要进一步检查内存压力。
可能原因：
应用内存泄漏进程占用过高系统内存不足缓存压力不过：
Swap 使用≠系统一定有故障关键是观察：
是否持续增长是否产生大量 I/O应用延迟是否受到影响6.3 vmstat
vmstat 可以同时观察：
ProcessMemorySwapI/OSystemCPU例如：
vmstat 1非常适合判断系统整体资源状态。
七、磁盘与文件系统监控
7.1 df
查看文件系统空间：
df -h典型问题：
/100%这时应用可能出现：
日志无法写入数据库无法写入临时文件创建失败服务异常7.2 inode
除了磁盘容量，还需要关注 inode：
df -i因为文件系统同时存在：
空间+inode例如：
磁盘还有 50GB但如果：
inode = 100%仍然可能无法创建新文件。
常见原因：
大量小文件日志文件缓存文件临时文件7.3 du
查看具体目录占用：
du -sh /var/log/*或者：
du -xh /var | sort -h可以帮助定位：
到底哪个目录占满了磁盘7.4 磁盘 I/O
磁盘空间正常：
df -h→ 正常并不意味着：
磁盘性能正常还需要观察 I/O。
例如：
iostat或：
iostat -xz 1可以查看：
IOPS吞吐量awaitutil这有助于判断：
CPU 问题还是磁盘 I/O 问题八、网络监控
8.1 网卡状态
查看：
ip link查看地址：
ip addr检查：
interfacestateIP8.2 路由
查看：
ip route重点关注：
default route以及目标网段是否存在对应路由。
8.3 监听端口
使用：
ss -lntp例如：
LISTEN0.0.0.0:800.0.0.0:22127.0.0.1:6379可以判断：
服务有没有监听监听在哪个地址监听哪个端口这在排查：
“服务已经启动，但是访问不了”时非常重要。
8.4 网络连接
查看 TCP 连接：
ss -ant统计：
ESTABLISHEDTIME-WAITCLOSE-WAITLISTEN例如：
CLOSE-WAIT大量增加时，可以进一步检查：
应用是否正确关闭连接上游是否异常连接是否泄漏九、系统负载 Load Average
9.1 Load Average 是什么
可以通过：
uptime或者：
top看到：
load average: 1.20, 0.80, 0.60分别代表：
1 分钟5 分钟15 分钟需要注意：
Load Average 不是简单的“CPU 使用率”。
它反映的是系统中处于可运行状态以及不可中断睡眠状态等任务的整体压力情况。
因此：
Load 高可能来自：
CPU 压力I/O 压力而不是只有 CPU。
9.2 Load 与 CPU 核数
例如：
1 核 CPULoad = 4压力通常比较明显。
而：
8 核 CPULoad = 4并不能简单理解为“系统已经 4 倍超载”。
因此判断负载时要结合：
CPU 核数CPU 使用率I/O Wait系统响应时间综合分析。
十、文件描述符与系统资源
Linux 中很多服务不仅消耗：
CPUMemoryDisk还可能受到：
File Descriptor限制。
10.1 文件描述符
查看当前 Shell 限制：
ulimit -n查看进程打开的文件：
lsof -p <PID>或者：
ls /proc/<PID>/fd | wc -l网络连接也会占用文件描述符。
因此：
连接数暴增可能最终表现为：
Too many open files10.2 系统级限制
查看：
cat /proc/sys/fs/file-max以及：
cat /proc/sys/fs/file-nr如果应用出现：
无法建立连接无法打开文件Too many open files就需要同时检查：
进程限制系统限制应用连接管理十一、日志与 systemd Journal
基础服务监控至少要能够查看本机服务日志；集中式日志系统则在此基础上统一保存和检索。
11.1 journalctl
查看系统日志：
journalctl查看指定服务：
journalctl -u nginx持续跟踪：
journalctl -u nginx -f查看最近日志：
journalctl -u nginx --since "1 hour ago"查看本次启动以来的日志：
journalctl -b11.2 为什么日志是监控的一部分
假设：
systemctl status nginx显示：
active但用户访问失败。
继续：
ss -lntp发现：
80 端口正常再：
curl http://127.0.0.1发现：
502 Bad Gateway这时候真正的原因可能存在于：
nginx error log或者：
backend journal因此：
Metrics→ 告诉你“异常了”
Logs→ 帮助你解释“为什么异常”指标和日志系统可以在此基础上扩展统一采集与告警。
十二、服务监控中的关键指标
不同服务需要观察的指标不同，但可以建立一套基础框架。
12.1 主机级指标
CPUMemoryLoadDisk UsageDisk I/ONetworkProcess CountFile Descriptors12.2 服务级指标
Service StatusProcessPortConnectionsResponse TimeError RateRestart Count12.3 应用级指标
不同应用还可能关注：
QPSTPSLatencyError RateQueue LengthCache Hit Rate例如 Redis：
MemoryConnectionsCommandsHit RateEvictionsLatencyMySQL：
ConnectionsQPSTPSSlow QueriesBuffer PoolLocksReplicationNginx：
RequestsStatus CodesResponse TimeConnectionsTraffic因此：
“监控服务器”并不意味着所有服务器都监控同一组指标。
真正有效的监控应该围绕：
服务的工作方式来设计。
十三、服务监控的基本层次
可以把 Linux 服务监控分成几个层次：
Service Monitoring │ ┌────────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ Availability Resource Performance │ │ │ 服务是否运行 CPU/Memory Latency 端口是否监听 Disk/Network QPS 是否能访问 FD Error Rate进一步：
Availability→ 有没有活着
Resource→ 有没有资源压力
Performance→ 活着的时候是否正常工作这是后续学习 Prometheus 非常重要的基础。
十四、一个实际的 Linux 服务监控示例
假设服务器运行：
NginxJava ApplicationRedisPostgreSQL可以建立如下监控思路：
Linux Server │ ┌───────────────┼────────────────┐ │ │ │ Nginx Java Redis │ │ │ Port 80 Port 8080 Port 6379 │ │ │ └────────────────┼────────────────┘ │ PostgreSQL 5432主机层：
CPUMemoryDiskNetworkLoad服务层：
Nginx → HTTPJava → HTTPRedis → TCPPostgreSQL → TCP于是：
服务器 CPU 正常 ↓Nginx 正常 ↓Java 正常 ↓Redis 正常 ↓PostgreSQL 正常用户最终得到的才是：
业务正常这说明：
单个服务正常，并不能证明整个业务正常；主机正常，也不能证明业务正常。
十五、Linux 服务故障排查流程
假设用户反馈：
网站打不开不要直接重启服务器。
可以按照：
网站打不开 │ ▼ 服务是否运行？ │ systemctl │ ▼ 进程是否存在？ │ ▼ 端口是否监听？ │ ▼ 网络是否正常？ │ ▼ 本机 curl 是否正常？ │ ▼ 查看日志 │ ▼ 检查 CPU / Memory │ ▼ 检查磁盘 │ ▼ 检查依赖具体可以依次执行：
systemctl status nginx
ps -ef | grep nginx
ss -lntp | grep :80
curl -I http://127.0.0.1
journalctl -u nginx --since "30 min ago"
free -h
df -h
top如果 Nginx 本身正常：
Nginx ↓Backend ↓Database ↓Redis继续检查后端依赖。
十六、几个典型故障案例
16.1 CPU 持续 100%
现象：
CPU = 100%Load ↑排查：
top找到高 CPU 进程：
PID 1234CPU 300%java进一步：
top -H -p 1234查看线程。
接下来再结合：
应用日志GC请求量线程状态定位原因。
所以：
CPU 高→ 只是症状不能直接：
kill -916.2 磁盘满
现象：
df -h/100%继续：
du -xh /var | sort -h发现：
/var/log非常大。
继续检查：
哪个日志为什么没有轮转是否存在异常日志刷屏正确处理应该是：
找到原因 ↓合理清理 / 轮转 ↓恢复磁盘空间 ↓修复日志配置而不是简单：
rm -rf /var/log/*16.3 服务 active 但访问失败
例如：
systemctl status nginx结果：
active但是：
curl http://127.0.0.1返回：
502 Bad Gateway这时说明：
Nginx Process→ 正常
Nginx HTTP→ 正常响应
Backend→ 可能异常继续：
Nginx ↓upstream ↓Backend排查后端。
16.4 内存持续下降
现象：
available memory持续下降需要观察：
进程 RSSPage CacheSwapOOM如果某一个应用：
RSS 持续增长就需要进一步考虑：
内存泄漏缓存无限增长连接累积对象无法释放如果出现：
OOM Killer则需要检查：
dmesg或：
journalctl -k查看内核日志。
十七、监控数据的三个维度
后续学习 Prometheus 和 Grafana 前，需要先建立一个非常重要的概念：
状态趋势异常17.1 当前状态
例如：
CPU = 30%Memory = 45%Disk = 60%回答：
现在怎么样？17.2 趋势
例如：
Disk Usage
60%61%63%66%70%75%...虽然今天：
75%不一定是故障。
但趋势告诉我们：
磁盘正在持续增长可能很快产生问题。
17.3 异常
例如：
平时 QPS = 1000
突然：QPS = 10000或者：
平时 CPU = 30%
突然：CPU = 95%这才是：
Anomaly因此真正的监控系统不仅要：
采集数据还需要：
判断告警可视化趋势分析这些内容就是下一篇 Prometheus 与 Grafana 的核心。
十八、从 Linux 本机监控到 Prometheus
到这里，Linux 自带工具已经能够观察大量基础数据：
systemdpstopfreevmstatdfduiostatssjournalctl但它们的问题是：
只能人工执行例如：
top只能告诉你：
“现在 CPU 是多少”如果希望：
每 15 秒采集保存 30 天生成图表超过阈值自动告警就需要专门的监控系统。
于是进入：
Linux │ ├── Metrics ├── Logs └── Status │ ▼ Monitoring System │ ▼ Prometheus │ ▼ Grafana下一篇可以进一步解决：
数据怎么采集？指标怎么定义？Prometheus 怎么存？怎么查询？Grafana 怎么画？怎么告警？而日志体系则继续拆开：
Logs ↓Log Collection ↓ELK / Elastic Stack再往后：
MetricsLogsTraces ↓OpenTelemetry ↓完整可观测性体系十九、总结
Linux 服务监控可以先建立这样一套思维框架：
Linux Service │ ┌────────────┼────────────┐ ▼ ▼ ▼ Availability Resource Performance │ │ │ Service CPU Latency Process Memory QPS Port Disk Error Health Network │ ▼ Logs │ ▼ Root Cause日常排查最常用的基础工具可以归纳为：
systemctl→ 服务状态
ps / top→ 进程与 CPU
free / vmstat→ 内存与系统状态
df / du / iostat→ 磁盘与 I/O
ip / ss→ 网络
journalctl→ 服务与系统日志最终形成：
发现异常 ↓确认服务 ↓检查进程 ↓检查资源 ↓检查网络 ↓检查日志 ↓检查依赖 ↓定位原因这套基础能力是后面的：
PrometheusGrafanaELKOpenTelemetry可观测性的基础。
监控系统解决的是“持续观察系统”，而 Linux 基础工具解决的是“理解系统当前发生了什么”。在真正使用 Prometheus 之前，先掌握后者，才能看懂监控数据背后的含义。