查看Linux服务器运行时间，核心答案就一条：执行uptime命令即可，它一行输出就能告诉你这台机器从上次开机到现在已经跑了多久，想更精确或换个角度，还有/proc/uptime、who -b、last reboot几条路可走。
uptime 命令：一行输出里藏着五个信息
逐字段拆开看
在终端敲下uptime，典型输出长这样：
15:32:07 up 128 days, 3:41, 2 users, load average: 0.08, 0.03, 0.01从左往右读,每一段都有明确含义：
15:32:07：当前系统时间up 128 days, 3:41：这就是运行时间，128天3小时41分钟2 users：当前登录的用户会话数，不是用户账号数load average：1、5、15分钟的平均负载
如果你只想看运行时间,uptime -p会输出更口语化的结果，比如up 18 weeks, 2 days, 3 hours, 41 minutes；uptime -s则直接给出开机时刻，形如2026-09-01 08:12:33。
为什么很多人第一次看会读错
最常见的误读是把2 users当成”有2个人在用服务器”，它统计的是登录会话（tty、pts），一个人开三个SSH窗口就会显示3，另一个误读是盯着load average不放那是负载，跟运行时间没有因果关系，别混着理解。
想要秒级精度，去 /proc/uptime 拿原始数据
uptime的输出经过格式化，天生带着”天、时、分”的粗粒度，要精确数字，直接读内核暴露的虚拟文件：
cat /proc/uptime # 11059200.37 41952.18
第一个数字是系统已运行的秒数，第二个是所有CPU核心空闲时间的累计秒数，这个值是单调递增的，不受系统时间被NTP校正的影响，脚本里做判断时比解析uptime的文本可靠得多。
想把秒数换算成开机时刻,一行命令搞定：
date -d "@$(( $(date +%s) - $(cut -d. -f1 /proc/uptime) ))"
who -b 与 last reboot：确认开机的那一瞬间
两条命令给出的是”时刻”而不是”时长”：
who -b：直接输出system boot 2026-09-01 08:12，简单直接last reboot | head -n 5：从wtmp日志里翻出最近几次重启记录，能看到重启原因（比如shutdown还是crash）
who -b依赖wtmp日志，日志被轮转或清理后可能为空；/proc/uptime是内核实时数据，不存在这个问题，排查”机器到底重启过没有”时，两条路交叉验证最稳妥。
ps 看1号进程：换个角度验证
ps -p 1 -o lstart=
输出的是init（或systemd）进程的启动时间，正常情况下它跟who -b一致；如果不一致，说明1号进程被重启过而系统没有这在容器环境里很常见。
uptime命令和top命令看运行时间有什么区别
这是被问得最多的一类问题,直接给结论：两者读的是同一个数据源，区别只在展示目的。
| 维度 | uptime |
top |
|---|---|---|
| 运行时间位置 | 第一行完整输出 | 顶部第一行，压缩显示 |
| 主要用途 | 快速确认开机时长、负载 | 实时观察进程资源占用 |
| 是否交互 | 一次性输出，执行完退出 | 持续刷新，需按q退出 |
| 输出体量 | 一行 | 满屏进程列表 |
| 适合场景 | 快速巡检、写进脚本 | 现场排障、盯CPU和内存 |
top顶部那行up 128 days，跟uptime的算法完全一样，业内专家指出，把top当”看运行时间的工具”是典型的工具误用它真正的价值在下面的进程列表。
什么场景该用哪个
- 只想确认”这台机器多久没重启了”：
uptime - 要同时看负载趋势：
uptime，信息够用且干净 - 怀疑某个进程吃满CPU：
top或htop - 写进监控脚本、需要结构化数据：读
/proc/uptime
简米云服务器怎么查看运行时间
云服务器本质上还是Linux,命令完全通用，差别在于你有两条路可以走。
命令行：和物理机没有任何区别
SSH登录后直接uptime，输出格式一模一样，这是最快的方式，也是运维日常最常用的。
控制台：实例详情页里的启动时间
登录云厂商控制台,进入实例列表，点开具体实例，基本信息里通常有”启动时间”或”创建时间”字段。注意区分这两个概念：创建时间是你买下这台实例的时刻，启动时间才是本次开机的时刻，实例做过重启、迁移、变更配置后，启动时间会刷新，创建时间不变。
云环境下的两个特殊点
- 实例迁移或宿主机维护可能导致实例重启，
last reboot里能看到记录，但控制台不一定有明显的通知 - 部分云厂商提供实例监控里的”运行时长”指标，可以配合告警使用，比自己写脚本省事
如何查看服务器开机了多久，并把运行时间用起来
看到”up 300 days”就放心了？这个判断本身有风险。
运行时间长不等于系统健康
行业共识认为,长时间不重启对Linux来说通常不是问题，内核稳定性足够支撑数百天连续运行，但运行时间长会掩盖另一类问题：
- 内核补丁、安全更新在等待重启生效
- 内存泄漏类进程累积占用的资源越来越多
- 日志文件、临时文件持续膨胀挤占磁盘
所以uptime的正确用法是作为参照，而不是健康指标，看到运行时间很长，顺手查一下free -h、df -h、dmesg | tail，比单看一个数字有意义。
把运行时间接进监控
在监控系统里,可以用一条简单命令采集：
awk '{print $1}' /proc/uptime
采集到的是秒数,做趋势图时关注”突降”数值突然变小就意味着重启，这比等用户报障要快得多，对于核心业务机器，重启事件本身就该触发告警。
几个容易踩的坑
容器里看到的不是容器自己的运行时间
在Docker容器内执行uptime，读到的通常是宿主机的运行时间，不是容器启动了多久，原因很直接：/proc/uptime在没有特殊处理时反映的是内核视角的时间，要看容器自身存活时长，用docker ps的STATUS列，或者读容器内的/proc/1/stat起始时间。
虚拟机挂起后，时间对不上
虚拟机执行挂起再恢复,/proc/uptime的单调时钟可能不包含挂起的那段时间，这时候who -b给出的开机时刻和uptime的时长会打架，不用怀疑命令坏了，是虚拟化层的行为差异。
不要把 systemd-analyze 当成运行时间
systemd-analyze输出的是本次开机耗时（几秒几毫秒），跟”运行了多久”完全是两码事，这两个概念在搜索时经常被混淆。
收尾
查Linux服务器运行时间不难,uptime一行就够；难的是把”运行时长”这个数字放回正确的语境里它回答的是”多久没重启”，而不是”系统好不好”，养成uptime配合/proc/uptime、who -b交叉验证的习惯，能省掉很多排查上的弯路。
关于Linux服务器运行时间的常见问题
查看Linux服务器运行时间需要root权限吗
不需要。uptime、cat /proc/uptime、who -b都是普通用户可执行的命令。last reboot读取的是/var/log/wtmp，部分发行版对该文件的权限做了限制，普通用户可能读不到完整记录，这时候才需要提权。
uptime显示的天数会一直累加吗，服务器重启后怎么变化
会持续累加,直到系统重启，重启后uptime从零重新计时，但last reboot会保留历史记录，能看到之前每一次重启的时间点，所以判断”这台机器是否重启过”，看last reboot比看uptime更可靠。
云服务器控制台显示的开机时间和uptime不一致是什么原因
常见于三种情况：控制台显示的是实例创建时间而非本次启动时间；实例经历过迁移或热迁移，控制台记录刷新了而系统内部计时逻辑不同；或者实例从快照恢复，系统时间被还原，以服务器内部who -b的输出为准，控制台数据作为辅助参考。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788872.html
