MySQL指标第I部分：吞吐量

作者：Katy Farmer / 开发者，产品
2018年1月11日

导航至

在理想世界中，这篇博客文章是关于MySQL指标和监控MySQL中的吞吐量。在现实中，这篇文章是关于理解数据可视化、适当查询和不断失败——作为副产品，我还在监控MySQL中的吞吐量。让我们开始吧。（注意：如果您只对吞吐量感兴趣，并且不关心我的失败，请跳过标记为“失败”的部分。）

您可能有多种原因想要监控吞吐量——也许您有缓慢的加载时间、断开的连接、服务器崩溃，或者您只是好奇。但在出现问题之前，您可以通过监控吞吐量来深入了解您的流量。

像往常一样，我将继续使用我的爱好项目Blogger（再次提醒，不是那个运行良好、可用的Blogger.com，而是我的个人悲伤状态）。我可以整天讨论监控在理论上的用途，但这并不意味着我可以用原力举起X-Wing。让我们深入探讨如何开始监控吞吐量。

您可以选择您喜欢的任何工具来可视化数据——甚至可以不使用任何工具，只用终端和您的大脑来分析数据。在我的例子中，我将使用Chronograf，因为我最熟悉这个工具。

设置

我正在使用Telegraf和InfluxDB的组合将指标发送到Chronograf。如果您需要帮助设置Telegraf的MySQL输入插件，请参考这篇博客文章中的“配置Telegraf”部分。流程看起来是这样的

Blogger ? MySQL ? Telegraf ? InfluxDB ? Chronograf

可视化

在Chronograf中，我将使用数据探索器来探索数据。

我从数据库列表（mysql-monitor）中选择我的数据库，并从列表中选择mysql度量。这给我们提供了MySQL中所有可用的指标，这很多。很多这个词有点夸张。如果我是Scrooge McDuck，我可以在一个装满MySQL指标的保险库中游泳。如果每个指标都是一个折叠椅，你可能会希望它是摔跤大赛。

我们需要更多的椅子。

你明白了。

我们专注于吞吐量，所以一个好的起点是问题和查询。在我的上一篇文章中，我们讨论了这些如何反映流量量。它也可以作为测试一切是否正常运行的一种方式。

看看它。它只是太图形化了。

这张图显示了过去一小时的情况，我们可以看到逐渐上升的趋势。说实话，即使以这种方式展示，这些数据对我来说意义不大。有40K个查询是好事还是坏事？数据需要上下文。

进入失败#1

从图中可以看出，查询量在40K左右达到峰值，但在我统计之前一篇文章的问题和查询时，它们分别是282590和294564。当时这些数字对我没有太大用处，但现在，从我监控过程中收集到的更多数据点来看，我有了事件发生的证据。

这是一个好消息/坏消息的情况。好消息是：良好的监控实践让我意识到可能存在的问题。坏消息是：在8:30发生了什么？问题和查询都重置为零。

查询

让我说明一下，我不确定这是否值得跟进。在下降之后，系统似乎恢复了正常行为。然而，我发现从错误中学习比正常行为更容易。如果我们没有上下文，没有比较点，那么我们就不知道正常行为是什么样子。所以，让我们来看看异常。

根本无法知道哪一个是正常的。
调查

现在，问题和查询实际上只是一个理性检查。它们给我们一个关于流量的模糊概念，但它们并不提供细节。我们看到的是糟糕的水波纹，但它非常概括。放大数据可能能让我们知道导致下降的原因，每秒读取/写入数最有可能是告诉我们吞吐量是否下降。

问题是：我不知道如何找到每秒的读取/写入数。但我有Influx Query Language文档和互联网，所以我不缺少选择。

首先，我做了我们都会做的事情：我谷歌了一下。结果有很多，但最有帮助的，也是最终正确的答案，在GitHub上关于InfluxDB的问题（InfluxDB issues on GitHub）中。实话实说：我快速浏览了对话，复制了查询，做了一些非常微小的修改，并将其放入我的Chronograf数据探索器中。

没有人提出任何问题。
失败#2

