Linux 最大的误区之一，就是认为必须安装几十个第三方工具，才能提高工作效率，
现代软件仓库确实包含了数以千计的优秀工具，但工程师们苦苦寻找的许多功能，其实在一套标准的 Linux 安装中就已经具备。
这些年来，我逐渐意识到，一些最有价值的故障排查、调试和系统分析工具，本身就是操作系统自带的。
它们很少是 GitHub 增长最快的明星项目。
也很少在社交媒体上获得太多关注。
然而，系统管理员、SRE（Site Reliability Engineering，站点可靠性工程师）、后端工程师以及安全从业者每天都在使用它们，因为它们能够准确揭露 Linux 内核和用户空间正在发生什么。
这些，就是我希望更早学会的内置工具。
ss：查看的不只是开放端口，而是整个网络栈
多年以来，netstat 一直是查看网络连接的默认工具。
如今，ss 不仅速度更快、提供的信息更丰富，而且通过 Netlink 接口直接与 Linux 内核通信，不像 netstat 那样解析 /proc 数据，因此在繁忙的系统上效率要高得多。
快速查看监听中的服务：
查看已建立的 TCP 连接：
适用于以下场景：
当一个应用程序看起来“卡住”时，ss 能够告诉你，它是不是正在等待网络响应。
lsof：一切皆文件
在 Linux 中，被表示为文件的远不止文档。
Socket（套接字）
Pipe（管道）
设备
目录
共享库
每个进程都会为自己访问的资源维护文件描述符（File Descriptor）。
lsof 可以将这些关联关系完整展示出来。
查看某个进程打开的文件：
查看哪个进程占用了某个 TCP 端口：
一个特别实用的排查命令：
已经删除的日志文件，只要仍然被运行中的进程持有文件描述符，就依然会占用磁盘空间。
这也解释了为什么很多时候 df 显示文件系统已经满了，du 却找不到这些被占用的空间。
journalctl：结构化的系统日志
传统的 Linux 日志通常需要在 /var/log 下翻阅多个日志文件。
采用 systemd 系统，则会通过系统日志（Journal）统一管理日志。
无需逐个搜索日志文件，就可以按服务查询：
查看最近的日志：
journalctl --since ”30 minutes ago”
查看当前启动周期（Boot）的日志：
由于日志与系统元数据、时间戳、进程 ID 以及服务单元（Service Unit）保持关联，因此排查服务失败的问题会轻松得多。
vmstat：内存问题，看起来往往不像内存问题
很多工程师在服务器变慢时，第一反应是查看 CPU 使用率。
vmstat 往往能揭示真正的瓶颈。
重点关注：
如果系统大量时间都在 RAM 与存储之间交换内存页（Swap），即使 CPU 利用率不高，系统也可能无法使用。
它的表现很像 CPU 已经被耗尽。
但真正的原因，其实是内存压力过大。
dmesg：倾听内核的声音
应用程序只能报告它所观察到的现象。
内核则会告诉你，在操作系统层面发生了什么。
查看最近的内核事件：
重点关注：
忽略内核日志，意味着错过系统变得不稳定时最早出现的证据。
find：远不只是搜索文件
大多数人认为 find 只是用来查找文件名。
事实上，它的过滤能力远不止如此。
查找最近一天修改过的文件：
查找超过指定大小的文件：
find / -type f -size +500M
查找属于指定用户的文件：
在安全事件响应中，find 是定位异常文件、可疑可执行程序以及最近生成痕迹（Artifacts）的高效工具。
xargs：把输出变成工作流
许多 Unix 工具都会产生输出。
xargs 可以把这些输出转换成另一个命令的输入。
例如：
find . -name ”*.log” | xargs grep ”ERROR”
或者删除所有空目录：
find . -type d -empty | xargs rmdir
很多原本需要编写 Shell 脚本完成的重复性管理任务，都可以用几条简洁的命令管道来实现。
tee：观察，而不中断流程
命令管道通常会隐藏中间输出。
tee 可以复制数据流。
例如：
journalctl -u nginx | tee errors.log
日志会一边显示在终端，一边写入文件。
在故障排查过程中，如果你希望保留现场证据，同时又不想重新执行命令，这一点尤其有用。
watch：持续观察
不断按“方向键↑”再按 Enter 重复执行命令，很快就会变得令人厌烦。
不如这样：
或者：
命令会按照固定时间间隔自动执行。
这使得你能够在部署、性能分析或故障响应期间进行轻量级实时监控，无需部署专门的监控平台。
diff：比较，而不是猜测
配置漂移（Configuration Drift）是生产环境问题的常见来源。
与其肉眼逐行比较文件，不如直接：
diff nginx.conf nginx.conf.backup
很多时候，一个看似不起眼的小差异，就足以导致系统行为发生巨大变化。
在部署过程中，比较配置文件，往往比翻阅应用日志更快找到问题根源。
env：你的运行时配置
很多应用程序之所以表现不同，不是因为代码发生了变化，而是环境变量变了。
查看当前运行环境：
在调试容器化应用、CI/CD 流水线或 systemd 服务时，检查环境变量应当是最早进行的排查步骤之一。
缺失的密钥（Secret）、错误的路径，或被修改的配置值，都是导致应用行为异常的常见原因。
这些工具有一个共同特点
仔细观察这些工具，你会发现它们有一个共同点。
它们都不会修改系统。
它们只是观察系统。
它们能够揭示：
经验丰富的工程师，在修改系统之前，首先会弄清楚系统当前的真实状态。
这些工具，正是帮助他们做到这一点的利器。
在扩展操作系统之前，先学会操作系统
Linux 拥有世界上最丰富的软件生态之一。
安装专业工具，很多时候确实是正确的选择。
但许多工程师忽略了一个重要的事实。
操作系统本身，早已提供了一套成熟、高效且经过充分验证的工具，足以应对大多数日常问题的排查与分析。
无论你是在调试生产环境故障、追踪资源消耗、调查安全事件，还是仅仅想弄清楚一台陌生服务器的运行情况，这些内置工具都能直接让你看到 Linux 真正是如何工作的。
回头看，在不断给系统安装更多软件之前，我本应该花更多时间，把那些早已存在系统中的工具学会。
因为，Linux 最有价值的工具，往往正是那些你从来不需要安装的工具。
参考
https://medium.com/@fatihaali093/the-built-in-linux-tools-i-wish-someone-had-shown-me-earlier-4621005dffa9
10个月宝宝每天需要喝多少奶粉？
