数据库健康状况监视

我们对数据库的谈论不够。 在这个工具时代，我们监视我们的应用程序，基础结构甚至用户，但是有时我们忘记了我们的数据库也应受到监视。 这主要是因为大多数数据库都能很好地完成其工作，因此我们只是相信他们能够做到。 信任固然很好，但对我们假设的确认甚至更好。

为什么要监视您的数据库？

监视数据库的原因很多，其中大多数与监视系统的其他部分的原因相同：知道应用程序各个组件中发生的事情会使您成为一个更精明的开发人员，从而做出更明智的决策。

更具体地说，数据库是系统运行状况和行为的重要指标。 数据库中的异常行为可能指向应用程序中的问题区域。 或者，当应用程序中出现异常行为时，可以使用数据库指标来帮助加快调试过程。

问题

最细微的调查揭示了监视数据库的一个问题：数据库有很多指标。 “很多”是一种轻描淡写的方法-如果您是Scrooge McDuck，则可以浏览所有可用的指标。 如果这是Wrestlemania，则指标将为折叠椅。 监视所有这些似乎并不实际，因此您如何确定要监视的指标？

解决方案

开始监视数据库的最佳方法是确定一些基础的，与数据库无关的指标。 这些指标为理解数据库的生命提供了一个良好的开端。

吞吐量：数据库正在做什么？

开始监视数据库的最简单方法是跟踪数据库接收的请求数。 我们对我们的数据库寄予厚望； 我们希望他们能够可靠地存储数据并处理我们向他们提出的所有查询，这可能一天一天是一个庞大的查询，也可能是整天来自用户的数百万次查询。 吞吐量可以告诉您哪些是正确的。

您还可以按类型（读取，写入，服务器端，客户端等）对请求进行分组，以开始分析流量。

执行时间：数据库需要多长时间才能完成工作？

这个指标似乎很明显，但是它经常被忽略。 您不仅要知道数据库收到了多少个请求，还想知道数据库在每个请求上花费了多长时间 。 但是，使用上下文来确定执行时间很重要：对于像InfluxDB这样的时间序列数据库，慢的情况与对于像MySQL这样的关系数据库而言，慢的情况是不一样的。 InfluxDB中的慢速可能意味着毫秒，而MySQL的SLOW_QUERY变量的默认值为十秒。

监视执行时间与改善执行时间不同，因此请注意，如果您的应用程序中有其他问题需要解决，则要花时间进行优化。

并发性：数据库同时执行多少个作业？

一旦知道数据库正在处理多少个请求以及每个请求花费多长时间，就需要增加一层复杂性以开始从这些指标中获得实际价值。

如果数据库收到十个请求，而每个请求都需要十秒钟才能完成，那么数据库是否忙了100秒，十秒钟（或介于两者之间）？ 并发任务的数量改变了数据库资源的使用方式。 当您考虑诸如连接数和线程数之类的问题时，您将开始全面了解数据库指标。

并发还可能影响等待时间，这不仅包括完成任务所需的时间（执行时间），还包括处理任务之前需要等待的时间。

利用率：数据库忙于什么时间？

利用率是吞吐量，执行时间和并发性的最终结果，以确定数据库可用的频率，或者数据库繁忙的频率无法响应请求。

此度量标准对于确定数据库的总体运行状况和性能特别有用。 如果可用于仅80％的时间响应请求，则可以重新分配资源，进行优化或以其他方式进行更改以接近高可用性。

好消息

监视和分析似乎不堪重负，尤其是因为我们大多数人都不是数据库专家，并且我们可能没有时间专门用来理解这些指标。 但好消息是，大部分工作已经为我们完成。 许多数据库都有一个内部性能数据库（Postgres：pg_stats，CouchDB：Runtime_Statistics，InfluxDB：_internal等），该数据库是由数据库工程师设计的，用于监视对该特定数据库重要的指标。 您可以看到慢查询数量之类的事物，或者数据库中每个事件所花费的平均微秒之类的事物。

结论

数据库创建足够的度量标准以使我们所有人长时间忙碌，而内部性能数据库中充满了有用的信息，但并不总是清楚您应该关注哪些度量标准。 从吞吐量，执行时间，并发性和利用率开始，它们为您提供了足够的信息来开始理解数据库中的模式。

您是否正在监视数据库？ 您发现哪些指标有用？ 告诉我怎么回事儿！

接下来要读什么

翻译自: https://opensource.com/article/18/10/database-metrics-matter

数据库健康状况监视