这是一个个人的失败。我有一个可用的查询，我可以很容易地修改它来处理写入，就像上面看到的。但使用我不理解的代码不是前进的方式。我觉得尤达会对我失望，这是一个我需要重新评估我的行为的信号。如果我要使用这个查询，我必须理解它。

这是查询

SELECT non_negative_derivative(first("commands_select"), 1s) 
AS "mean_commands_select" 
FROM "mysql-monitor"."autogen"."mysql" 
WHERE time > :dashboardTime: -1h 
GROUP BY time(10s) FILL(null)

 

这只是一堆东西。InfluxQL类似于SQL，所以我依赖我对SQL（大约是B+）的了解。

SELECT

这部分是相当容易理解的。SELECT语句之后的所有内容都是我们希望返回的内容。

SELECT non_negative_derivative

听听那个。这是开发者倡导者开始意识到她只在前两个词中失去了所有动力的声音。

这有点类似。

不用担心。让我们去找文档。

从非负导数的条目

"返回后续字段值之间的非负变化率。非负变化率包括正的变化率和等于零的变化率。"

变化率是有意义的。也就是说，事实上，我们试图用每秒读取数来衡量的是从一秒到下一秒的读取数的变化率。

SELECT non_negative_derivative(first("commands_insert"), 1s)

InfluxDB中，FIRST指的是具有最老时间戳的条目。这是我可以理解的那种清晰的定义。在这种情况下，我们想要commands_insert（这是我们写入度量之一）的第一个条目。

第二个参数（1s）指定了导数函数要测量的变化率。如果我们想每十秒测量一次写入，我们可以将其替换为10s。

SELECT non_negative_derivative(first("commands_insert"), 1s) 
AS "writes per sec" 
FROM "mysql-monitor"."autogen"."mysql" 
WHERE time > :dashboardTime: -1h

AS提供了别名，这在以后需要再次引用此函数时非常有用。

FROM指定我们要查询的数据库。"autogen"部分是Chronograf添加的默认设置。

WHERE是限定符，表示只返回符合以下标准的结果。在我们的例子中，我们只想看到时间字段大于变量:dashboardTime:（Chronograf生成的变量，默认为1小时）减去一小时的条目。这有点难以理解，但我的看法是它只是改变了你在结果中看到的时间窗口。从:dashboardTime:减去一小时意味着没有偏移量。

这是查询的“加州旅馆”。
SELECT non_negative_derivative(first("commands_insert"), 1s) 
AS "writes per sec" 
FROM "mysql-monitor"."autogen"."mysql" 
WHERE time > :dashboardTime: -1h 
GROUP BY time(10s) FILL(null)

最后，我们到达了GROUP BY。本质上，我们正在创建每10秒的桶，然后应用所有前面的函数。对于每10秒，获取第一个条目，并找到每秒之间的变化率。

FILL是一个我们可以设置的选项，告诉查询在数据缺失时应该做什么。Null是一个好选项，因为它不会扭曲数据。

结果

值得注意的是，使用非负导数实际上掩盖了我们正在调查的事件。将非负导数替换为导数的结果如下所示。

这就是我们要找的。

是的，那是-200。其余的数据受到这次下降的影响非常严重，看起来相对稳定（大约在0-8次/秒之间）。更多真相：这是我发现我在当天早些时候重启笔记本电脑以安装更新的时刻。在本地运行真的又踢了我一下。

即便如此，测量带和不带负值每秒的读写次数显示了两件事：1)仍然只有一个异常数据点，2)在该点移除后，读写非常一致。

数据中的模式对我来说比单个值更有意义，因此知道Blogger有一个规律的跳动意味着它按预期工作。

谢谢，吞吐量！

结论

尽管在旅途中遇到了许多失败和干扰，但吞吐量证明了它是监控以及调查我的数据的宝贵工具。可视化这些数据帮助我看到了趋势和疯狂的事件，以及帮助我确定我是否应该关心这些事情。

在下一篇文章中，我们将探讨执行时间，以及最终真相：我希望它比吞吐量少一些情感上的消耗。