SQL Server是企业级广泛应用的数据库，通过简单的Prometheus exportor可以很容易地监控它。与所有数据库一样，SQL Server也有许多故障点，例如事务延迟或数据库中连接过多。本文介绍如何使用Prometheus监视SQL Server，包括常用的监控指标，从用户或消费者的角度提供实用的服务视图，包括检测可能直接影响应用程序行为的潜在问题。

sql_exporter

为了使用Prometheus监视SQL Server，我们将使用sql_export，这是SQL Server的特定exporter，它公开度一系列量指标，以便prometheus能够获得它们。此外，此导出器的灵活性支持根据业务创建任何自定义指标，因此它几乎可以监视所有内容。

假设你已经安装了Prometheus和sql_exporter，现在开始使用Prometheus监视SQL Server，让我们看看应该关注哪些指标并创建一些警报。

主要监控指标

启动状态

你可以使用up指标检查数据库是否启动并运行。让我们创建PromQL警报来检查数据库是否已启动：

Up {job="mssql"} == 0

死锁指标

你可以使用mssql_deadlocks指标检查数据库中是否没有死锁。当两个具有排他锁的进程想要访问相同的资源时，就会发生死锁。发生死锁情况，系统性能会显著下降，管理员需要关注并进行优化调整。

让我们创建警报查询，如果死锁的数量在一分钟的时间范围内增加到五个：

Increase (mssql_deadlocks[1m]) > 5

磁盘空间

磁盘上没有足够的空间将使数据库崩溃。为此，你需要使用mssql_disk_space_used_bytes_total指标，并结合mssql_disk_space_available_bytes_total，它将返回磁盘使用情况和可用空间总量（以字节为单位）。

让我们创建警报查询，如果数据库使用的可用空间超过85%：

sum(mssql_disk_space_available_bytes_total{job=~"mssql"})/sum(mssql_disk_space_total_bytes_total{job=~"mssql"})  < 0.15

创建自定义指标

还可以创建自定义查询来监视与业务有关的指标。例如，你可以创建度量来获取电子商务交易中今天的总发票金额。

为此，您需要在mssql-metrics-config 配置中为收集器创建新的数据条目：

apiVersion: v1
kind: ConfigMap
metadata:namespace: mssqlname: mssql-metrics-configlabels:app: mssql-exporter
data:sql_custom_invoice.collector.yml:collector_name: sql_custom_invoicemetrics:- metric_name: total_invoiced_todaytype: gaugehelp: 'Get total amount invoiced today.'values: [invoiced_today_sum]query_ref: total_invoiced_today_queryqueries:- query_name: total_invoiced_today_queryquery: | SELECT sum(total) AS invoiced_today_sum FROM Invoice where invoiceDate=CAST(GETDATE() AS date);

然后在 sql_exporter.yml 文件中修改目标收集器，指定 sql_custom_invoice:

target:collectors: [mssql_standard, sql_custom_invoice]

确保自定义收集器文件名称以collector.yml结尾。

其他常用指标

连接相关指标

• 指标：连接数（Number of Connections）

  • 解释：这是指当前与 SQL Server 数据库建立的连接数量。连接数的监控很重要，因为过多的连接可能会耗尽数据库服务器的资源。例如，如果数据库配置的最大连接数是 1000，当连接数接近或超过这个阈值时，新的连接请求可能会被拒绝或者等待很长时间才能建立连接。

  • 预警设置：可以设置一个阈值，比如连接数达到最大连接数的 80% 时触发预警。这样系统运维人员就可以提前采取措施，如检查是否有异常的连接或者考虑增加数据库服务器的连接资源配置。

  • 连接数预警（假设连接数指标名为sql_server_connections，最大连接数为 1000，阈值设为 80%）

    查询语句：

    sql_server_connections > 1000 * 0.8
    

    这条 PromQL 语句检查sql_server_connections指标的值是否大于最大连接数（1000）的 80%（即 800）。如果满足这个条件，就会触发预警，表示连接数可能过多。

• 指标：连接成功率（Connection Success Rate）

  • 解释：这是成功建立连接的数量与连接尝试总数的比率。它反映了数据库服务对连接请求的响应能力。如果连接成功率下降，可能表示网络问题、数据库配置错误或者服务器负载过高。例如，在网络波动时，客户端与数据库服务器之间的连接可能会频繁中断，导致连接成功率降低。

  • 预警设置：当连接成功率低于 95%（这个值可以根据实际情况调整）时发出预警，提醒运维人员检查网络、服务器状态以及数据库的配置参数。

  • 连接成功率预警（假设连接成功率指标名为sql_server_connection_success_rate，阈值设为 95%）

    查询语句：

    sql_server_connection_success_rate < 0.95
    

    当sql_server_connection_success_rate指标的值小于 95%（0.95）时，这个查询条件就会满足，触发预警，表明连接成功率较低，可能存在网络或数据库配置等问题。

性能相关指标

