RED（比率，错误，持续时间）方法是性能监视的流行方法之一。它通常用于监视微服务，尽管没有什么可以阻止您将其用于MySQL等数据库。
在Percona Monitoring and Management（PMM）v2中，所有必需的信息都收集在ClickHouse数据库中，然后创建一个仪表板以使用内置的ClickHouse数据源可视化指标是技术问题。
在创建仪表板时，除了用于RED的面板外，还添加了其他几个面板，以显示可以用Grafana + ClickHouse作为数据源完成的一些有趣的事情，以及我们存储的有关MySQL查询性能的信息。
让我们仔细看一下仪表板。
我们看到经典的RED方法面板，其中显示了系统中所有节点的查询速率（每秒请求），错误率（错误）以及平均和第99个百分位数的查询延迟（查询执行时间）。下面的面板显示有关特定节点的信息，这对于比较它们的性能非常有用。如果其中一个节点开始与其他类似节点的工作方式不同，则这是进行调查的原因。
借助过滤器（仪表板顶部的“过滤器”），您可以仅查看所需的数据。例如，您只能为“ datacenter4”区域中的主机选择“ sbtest”架构查询：
这种临时过滤非常方便。您可以在过滤器中使用正则表达式，通过特定的QueryID进行搜索，分析来自特定客户端主机的查询等。有关ClickHouse中可用列的说明，请参见《 Percona监视和管理中具有Direct ClickHouse Access的高级查询分析》一文。
在大多数面板中，您可以快速转到Query Analytics以查看有关查询性能的详细信息，或者，如果您注意到其中一台主机上出现异常，则可以通过“数据链接”查看该主机的查询-单击图并点击专用链接：
对于每个系统，您可以查看与整个系统整体相同的RED指标。默认情况下，我将这些面板最小化，尤其是当您监视许多主机时。
我们熟悉了RED方法的面板。现在，让我们看一下该仪表板中的“其他仪表板”。
基于行的效率显示每个返回或更改的行分析了多少行。通常，大于100的值表示索引错误或非常复杂的查询，这些查询读取大量数据而仅返回几行。这两种情况都需要分析。
基于时间的效率（基于时间的效率）基于相同的数学原理，但着眼于查询执行时间而不是扫描的行数。这使您可以诊断磁盘速度慢或请求冲突的问题。通常，高性能系统应该期望毫秒级的时间将字符串发送或更改给客户端。返回或更新许多行的查询将具有较低的值。
每个主机的查询（主机请求的数量）说明了一切，紧接着它是查看每个主机的查询负载（主机负载）非常有用，它显示了并发活动请求的数量。在这里我们可以看到，尽管mysql4的查询数量（查询率）最高，但它的负载最大，活动查询的平均数量最高。
考虑其他哪些指标可能有用，我添加了以下其他面板：
这些面板将查询处理效率分为READ查询（返回行）和WRITE查询（具有row_affected）。
基于QueryTime的效率与上述相同，仅强调某些类型的查询。
数据处理效率（数据处理效率）对相同数据的外观略有不同。这显示了查询检查了多少行以及查询的执行时间。一方面，这显示了系统的处理能力。具有许多核心且将所有数据存储在内存中的系统每秒可以处理数百万行，并且可以完成很多工作。但这并不意味着查询效率。实际上，快速处理大量数据的系统通常会执行许多全表扫描。
最后，有几个请求列表。
频繁查询，最慢查询（按平均执行时间），负载最高的查询以及失败或失败的查询。您还可以在Query Analytics中查看这些查询，但我想在此处显示它们作为示例。
你感兴趣吗？您可以从Grafana.com在Percona Monitoring and Management（PMM）v2中安装仪表板。
从代码到kubernetes