原文：https://www.redhat.com/en/blog/implementing-dstat-performance-co-pilot
Dstat 是许多人喜爱的工具，也是诊断系统性能问题时的主要工具。 但是，原来的 dstat 不再积极开发。 这给像 Fedora 这样的发行版迁移到 Python 3 堆栈带来了直接的问题，因为它缺少 Python 3 实现（工具本身和它的许多插件）。 还有一个问题是插件系统相对简单，需要进行重大的重新设计和重写以添加新的所需功能。
用于救援任务的Performance Co-Pilot
Performance Co-Pilot (PCP) 是一个轻量级的性能分析工具包。 用于轻松收集指标、分析（包括）实时和历史性能数据。 它还设计为易于扩展，提供 API 和库以从您自己的应用程序中提取和使用性能指标。
我们采用了这些功能，将它们与原始 dstat UI 代码结合起来，并生成了一个新的 dstat。 从架构的角度来看，PCP 通过性能指标 API (PMAPI) 将指标集合与其分析/显示分开。 这允许开发人员一次（有效地）编写指标收集/采样功能，并通过使用 PMAPI 调用而不是直接使用指标源将其抽象化，从而在报告/可视化指标的不同请求中重用该实现。
使之适应 dstat
与 dstat 类似，PCP 有自己的 vmstat、iostat 和 mpstat 实现。 每个都利用 PCP 的可扩展集合 API 以类似于其原始工具的方式提取指标。
我们在dstat上再次做到了这一点，我们的Python库与Python2和Python3版本兼容。
与原始 dstat 一样，可以指定要通过命令行显示的备用/深度指标类别：
插件
随着我们继续开发这个新的 dstat 并努力实现功能对等，我们希望确保明确包含的 dstat UI 的一个重要方面是插件。 然而，因为我们已经能够通过 PMAPI 抽象出指标收集细节，所以这是一个自然的地方，可以改进我们在 dstat UI 中描述插件的方式，并将其与创建配置文件功能的长期 TODO 相结合。
现在，显示的所有 PCP dstat 指标都来自配置文件定义的“插件”。 这带来了一个优势，可以更轻松地为 PCP 的 dstat 创建插件。 例如，比较 nfs3 插件实现：
### Author: Dag Wieers <dag@wieers.com>class dstat_plugin(dstat):def __init__(self):self.name = 'nfs3 client'self.nick = ('read', 'writ', 'rdir', 'inod', 'fs', 'cmmt')self.vars = ('read', 'write', 'readdir', 'inode', 'filesystem', 'commit')self.type = 'd'self.width = 5self.scale = 1000self.open('/proc/net/rpc/nfs')def check(self):info(1, 'Module %s is still experimental.' % self.filename)def extract(self):for l in self.splitlines():if not l or l[0] != 'proc3': continueself.set2['read'] = long(l[8])self.set2['write'] = long(l[9])self.set2['readdir'] = long(l[17]) + long(l[18])self.set2['inode'] = long(l[3]) + long(l[4]) + long(l[5]) + long(l[6]) + long(l[7]) + long(l[10]) + long(l[11]) + long(l[12]) + long(l[13]) + long(l[14]) + long(l[15]) + long(l[16])self.set2['filesystem'] = long(l[19]) + long(l[20]) + long(l[21])self.set2['commit'] = long(l[22])for name in self.vars:self.val[name] = (self.set2[name] - self.set1[name]) * 1.0 / elapsedif step == op.delay:self.set1.update(self.set2)# vim:ts=4:sw=4:et
这个实现不仅必须定义指标——包括如何显示它们——还必须定义如何从源中抓取它们（在本例中为“/proc/net/rpc/nfs”）。
相反，在新的dstat中，我们只需要列出我们将使用的指标，以及如何使用 PCP 的 pmrep.conf(5) 语法来显示它们。
添加其他（每个用户）配置遵循相同的过程。 例如，如果我们想要一个新的内核entropy插件，我们可以创建一个只包含几行信息的配置文件：
我们可以使用“--entropy”作为 pcp 的 dstat 命令的选项来调用它，如下所示：
虽然我们还没有完美的插件覆盖，但随着时间的推移，我们会朝着这个方向努力。 当然，欢迎投稿！
不需要守护进程
我听到的一个误解是 PCP 需要守护进程才能使用新的 dstat，但事实并非如此。
为此，PCP 使用“本地上下文模式”。 并直接从各自的性能指标域代理 (PMDA) 中提取指标。
通过 PCP 增强 dstat
考虑到这一点，将新的 dstat 集成到 PCP 的框架中增加了几个优势，并且非常适合已启用的 TODO dstat 页面一段时间。 特别是这个：
允许强制到给定的大小（–unit=kilo）
这是在整个 PCP 工具包中完成的，这不仅意味着每个指标在收集时都被赋予了一个默认单位，而且 PMAPI 知道如何在请求时在不同单位之间进行转换。
从 dstat 的角度来看，这就像在配置文件中指定单位一样简单。 检查 man 5 pcp-dstat 为我们提供了以下信息：
metric.unit (string)Defines the unit/scale conversion for the metric. Needs to be dimension-compatible and is used with non-string metrics. For allowed values, see pmrep(1).
我们勾选的另一个 TODO 是“允许不同类型的导出模块（现在只有 CSV）”。
PCP 的框架有多种已经存在的工具来写入 pcp 数据（包括那些由 dstat 收集的指标）转换为其他格式。 几个保存在主源代码树中；
pcp2elasticsearch
pcp2graphite
pcp2influxdb
pcp2json
pcp2spark
pcp2xlsx
pcp2xml
pcp2zabbix
允许将缓冲写入磁盘
在过去的 20 年中，PCP 拥有自己的存档格式，由“pmlogger”程序编写（通常作为服务运行）。 当 PCP 客户端工具使用 PMAPI 时（就像这个 dstat 实现一样），它们还可以访问存储在档案中的指标，而无需自己实现功能。 这意味着即使是全新的 dstat 实现也可以显示以前收集的值，就像它们是实时的一样，使用 PCP 标准标志来指定要显示的指标的时间范围。
研究与应用程序的交互
我们关注的另一个任务是为应用程序/协议添加接口，例如 Amavis、Apache httpd、Bind、CIFS、dhcpd、dnsmasq、gfs、Samba、Squid 等。
虽然与原始 dstat 不是 1:1 匹配，但我们覆盖了 70 多个不同的应用程序/指标域。 完整列表位于 GitHub 在 PCP 存储库中。 dstat 用户感兴趣的几个包括用于 Apache、Bind、CIFS、GFS2、Gluster、Libvirt、MySQL、NGINX、Postfix、Prometheus、Redis、XFS 等的 PMDA。
我们解决的另一个 TODO 是“为_所有_可能的统计信息设计适当的对象模型和命名空间”。
这是在 PCP 中使用性能指标名称空间 (PMNS) 完成的。 每个指标都有一个名称，用于在任何给定的分析工具以及历史档案中引用它。
最后，还有“创建客户端/服务器监控工具”TODO。 在 PCP 的 dstat 上下文中，在目标主机上启用 Performance Metrics Collector Daemon (PMCD) 的主要好处之一是远程使用 dstat。 这种分布式特性从一开始就内置于 PCP 中，使用 PMAPI 允许新的 dstat 远程访问该功能。
上下文中，在目标主机上启用 Performance Metrics Collector Daemon (PMCD) 的主要好处之一是远程使用 dstat。 这种分布式特性从一开始就内置于 PCP 中，使用 PMAPI 允许新的 dstat 远程访问该功能。
[外链图片转存中…(img-PwNRQGrJ-1644306912711)]
我们认为 dstat 是一个很棒的工具，这就是为什么我们希望看到它继续被使用，即使在 Python 3 世界中，并希望帮助它继续发展和扩展其可用功能。 PCP 在大多数现代 Linux 发行版中都可用。 如需更多文档和信息，请参阅 Performance Co-Pilot 主页。 想贡献？ 随意打开 GitHub 上的拉取请求，或将您的配置发送到 pcp@groups.io。