• 指标：查询执行时间（Query Execution Time）

  • 解释：记录每个查询从开始执行到结束所花费的时间。长查询执行时间可能是由于查询语句复杂、索引缺失、数据量过大或者服务器性能瓶颈等原因导致的。例如，一个没有合适索引的复杂关联查询可能会花费很长时间来执行，影响系统的响应速度。

  • 预警设置：对于关键业务查询，可以设置一个最大允许执行时间。如果查询执行时间超过这个阈值，如某个重要报表查询超过 5 秒（具体时间根据业务需求确定），就触发预警，促使运维人员优化查询或者数据库性能。

  • 查询执行时间预警（假设关键业务查询执行时间指标名为sql_server_query_execution_time，关键业务查询最大允许执行时间为 5 秒）

    查询语句：

    sql_server_query_execution_time > 5
    

    此查询检查sql_server_query_execution_time指标的值是否大于 5 秒。如果大于这个阈值，就意味着关键业务查询执行时间过长，触发预警，提醒运维人员优化查询。

• 指标：CPU 使用率（CPU Utilization）

  • 解释：显示 SQL Server 进程占用服务器 CPU 资源的百分比。高 CPU 使用率可能是因为大量复杂查询同时执行、数据库内部的高负载操作（如索引重建）或者存在性能不佳的存储过程。例如，在数据仓库环境中，进行大规模数据加载和聚合操作时，CPU 使用率可能会显著上升。

  • 预警设置：当 CPU 使用率超过 80%（可根据服务器硬件资源和业务负载情况调整）持续一段时间（如 1 分钟），就发出预警，提醒运维人员检查是否有异常的查询或者考虑升级服务器硬件。

  • CPU 使用率预警（假设 CPU 使用率指标名为sql_server_cpu_utilization，阈值设为 80%，持续时间 1 分钟）

    查询语句：

    `sql_server_cpu_utilization > 0.8` `[1m]`
    

    这里sql_server_cpu_utilization指标的值大于 80%（0.8），并且这个条件持续 1 分钟（[1m]）就会触发预警。这有助于避免因短暂的 CPU 高峰而误报警，只有当 CPU 高使用率持续一段时间时才发出警告，提醒运维人员关注服务器性能。

• 指标：内存使用率（Memory Usage）

  • 解释：反映 SQL Server 使用服务器内存的情况。SQL Server 会使用内存来缓存数据和执行计划等，合理的内存使用可以提高性能，但过高的内存使用率可能导致服务器内存不足，出现性能问题甚至系统崩溃。例如，如果数据库缓存了大量不常用的数据，而没有及时释放内存，可能会使内存使用率过高。

  • 预警设置：当内存使用率达到 90%（具体数值根据服务器内存大小和业务需求确定）时触发预警，运维人员可以检查内存分配情况，优化数据库内存管理策略或者增加服务器内存。

  • 内存使用率预警（假设内存使用率指标名为sql_server_memory_usage，阈值设为 90%）

    查询语句：

    `sql_server_memory_usage > 0.9`
    

    当sql_server_memory_usage指标的值大于 90%（0.9）时，就会触发预警，提示运维人员内存使用率过高，需要检查内存分配情况等。

事务相关指标

• 指标：事务吞吐量（Transaction Throughput）

  • 解释：指单位时间内成功完成的事务数量。它体现了数据库处理事务的能力。在高并发的业务场景下，如电商平台的订单处理系统，高事务吞吐量是保证系统高效运行的关键。如果事务吞吐量下降，可能表示数据库出现性能问题或者业务量发生变化。

  • 预警设置：设定一个基准事务吞吐量，当实际吞吐量低于这个基准的 80%（可根据业务高峰和低谷期调整）时，触发预警，以便运维人员查找原因，如是否有锁竞争或者资源瓶颈。

  • 事务吞吐量预警（假设事务吞吐量指标名为sql_server_transaction_throughput，基准事务吞吐量设为 100，阈值设为 80%）

    查询语句：

    sql_server_transaction_throughput < 100 * 0.8
    

    此查询检查sql_server_transaction_throughput指标的值是否小于基准事务吞吐量（100）的 80%（即 80）。如果满足这个条件，就触发预警，说明事务吞吐量可能下降，需要查找原因。

• 指标 ：事务回滚率（Transaction Rollback Rate）

  • 解释：这是回滚事务数量与总事务数量的比率。较高的事务回滚率可能表示应用程序逻辑错误、数据冲突或者数据库故障。例如，在并发更新同一数据时，如果没有正确的事务隔离级别和锁机制，可能会导致事务冲突和回滚。
  • 预警设置：当事务回滚率超过 5%（根据业务对数据准确性的要求调整）时，发出预警，运维人员可以检查应用程序代码和数据库事务配置。

• 事务回滚率预警（假设事务回滚率指标名为sql_server_transaction_rollback_rate，阈值设为 5%）

​ 查询语句：

	sql_server_transaction_rollback_rate > 0.05

​ 当sql_server_transaction_rollback_rate指标的值大于 5%（0.05）时，就会触发预警，表明事务回滚率较高，可能存在应 用程序或数据库事务配置问题。