查看服务器主机状态，核心就一句话：用命令行看实时负载，用日志和监控工具看历史趋势，两条腿走路才能全面掌握机器健康度。
先明确一个概念,服务器主机状态不是单一指标，而是CPU、内存、磁盘、网络、进程、日志的综合表现，新手最容易犯的错是只盯CPU占用率，结果磁盘满了才发现问题，以下内容按权重排序展开，既有可直接操作的命令，也有思路层面的方法论。
先分清两层状态：实时运行和长期趋势
实时状态指的是打开终端那一刻机器在干什么,长期趋势反映的是过去一周甚至一个月内，资源使用率有没有持续走高，日志里有没有周期性报错。
实时状态靠命令行,长期趋势靠监控平台或日志分析，两者缺一不可，只看实时状态，后半夜磁盘悄然写满没人发现；只看监控趋势，突然出现的CPU尖峰又没法定位是哪个进程捣乱。
具体看什么？按优先级排：
- CPU使用率与负载，判断计算资源是否吃紧
- 内存占用和Swap交换情况，排查内存泄漏或不足
- 磁盘空间与I/O读写延迟，避免存储瓶颈拖垮业务
- 网络连接数和带宽占满情况，定位流量异常或攻击
服务器负载过高怎么排查
打开终端先跑 uptime，看最后三个数字，也就是1分钟、5分钟、15分钟的平均负载，行业共识是，负载值除以CPU核数，如果结果持续大于1，说明任务排队了，比如一台4核机器负载长期在4以上，约等于一直在满负荷加班。
但这只是定性判断,接下来用 top 看细节：
- 按 1 看每个核心的使用情况，确认是单核打满还是整体均衡
- 看
us用户态和sy系统态占比，sy长期偏高说明系统调用频繁，可能有锁竞争或上下文切换过多 - 按 P 按CPU占用排序，找到最耗资源的进程
配合 ps -eo pid,ppid,%cpu,cmd --sort=-%cpu | head -20 可以列出CPU占用最高的前20个进程。
定位到进程后,多数情况下有两条路：业务高峰期必然增加，属于合理扩容的范畴；某个进程异常飙升，跑 strace -p 进程号 跟踪系统调用，确认是不是卡在磁盘读写或网络等待上。
linux查看服务器状态命令详解
Linux里看状态没有任何玄学,都是一行行命令拼出来的熟练度，按模块拆开说：
用top和htop看CPU与负载
top 是默认安装的，够用但不直观。htop 支持彩色显示、鼠标操作、树状进程视图，建议第一时间装一个，看的时候重点看顶部的负载均值，以及进程列表里有没有异常占用者。
top 视图里还有个容易忽略的字段是 zombie，僵尸进程占比高说明父进程没正确回收子进程，长期存在可能拖累系统资源释放。
用free和dmesg看内存
free -h 看总量和已用量，关键在 available 这一列，它才代表实际可分配的内存。used 里有一部分是page cache，缓存可以被回收，不算真实消耗。
如果发现Swap被大量使用,返回 dmesg | grep -i oom 查有没有OOM杀进程的记录，内存泄漏的特征是进程的RES值持续上涨，重启后回落，几天后重回高位。
用df和iostat看磁盘
df -h 看分区剩余空间，这属于最基础的检查，真正容易踩坑的是inode耗尽，df -i 看inode使用率，小文件很多的时候空间没满，但inode先满了，新文件写不进去。
I/O层面用 iostat -x 1 看 %util 和 await 两列。%util 接近100%说明磁盘满负荷，await 过高说明响应延迟明显，真实场景里，数据库服务器频繁出现慢查询，往往就是I/O等待时间太长导致的。
用ss和iftop看网络
端口监听状态用 ss -lntp，连接统计用 ss -s，能看到TIME_WAIT数量堆积，配合调整内核参数，属于运维常规操作。
带宽占用用 iftop -i eth0 实时查看，按流量排序找到带宽杀手，公网服务器被恶意扫描时，Connection数会异常走高，ss -t state established | wc -l 可以快速获取当前连接总量。
日志文件是服务器最诚实的自白
跑到命令行看状态只回答“现在怎么样”，日志回答“刚才发生了什么”，排查问题时，状态命令只能告诉你现象，日志里才有根因。
核心日志路径按发行版区分：
- CentOS老版本看
/var/log/messages，Debian/Ubuntu用journalctl
- Nginx日志区分访问日志和错误日志,错误日志里频繁出现
upstream timed out多半是后端处理不过来 - 应用日志看业务代码自身,比如Java应用会把异常栈打印到独立文件，和系统日志互不影响
实操时常用一条命令定位：journalctl --since "30 min ago" --until "10 min ago" -p err，看最近半小时内的错误级别日志，实时追踪用 tail -f /var/log/nginx/error.log，窗口同步观察，改一处配置立刻有反馈。
一次完整的服务器状态体检怎么做
体系化的检查比零散看几个指标更靠谱,推荐按以下顺序，两分钟内完成基础项：
uptime看负载，快速判断整体压力free -h看内存，确认Swap有没有增长df -h和df -i看空间和inodeiostat -x 1 2看磁盘I/Oss -lntp核对监听端口和业务进程tail -n 50 /var/log/messages或者journalctl -n 50扫一眼近期错误
这套流程适合值班时巡检,顺手把结果截个图留档，遇到大促或者版本发布前后，把频率从每天一次提高到每两小时一次。
更进一步,企业服务器状态巡检怎么做才算规范？至少要有基线数据，连续收集两周的资源数据形成基线，之后一旦超出正常波动范围，自动触发告警，没有基线，新来的运维根本判断不了当前状态算正常还是异常。
云服务器和物理服务器监控有啥区别
上云之后,状态查看多了一层维度，物理机直接通过BMC/IPMI看硬件健康，云服务器则通过在控制台提供的监控面板，直接读虚拟化层的指标。
云服务器和物理服务器监控有啥区别，这个问题的核心在于可见性边界：
- 物理服务器可以用
sensors看硬件温度，用smartctl -a /dev/sda看硬盘SMART信息，云服务器没有这些权限 - 云厂商控制台能看到带宽、CPU、内存、磁盘IOPS的月度曲线，物理机需要自己部署历史数据采集
- 云服务器遭遇宿主机邻居的资源争抢时,可能出现CPU steal值偏高，物理机不存在这个问题，
top里的st字段可以观察 - 物理机更依赖机房运维的现场响应,云服务器可以直接在控制台做无重启配置变更
多数情况下,云服务器上推荐优先用云厂商自带监控，原因在于默认采集间隔更短，控制台还能直接查看趋势图，如果业务运行在自建机房，就要走Prometheus加Grafana的路子。
从手动排查到自动监控怎么过渡
手动看命令适合应急,长期稳定运行必须交给监控工具，轻量级方案用 figlet 做命令行展示意义不大，这里推荐一套成熟可行的技术栈：
- Prometheus 负责指标采集和存储，
node_exporter暴露主机指标 - Grafana 负责图形化展示，模板库直接导入Node Exporter Full模板
- Alertmanager 负责告警，配合钉钉或企业微信webhook推消息
这套组合的优势在于,不用写任何业务代码，下载解压就能跑，服务器监控工具有哪些这个问题，除了Prometheus，还有Zabbix、Datadog、云监控等，中小企业选Prometheus的原因很现实：开源免费、社区模板多、适配几乎所有Linux发行版。
搭建完成后,把告警阈值设成三层：警告级别持续5分钟触发，严重级别持续10分钟触发，致命级别持续15分钟触发，避免瞬时抖动就短信轰炸，同时也确保真出大事时不会错过。
Q&A：服务器主机状态怎么看
多久看一次比较合适？
日常业务一天一次排查即可,重点业务建议启用监控告警，以5分钟为采集周期，异常自动推送，省去人工盯屏，物理服务器每季度做一次硬件巡检，包括硬盘SMART信息、内存报错日志和电源状态。
load average多大算异常？
负载等于CPU核数时属于临界值,超过核数说明任务排队，具体到判断尺度，1分钟负载高但15分钟负载低，通常是瞬时任务导致，不必过度反应；15分钟负载持续走高就必须排查，真实案例里，Java应用Full GC频繁会引发CPU飙升，表现就是负载快速升高但CPU并不完全饱和。
磁盘I/O和网络延迟怎么区分？
看业务特征,数据库类应用响应变慢优先检查磁盘I/O的await值，Web服务全球访问变慢优先检查公网带宽和连接数，用 time curl -w 测接口耗时，再结合 iostat -x 1 对比，就能分清瓶颈是存储系统还是网络路径。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/578004.html
