共计 2610 个字符,预计需要花费 7 分钟才能阅读完成。
在这篇文章中,咱们将介绍 below
:一个用于古代 Linux 零碎的 Apache 2.0 许可的资源监视器。below
能够让你重放以前记录的数据。
背景
内核的主要职责之一是调度对资源的拜访。有时这可能意味着调配物理内存,使多个过程能够共享同一主机。其余时候,它可能意味着确保 CPU 工夫的偏心调配。在这些场景里,内核提供了机制,而将策略留给了“他人”。近来,这个“他人”通常是 systemd 或 dockerd 这样的运行时。运行时承受来自调度器或最终用户的输出(相似于运行什么和如何运行)并在内核上转动正确的旋钮和拉动正确的杠杆,从而使工作负载可能 好好 工作。
在一个完满的世界里,故事就到此结束了。然而,现实情况是,资源管理是一个简单的、相当不通明的技术混合体,在几十年里计算技术一直倒退。只管其中一些技术有各种缺点和死角,但最终的后果是,容器运作得比拟好。尽管用户通常不须要关怀这些细节,但对于基础设施运营商来说,对他们的技术架构领有可见性是至关重要的。可见性和可调试性对于检测和考察谬误的配置、问题和系统性故障至关重要。
让事件变得更加简单的是,资源中断往往难以重现。常常须要破费数周工夫期待一个问题从新呈现,以便考察其根本原因。规模的扩充进一步加剧了这个问题:咱们不能在 每台 主机上运行一个自定义脚本,心愿在谬误再次发生时记录下要害状态的片段。因而,须要更简单的工具。这就呈现了 below
。
动机
历史上,Facebook 始终是 atop 的忠诚用户。atop
是一个用于 Linux 的性能监视器,可能报告所有过程的流动以及各种零碎级流动。与 htop
等工具相比,atop
最引人注目的性能之一是可能作为一个守护程序记录历史数据。这听起来是一个简略的性能,但在实践中,这使得调试有数的生产问题成为可能。有了足够长的数据保留,就有可能在工夫上回溯,查看在问题或故障产生之前、期间和之后的主机状态。
可怜的是,随着工夫的推移,人们发现atop
有某些不足之处。首先,控制组 cgroup 曾经成为管制和监督 Linux 机器上资源的理论形式。atop
依然不足对这一根本构建模块的反对。第二,atop
用自定义的 delta 压缩办法在磁盘上存储数据。这在失常状况下运行良好,但在惨重的资源压力下,主机很可能会失落数据点。因为应用了 delta 压缩,在数据最重要的时间段内,数据可能会大面积失落。第三,用户体验有一个平缓的学习曲线。咱们常常听到 atop
的资深用户说,他们喜爱密集的布局和泛滥的键盘绑定。然而,这也是一把双刃剑。当一个刚进入这个畛域的人想要调试一个生产问题时,他们当初要同时解决两个问题:手头的问题和如何应用 atop
。
below
是由 Facebook 的资源管制团队为其设计和开发的,并失去了 atop
生产环境用户的反对。顾名思义,资源管制团队负责的是规模化的资源管理。该团队由内核开发人员、容器运行时开发人员和硬件人员组成。意识到下一代零碎监控器的机会,咱们在设计 below
时思考到以下几点:
- 易用性:
below
必须既能为新用户提供直观的体验,又能为日常用户提供弱小的性能。* 有意义的统计数据:below
显示精确和有用的统计数据。即使能够,但咱们尽量避免收集和倾倒统计数字。 - 灵活性:当默认设置不适合时,咱们容许用户自定义他们的体验。例如包含可配置的键绑定、可配置的默认视图,以及脚本界面(默认为终端用户接口)。
装置
装置该软件包:
# dnf install -y below
关上记录守护过程:
# systemctl enable --now below
疾速介绍
below
最罕用的模式是重放模式。顾名思义,重放模式是重放以前记录的数据。假如你曾经启动了记录守护程序,那么通过运行以下程序启动一个会话:
$ below replay --time "5 minutes ago"
而后你会看到控制组视图:
如果你不晓得该怎么操作,或者遗记了一个键位,按 ?
能够进入帮忙菜单。
屏幕的最上方是状态栏。状态栏显示对于以后样本的信息。你能够通过按 t
和 T
别离向前和向后挪动样本。两头的局部是零碎概览。零碎概览蕴含了对于整个零碎的统计数据,一般来说,这些数据总是很有用的。第三局部也是最上面的局部是多用途视图。下面的图片显示了控制组视图。此外,还有过程和零碎视图,别离通过按 p
和s
来拜访。
按 ↑
和 ↓
来挪动列表抉择。按回车键来折叠和开展控制组。假如你发现了一个感兴趣的控制组,你想看看它外面有哪些过程在运行。要放大过程视图,抉择控制组并按 z
:
再按 z
返回到控制组视图。这个视图有时会有点长。如果你对你要找的货色有一个含糊的概念,你能够通过按 /
并输出一个过滤器来过滤控制组名称。
在这一点上,你可能曾经留神到了一个咱们还没有摸索过的标签零碎。要在标签中向前和向后循环,能够别离按 Tab
和 Shift
+ Tab
。咱们把这个问题留给读者去做练习。
其余性能
在底层,below
有一个弱小的设计和架构。Facebook 正在一直降级到更新的内核,所以咱们从不假如数据源是可用的。这种默契的假如使得内核和 below
版本之间可能齐全向前和向后兼容。此外,每个数据点都用 zstd 压缩并残缺地存储。这解决了咱们看到的 atop
在大规模时的 delta 压缩问题。依据咱们的测试,咱们的每个样本压缩能够达到均匀 5 倍的压缩率。
below
也应用 eBPF 来收集对于短暂过程(生存工夫短于数据收集距离的过程)的信息。相比之下,atop
应用 BSD 过程核算来实现这一性能,这是一个已知迟缓且容易产生优先级转换的内核接口。
对于用户来说,below
还反对实时模式和一个转储接口。实时模式将记录守护程序和 TUI 会话合并到一个过程中。这对于浏览零碎状态是很不便的,不须要为数据存储投入长期运行的守护程序或磁盘空间。转储接口是一个可编写脚本的接口,用于所有的 below
数据存储。转储既弱小又灵便,具体的数据以 CSV、JSON 和人类可读格局提供。
总结
below
是一个 Apache 2.0 许可的开源我的项目,咱们(below
的开发者)认为它比资源监控畛域的现有工具具备引人注目的劣势。咱们曾经花了大量的精力来筹备 below
,以提供开源应用,所以咱们心愿读者和社区有机会尝试 below
,并报告谬误和性能要求。
开源前哨
日常分享热门、乏味和实用的开源我的项目。参加保护 10 万 + Star 的开源技术资源库,包含:Python、Java、C/C++、Go、JS、CSS、Node.js、PHP、.NET 等。