如何用系统信息收集工具快速定位故障运维新手完整上手指南【免费下载链接】sosA unified tool for collecting system logs and other debug information项目地址: https://gitcode.com/gh_mirrors/so/sosSoSSystem Support是一款基于 Python 的开源系统信息收集工具它能把操作系统配置、运行日志、服务状态等散落各处的诊断数据一次性打包成压缩文档让排障从手工翻几十个文件变成一条命令搞定。它主要面向 Linux 运维人员、技术支持工程师以及刚入门系统诊断、想知道机器到底发生了什么的初学者。出发之前先认识这位系统体检打包师想象一下体检中心你不需要自己一项项测血压、验血、做B超只需要躺好机器会自动采集所有指标最后给你一张汇总报告单。SoS 干的就是这件事——它把内核信息、网络配置、服务状态、日志文件、软件包清单等体检项目全部自动跑一遍然后打包成一份带时间戳的压缩档案。它的工作方式有四个常用成员sos report主力采集命令负责生成诊断包sos clean / sos mask给报告做脱敏抹掉 IP、主机名、MAC 地址等敏感信息sos collect针对集群环境一条命令从多个节点同时收集sos upload把生成的报告直接推送到指定服务器。这套工具之所以强大核心在于插件化设计。每一个子系统内核、网络、数据库、容器……都对应一个独立插件插件决定要跑哪些命令、读哪些文件。你可以把它理解成体检中心的各个科室缺哪个科室就补哪个科室灵活得很。三步搭好运行环境从安装到验证一条龙安装是所有人绕不开的第一关其实只需要三步。用包管理器安装推荐新手如果你的系统是 RHEL、Fedora 这类红帽系执行sudo dnf install sos如果是 Debian、Ubuntu 这类 Debian 系执行sudo apt install sosreport。发行版自带的版本已经过充分测试开箱即用。从源码安装想尝鲜或改代码先克隆仓库git clone https://gitcode.com/gh_mirrors/so/sos进入目录后执行python3 setup.py install。注意项目要求 Python 3.8 及以上版本装之前可以用python3 --version确认一下。验证安装是否成功在终端输入sos --help。如果能看到各个子命令的说明说明环境已经就绪可以出发了。结果验证这一步的成功标志就是帮助信息正常输出。如果报command not found多半是安装路径没进 PATH回到第一步检查安装命令有没有真正执行成功。建议顺手执行sos report --help提前熟悉一下后面会用到的主要参数。五分钟跑通首次采集拿到你的第一份诊断包环境就绪后我们来一次完整的首跑。执行sudo sos report --batch。--batch的意思是全程免交互不需要你回答任何确认问题适合第一次体验。稍等片刻你会看到屏幕上不断滚动各种插件采集的状态。采集时长取决于机器配置和安装的软件数量一般几分钟内完成。采集结束后在/var/tmp目录下找产物。文件名形如sosreport-主机名-日期-随机串.tar.xz这就是你的第一份诊断包。解包看看里面都有什么。用tar -tf列一下内容你会发现它井井有条配置文件、日志、命令输出被分门别类整理好还有一个 HTML 格式的摘要报告浏览器打开就能概览系统全貌。结果验证能生成.tar.xz压缩包、且解包后能看到结构清晰的内容目录就算首跑成功。如果你之前听说过sosreport这个老命令注意它已经退出历史舞台请一律使用新的sos report写法。一招化解权限拦路虎让采集完整无遗漏很多新手第一次运行时会发现不加sudo直接跑sos report采集结果缺东少西甚至直接报权限错误。原因很简单——系统里相当一部分配置和日志比如/var/log下的内核日志、网络连接状态只有 root 用户才有权读取。工具本身设计上就要求以管理员权限运行这不是 bug而是它的工作方式。应对方法始终使用sudo前缀运行采集命令。如果你在一台需要频繁排查的服务器上可以在/etc/sudoers里给运维账号配置免密执行 sos 的权限省去每次输密码的麻烦但注意这属于敏感权限建议只在可信的内网环境开启。结果验证以 root 权限重新采集一份对比普通用户版本的报告你会发现文件数量明显增加之前缺失的网络、内核、系统日志条目都齐了。下次再遇到报告内容不全先检查是不是权限没给够。学会挑着收集让报告体积更小、速度更快默认的全量采集会跑遍所有已安装组件的插件这在配置复杂的生产机上可能耗时较长生成的包动辄几十上百兆。其实大多数时候你只需要其中一小部分数据。好在 SoS 提供了精准的点菜能力。先用sudo sos report -l列出所有可用插件找到你关心的那一个比如网络对应 networking内核对应 kernel。用-o参数只收集指定插件例如sudo sos report -o networking其他无关插件全部跳过反过来如果你想排除某些插件用-n指定跳过列表-e则用于启用默认不开启的插件。如果嫌压缩包太大用-z指定压缩方式如果担心某个插件卡住拖慢整体进度可以设置--plugin-timeout和--cmd-timeout给采集命令加上超时保护超时自动跳过不会无限等待。你甚至可以用--skip-files和--skip-commands精确剔除某些大文件和耗时命令。结果验证对比全量采集和定向采集两种方式你会看到后者速度明显更快、包体积显著缩小而关键数据一条不少。排障时少而精往往比大而全更高效外发给别人也更友好。进阶第一课给报告做隐私脱敏再外发诊断包通常要发给厂商技术支持或外部同事但里面可能藏着敏感信息IP 地址、主机名、MAC 地址、用户名、甚至某些关键词。直接外发等于把服务器的底裤交了出去。这时候就该sos clean登场了。使用场景假设你已经在/var/tmp下拿到了一份原始报告准备发给厂商前执行sudo sos clean /var/tmp/sosreport-主机名-日期-随机串.tar.xz工具会自动识别并替换报告中的 IP、IPv6 地址、MAC、主机名、用户名等敏感内容生成一份新的清洗版报告。sos mask则是更轻量的脱敏命令适用于只想快速打码的场景。结果验证打开清洗后的报告用grep搜一下原始 IP 或主机名你会发现匹配不到——它们已经被替换成了占位符。确认无泄漏后再外发既专业又安全。顺带一提清洗逻辑本身也是插件化的你可以在sos/cleaner/parsers/目录下看到各类解析器的实现理解它比想象中容易。进阶第二课一条命令扫平整个集群单机排障只是入门真正的挑战在集群环境——Kubernetes、Pacemaker、OpenStack 这类多节点系统出问题时你需要挨个节点收集数据手工操作费时费力还容易漏。sos collect就是为此设计的。使用场景集群告警领导催着要全节点数据。你只需要在控制节点上执行sudo sos collect工具会通过 SSH 连接到集群中的各个节点统一执行采集再把结果汇总成一份总报告。它还内置了多种集群类型的识别能力自动适配不同集群的节点发现方式。结果验证采集完成后你能得到一份覆盖所有节点的汇总报告打开后可以按节点分别查看各自的诊断数据。原本一上午的重复劳动压缩到了几分钟这就是批量工具的价值。进阶第三课动手写一个专属采集插件用久了你会发现有些内部自研服务的数据 SoS 默认不采集。别急它天生就是为扩展设计的。插件目录在sos/report/plugins/下每个插件就是一个 Python 模块结构非常规整。上手思路先找kernel.py这类简单插件当模板读一遍。你会发现核心要素就几样一个继承自 Plugin 的类、一个plugin_name插件名、一组profiles表示它归属哪个配置档、一个option_list声明可调参数以及负责定义采集什么的setup方法。你只需要照着这个骨架把自己要跑的命令和要读的文件填进去即可。如果你写的插件不依赖特定发行版继承IndependentPlugin就能跨平台通用。结果验证把插件文件放进插件目录后执行sudo sos report -l你写的插件名会出现在列表里用-o 插件名单独运行看看输出是否如预期。从用工具的人变成造工具的人这一步是质的飞跃。写完后记得跑一下项目自带的tox测试flake8、pylint、单元测试保证代码质量再提交。最后一站往更深处走的三条路到这里你已经完成了从装不上到玩得转的蜕变。如果想继续深入我建议三条路并行吃透配置文件项目根目录的sos.conf是全局配置的入口把常用的参数固化进去以后每次运行都省心不少。读官方文档项目docs/目录下有完整的 Sphinx 文档从插件编写规范到上传目标配置一应俱全是你进阶路上最好的地图。回馈社区项目有大量翻译文件po/目录和测试用例你可以从翻译本地化、补充测试、提交 issue 开始参与。你的每一次贡献都在让这个体检打包师服务更多人。系统排障的终极目标是让找到问题这件事本身不再困难。SoS 帮你把信息收集的脏活累活包圆了剩下的就是你在关键时刻多了一份从容。现在去跑一条sos report试试看吧。【免费下载链接】sosA unified tool for collecting system logs and other debug information项目地址: https://gitcode.com/gh_mirrors/so/sos创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何用系统信息收集工具快速定位故障：运维新手完整上手指南
如何用系统信息收集工具快速定位故障运维新手完整上手指南【免费下载链接】sosA unified tool for collecting system logs and other debug information项目地址: https://gitcode.com/gh_mirrors/so/sosSoSSystem Support是一款基于 Python 的开源系统信息收集工具它能把操作系统配置、运行日志、服务状态等散落各处的诊断数据一次性打包成压缩文档让排障从手工翻几十个文件变成一条命令搞定。它主要面向 Linux 运维人员、技术支持工程师以及刚入门系统诊断、想知道机器到底发生了什么的初学者。出发之前先认识这位系统体检打包师想象一下体检中心你不需要自己一项项测血压、验血、做B超只需要躺好机器会自动采集所有指标最后给你一张汇总报告单。SoS 干的就是这件事——它把内核信息、网络配置、服务状态、日志文件、软件包清单等体检项目全部自动跑一遍然后打包成一份带时间戳的压缩档案。它的工作方式有四个常用成员sos report主力采集命令负责生成诊断包sos clean / sos mask给报告做脱敏抹掉 IP、主机名、MAC 地址等敏感信息sos collect针对集群环境一条命令从多个节点同时收集sos upload把生成的报告直接推送到指定服务器。这套工具之所以强大核心在于插件化设计。每一个子系统内核、网络、数据库、容器……都对应一个独立插件插件决定要跑哪些命令、读哪些文件。你可以把它理解成体检中心的各个科室缺哪个科室就补哪个科室灵活得很。三步搭好运行环境从安装到验证一条龙安装是所有人绕不开的第一关其实只需要三步。用包管理器安装推荐新手如果你的系统是 RHEL、Fedora 这类红帽系执行sudo dnf install sos如果是 Debian、Ubuntu 这类 Debian 系执行sudo apt install sosreport。发行版自带的版本已经过充分测试开箱即用。从源码安装想尝鲜或改代码先克隆仓库git clone https://gitcode.com/gh_mirrors/so/sos进入目录后执行python3 setup.py install。注意项目要求 Python 3.8 及以上版本装之前可以用python3 --version确认一下。验证安装是否成功在终端输入sos --help。如果能看到各个子命令的说明说明环境已经就绪可以出发了。结果验证这一步的成功标志就是帮助信息正常输出。如果报command not found多半是安装路径没进 PATH回到第一步检查安装命令有没有真正执行成功。建议顺手执行sos report --help提前熟悉一下后面会用到的主要参数。五分钟跑通首次采集拿到你的第一份诊断包环境就绪后我们来一次完整的首跑。执行sudo sos report --batch。--batch的意思是全程免交互不需要你回答任何确认问题适合第一次体验。稍等片刻你会看到屏幕上不断滚动各种插件采集的状态。采集时长取决于机器配置和安装的软件数量一般几分钟内完成。采集结束后在/var/tmp目录下找产物。文件名形如sosreport-主机名-日期-随机串.tar.xz这就是你的第一份诊断包。解包看看里面都有什么。用tar -tf列一下内容你会发现它井井有条配置文件、日志、命令输出被分门别类整理好还有一个 HTML 格式的摘要报告浏览器打开就能概览系统全貌。结果验证能生成.tar.xz压缩包、且解包后能看到结构清晰的内容目录就算首跑成功。如果你之前听说过sosreport这个老命令注意它已经退出历史舞台请一律使用新的sos report写法。一招化解权限拦路虎让采集完整无遗漏很多新手第一次运行时会发现不加sudo直接跑sos report采集结果缺东少西甚至直接报权限错误。原因很简单——系统里相当一部分配置和日志比如/var/log下的内核日志、网络连接状态只有 root 用户才有权读取。工具本身设计上就要求以管理员权限运行这不是 bug而是它的工作方式。应对方法始终使用sudo前缀运行采集命令。如果你在一台需要频繁排查的服务器上可以在/etc/sudoers里给运维账号配置免密执行 sos 的权限省去每次输密码的麻烦但注意这属于敏感权限建议只在可信的内网环境开启。结果验证以 root 权限重新采集一份对比普通用户版本的报告你会发现文件数量明显增加之前缺失的网络、内核、系统日志条目都齐了。下次再遇到报告内容不全先检查是不是权限没给够。学会挑着收集让报告体积更小、速度更快默认的全量采集会跑遍所有已安装组件的插件这在配置复杂的生产机上可能耗时较长生成的包动辄几十上百兆。其实大多数时候你只需要其中一小部分数据。好在 SoS 提供了精准的点菜能力。先用sudo sos report -l列出所有可用插件找到你关心的那一个比如网络对应 networking内核对应 kernel。用-o参数只收集指定插件例如sudo sos report -o networking其他无关插件全部跳过反过来如果你想排除某些插件用-n指定跳过列表-e则用于启用默认不开启的插件。如果嫌压缩包太大用-z指定压缩方式如果担心某个插件卡住拖慢整体进度可以设置--plugin-timeout和--cmd-timeout给采集命令加上超时保护超时自动跳过不会无限等待。你甚至可以用--skip-files和--skip-commands精确剔除某些大文件和耗时命令。结果验证对比全量采集和定向采集两种方式你会看到后者速度明显更快、包体积显著缩小而关键数据一条不少。排障时少而精往往比大而全更高效外发给别人也更友好。进阶第一课给报告做隐私脱敏再外发诊断包通常要发给厂商技术支持或外部同事但里面可能藏着敏感信息IP 地址、主机名、MAC 地址、用户名、甚至某些关键词。直接外发等于把服务器的底裤交了出去。这时候就该sos clean登场了。使用场景假设你已经在/var/tmp下拿到了一份原始报告准备发给厂商前执行sudo sos clean /var/tmp/sosreport-主机名-日期-随机串.tar.xz工具会自动识别并替换报告中的 IP、IPv6 地址、MAC、主机名、用户名等敏感内容生成一份新的清洗版报告。sos mask则是更轻量的脱敏命令适用于只想快速打码的场景。结果验证打开清洗后的报告用grep搜一下原始 IP 或主机名你会发现匹配不到——它们已经被替换成了占位符。确认无泄漏后再外发既专业又安全。顺带一提清洗逻辑本身也是插件化的你可以在sos/cleaner/parsers/目录下看到各类解析器的实现理解它比想象中容易。进阶第二课一条命令扫平整个集群单机排障只是入门真正的挑战在集群环境——Kubernetes、Pacemaker、OpenStack 这类多节点系统出问题时你需要挨个节点收集数据手工操作费时费力还容易漏。sos collect就是为此设计的。使用场景集群告警领导催着要全节点数据。你只需要在控制节点上执行sudo sos collect工具会通过 SSH 连接到集群中的各个节点统一执行采集再把结果汇总成一份总报告。它还内置了多种集群类型的识别能力自动适配不同集群的节点发现方式。结果验证采集完成后你能得到一份覆盖所有节点的汇总报告打开后可以按节点分别查看各自的诊断数据。原本一上午的重复劳动压缩到了几分钟这就是批量工具的价值。进阶第三课动手写一个专属采集插件用久了你会发现有些内部自研服务的数据 SoS 默认不采集。别急它天生就是为扩展设计的。插件目录在sos/report/plugins/下每个插件就是一个 Python 模块结构非常规整。上手思路先找kernel.py这类简单插件当模板读一遍。你会发现核心要素就几样一个继承自 Plugin 的类、一个plugin_name插件名、一组profiles表示它归属哪个配置档、一个option_list声明可调参数以及负责定义采集什么的setup方法。你只需要照着这个骨架把自己要跑的命令和要读的文件填进去即可。如果你写的插件不依赖特定发行版继承IndependentPlugin就能跨平台通用。结果验证把插件文件放进插件目录后执行sudo sos report -l你写的插件名会出现在列表里用-o 插件名单独运行看看输出是否如预期。从用工具的人变成造工具的人这一步是质的飞跃。写完后记得跑一下项目自带的tox测试flake8、pylint、单元测试保证代码质量再提交。最后一站往更深处走的三条路到这里你已经完成了从装不上到玩得转的蜕变。如果想继续深入我建议三条路并行吃透配置文件项目根目录的sos.conf是全局配置的入口把常用的参数固化进去以后每次运行都省心不少。读官方文档项目docs/目录下有完整的 Sphinx 文档从插件编写规范到上传目标配置一应俱全是你进阶路上最好的地图。回馈社区项目有大量翻译文件po/目录和测试用例你可以从翻译本地化、补充测试、提交 issue 开始参与。你的每一次贡献都在让这个体检打包师服务更多人。系统排障的终极目标是让找到问题这件事本身不再困难。SoS 帮你把信息收集的脏活累活包圆了剩下的就是你在关键时刻多了一份从容。现在去跑一条sos report试试看吧。【免费下载链接】sosA unified tool for collecting system logs and other debug information项目地址: https://gitcode.com/gh_mirrors/so/sos创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
