IT小白

这个屌丝很懒，什么也没留下！

热门标签

统一观测丨使用 Prometheus 监控 SQL Server 最佳实践_prometheus + grafana监控sqlserver

作者：IT小白 | 2024-05-01 06:08:59

踩

prometheus + grafana监控sqlserver

SQL Server 简介

SQL Server 是什么？

Microsoft SQL Server 是 Microsoft 推出的关系型数据库解决方案，支持企业 IT 环境中的各种事务处理、商业智能和分析应用程序。Microsoft SQL Server 是市场领先的数据库技术之一。

SQL Server 特点

稳定：针对企业的应用需求，制定出适应环境的解决方案，保证了企业的数据安全和顺利运行。
易用：提供了丰富的图形化管理工具，方便用户快速搭建数据库系统。
兼容：原生适配 Windows 系统，提供丰富的 API 访问。
性能：多种数据库引擎优化算法，支持大量数据查询存储。

SQL Server 核心概念

关系引擎：关系引擎控制存储引擎对数据的处理，并提供 SQL Server 组件来准确确定应如何执行查询。关系引擎由三个主要部分组成。CMD 解析器（parser）主要负责识别和消除语义和语法错误，并生成查询树。优化器（Optimizer）通过消除冗余任务和寻找最优计划，确保所请求的查询响应尽可能高效。查询执行器（Query Executoe）会生成数据获取逻辑的行为。

存储引擎：当数据由存储引擎存储时，会从存储系统（例如 SAN 或磁盘）检索数据。存储引擎中存在三种类型的文件：主文件、辅助文件和日志文件。访问方法（Access Method）负责在缓存管理器和事务日志之间交换数据。缓存管理器（Buffer Manager）缓存当前的执行计划和页。事务管理器（Transaction Manager）使用日志和锁管理器对事务进行管理。

协议层：该层支持客户端-服务器架构以及流。协议层支持 3 种类型的客户端服务器架构：共享内存、TCP/IP、命名管道。

主要适用场景

Microsoft SQL Server 凭借其可视化界面及其所具有的选项和工具，非常适合在关系数据库中存储所有所需的信息，以及轻松管理此类数据。

事务处理：SQL Server 支持事务处理，通过使用事务，用户可以将一系列数据库操作组合在一起，并确保它们要么全部成功执行，要么全部回滚到初始状态。这对于处理银行交易、在线购物和库存管理等需要保证数据一致性的应用程序非常关键。
通过大数据集群对所有数据进行智能分析：SQL Server 提供了强大的数据仓库和商业智能功能。用户可以使用 SSIS 将数据从不同的数据源中提取、转换和加载到数据仓库中。然后，您可以使用 SSAS 创建多维数据模型和立方体，以支持复杂的数据分析和报表需求。此外，SQL Server还提供了数据挖掘和预测分析功能，帮助组织发现数据中隐藏的模式和趋势。
可扩展性：SQL Server 提供了广泛的开发和编程功能，以支持应用程序开发人员。SQL Server 还支持水平和垂直扩展，用户可以在需要时增加服务器硬件资源或在多个服务器之间进行数据分区和分布，以处理大规模数据和高并发负载。SQL Server 允许用户轻松地将数据库管理系统与任何设备和 Azure 服务集成，以获得更好的数据性能和分析能力。

主要版本介绍

SQL Server 2022：安全、性能、可用性等加强；查询存储和智能查询处理

SQL Server 2019：数据虚拟化和大数据群集；智能数据库、智能查询；内存数据库

SQL Server 2017：图形数据库功能、动态管理视图、内存优化等

SQL Server 2016：内存OLTP、Stretch Database、集成 Hadoop 等

监控关键指标

这里介绍监控 SQL Server 服务中常见的关键指标。

系统指标

运行状态

启动状态是监控 SQL Server 最基础的指标，表示 SQL Server 实例是否在正常运行，或是否重启。SQL Server 重启时，没有 commit 的数据会丢失，小概率产生错误。

版本/实例时间

监控启动的 SQL Server 实例是否符合预期，是否是业务要求的 SQL Server 版本。保证 SQL Server 的本地时间与客户端保持一致，否则数据库返回的时间有可能发生错误。

读写指标

页指标

页读写：页是 SQL Server 存储引擎磁盘管理的最小单位，为数据库中的数据文件（.mdf 或 .ndf）分配的磁盘空间可以从逻辑上划分成页（从 0 到 n 连续编号）。磁盘 I/O 操作在页级执行。也就是说，SQL Server 读取或写入所有数据页。因此对页的读写监控尤为重要。通过读写页数量的指标，可以计算出页读写的速率，从而判断 SQL Server 的执行性能。

页在缓存的停留时间：所有数据库软件的主要设计目标之一是尽量减少磁盘 I/O，因为磁盘的读取和写入操作占用大量资源。SQL Server 在内存中生成缓存池，用于保存从数据库读取的页。我们需要监控页在缓存池的生命时长，页在缓存池中存在的时间越长，表示其被命中的可能性越大，也就是说访问该页时不需要访问磁盘。

惰性写（lazy write）：在缓冲区缓存中修改页后，不会将其立即写回磁盘；而是将其标记为“脏”。也就是说在将页物理写入磁盘之前，可以将其逻辑写入多次。在正常运行的情况下，脏页定期地刷入磁盘。而当不断地有新数据写入 SQL Server 且缓存不够用的情况下，大量的脏页会被移出缓存。

检查点（checkpoint）：当检查点发生时，SQL Server 要求刷新所有脏页至磁盘，此时 SQL Server 性能受到一定影响。我们需要监控检查点的速度，确保检查点的刷新速度达到预期。

页错误（page fault）：当页错误发生时，表示需要的页在 SQL Server 可管理的内存区域之外。当遇到页面错误时，程序执行停止并设置为等待状态。操作系统在磁盘上搜索所请求的地址。当找到该页面后，操作系统将其从磁盘复制到空闲 RAM 页面中。操作系统允许程序随后继续执行。

日志成长次数

SQL Server 数据库引擎为数据库中的每个操作写入日志记录，其中包括执行数据修改过程时、创建或删除数据库表或索引时以及每次分配或删除页面后开始或结束 SQL 事务。日志助于在系统或硬件发生故障时将数据库恢复到特定时间点。在具有过多日志记录操作的事务性很强的系统中，SQL Server 事务日志文件将快速增长，直到达到其最大大小，从而生成错误号 9002。如果启用自动增长选项，底层磁盘驱动器将耗尽可用空间。

I/O 等待（stall）时间

I/O 等待时间是一个可用于检测 I/O 问题的指标。SQL Server 将数据写入文件或是从文件读数据时，都需要等待较长的时间，表示为 I/O 等待时间，停顿时间较长表明存在 I/O 问题和磁盘活动繁忙。文件 I/O 属于数据库的关键路径，等待的时间直接反应到客户端读写 SQL Server 的延迟。每个数据库存储的文件不同，使用的存储介质也可能不同。因此除了监控整体的 I/O 等待时间，还需要监控各个数据库的 I/O 等待时间，以便运维做出针对性的优化。

连接指标

在 SQL Server 中，执行查询都依赖于建立和维护客户端连接。当需要维护 SQL Server 的可用性和高性能，监控连接是运维工作的良好入口。当 SQL Server 并发连接数过多可能会使服务器超载。当连接成功建立，不管是否使用连接，每个连接都会产生开销。

存储指标

如上文所述，尽管 SQL Server 将数据存储在磁盘中，但因为缓存池的存在，对 SQL Server 内存使用情况同样要重点关注。默认情况下，SQL Server 根据可用的系统资源动态管理其内存需求。如果 SQL Server 需要更多内存，它会查询操作系统以确定是否有可用的空闲物理内存并使用可用内存。如果操作系统的可用内存不足，SQL Server 会将内存释放回操作系统，直到内存不足的情况得到缓解，或者直到 SQL Server 达到最小服务器内存限制。

性能指标

事务处理速率（TPS）

一个事务是指一个客户端向 SQL Server 发送请求然后 SQL Server 做出反应的过程。客户端在发送查询请求时开始计时，收到 SQL Server 响应后结束计时，以此来计算使用的时间和完成的事务个数。一般的，评价 SQL Server 性能均以每秒钟完成的客户端请求的数量来衡量。

批处理（T-SQL）速率

T-SQL (Transact-SQL) 是 Sybase 和 Microsoft 的一组编程扩展，它为结构化查询语言 ( SQL ) 添加了多种功能，包括事务控制、异常和错误处理、行处理和声明的变量。所有与 SQL Server通信的应用程序都是通过向服务器发送 T-SQL 语句来实现的。

指标详细定义

系统指标

读写指标

连接指标

存储指标

性能指标

监控大盘

我们默认提供了 SQL Server Overview 大盘。

总览

在该 panel 能看到 SQL Server 运行时需要重点关注的指标，在检查 SQL Server 状态时，首先查看总览中是否有异常状态，再检查具体的指标。

启动状态：绿色代表正常运行，红色代表异常运行
内存使用率：使用红黄绿颜色提示，内存使用率在 80% 以下时为绿色，80%～90% 为黄色，90% 以上为红色

资源

内存是 SQL Server 的重点关注硬件资源，通过该 panel 能了解 SQL Server 的内存使用情况：

最大内存：提供内存整体状态
内存使用率/使用量：分析内存使用的趋势
文件扩展次数：分析操作数据量的趋势
数据库文件大小：查看数据库存储的数据量趋势，以及日志的存储量的趋势

性能

在以下 panel 能看到 SQL Server 的运行效率，分为以下三类：

事务处理速率：表示 SQL Server 每秒处理的事务数量，直接影响客户端查询请求的延迟
批处理速率：表示 SQL Server 每秒能处理多少个 Transact-SQL
死锁次数：检测是否发生了因为数据库竞争而发生的死锁，严重影响性能

读写

在以下 panel 能看到 SQL Server 的运行效率：

读写页速率：监控读写页的速率趋势，是否达到预期速率，是否发生波峰波谷等
惰性写速率：定期输入脏页的速率趋势，监控是否平稳
page 生命预期：page 的生命预期越高越好
I/O 等待时间：SQL Server 等待读写文件的等待时间趋势
检查点速率：当发生检查点，需要监控运行速率

数据库 I/O Stall

除了监控 SQL Server 的整体 I/O 等待时间，还需要分别监控数据库的 I/O 等待时间。每个数据库存储的文件不同，存储的磁盘可能不同，需要做出针对性优化方案。

连接

需要随时检查 SQL Server 的连接情况，防止过高的并发影响性能。

总连接数：监控整体连接数的趋势
连接错误数：监控是否有客户端发生了连接错误，保证系统正常运行
各数据库的连接用户：分别监控每个数据库连接的客户端，以及每个客户端发起的连接数量

数据库状态

监控各数据库是否正常运行，下表定义了数据库的状态。

状态	定义
ONLINE	可以对数据库进行访问。即使可能尚未完成恢复的撤消阶段，主文件组仍处于在线状态。
OFFLINE	数据库无法使用。数据库由于显式的用户操作而处于离线状态，并保持离线状态直至执行了其他的用户操作。例如，可能会让数据库离线以便将文件移至新的磁盘。然后，在完成移动操作后，使数据库恢复到在线状态。
RESTORING	正在还原主文件组的一个或多个文件，或正在脱机还原一个或多个辅助文件。数据库不可用。
RECOVERING	正在恢复数据库。恢复进程是一个暂时性状态，恢复成功后数据库将自动处于在线状态。如果恢复失败，数据库将处于可疑状态。数据库不可用。
RECOVERY PENDING	SQL Server 在恢复期间遇到与资源相关的错误。数据库未损坏，但是可能缺少文件，或系统资源限制可能导致无法启动数据库。数据库不可用。需要用户另外执行操作来解决问题，并让恢复进程完成。
SUSPECT	至少主文件组可疑或可能已损坏。在 SQL Server 启动过程中，数据库无法恢复。数据库不可用。需要用户另外执行操作来解决问题。
EMERGENCY	用户更改了数据库，并将其状态设置为 EMERGENCY。数据库处于单用户模式，可以修复或还原。数据库标记为 READ_ONLY，禁用日志记录，并仅限 sysadmin 固定服务器角色的成员访问。EMERGENCY 主要用于故障排除。例如，可以将标记为“可疑”的数据库设置为 EMERGENCY 状态。这样可以允许系统管理员对数据库进行只读访问。只有 sysadmin 固定服务器角色的成员才可以将数据库设置为 EMERGENCY 状态。

关键告警规则

在对 SQL Server 进行告警规则配置时，我们推荐基于以上采集得到的指标，从以下几个方面进行告警规则的配置，分别是运行情况、资源使用情况、连接使用情况。一般来说，我们默认生成影响 SQL Server 正常使用的告警规则，优先级较高。读写速率等与业务相关的告警则由用户自定义。以下是一些推荐的告警规则。

运行情况

SQL Server 停机

SQL Server 停机是 0/1 阈值的告警规则。一般来说，部署在 ACK 等阿里云环境的 SQL Server 服务具有高可用的能力，当一个 SQL Server 实例停止，其他的实例会继续工作。本报警引发的原因可能是所有的 SQL Server 都无法正常启动，或者 Exporter 错误无法获取数据。我们默认设定5分钟内 SQL Server 无法恢复的告警。

SQL Server 重启

SQL Server 重启是 0/1 阈值的告警规则绝大部分情况下 SQL Server 因为有日志的存在，不存在数据丢失的情况。但 SQL Server 重启之后缓存池的内容被清空，造成暂时的查询缓慢。正在执行的事务要回退给客户端，引发一系列暂时的错误，需要客户端重新发起请求。

资源使用情况

内存使用率过高

SQL Server 对服务器内存的使用策略是用多少内存就占用多少内存，不加限制的话有可能把节点的所有内存资源占用。当内存使用率过高，SQL Server 无法正常运行。我们设定的内存使用阈值为：危险值 80%，告警值 90%。当内存使用率为 80% 时，节点高负荷运转，但一般不影响正常使用。当内存长时间使用率为 90% 时，将发出告警，提示运维资源紧缺，尽早处理。

发生死锁

SQL Server 发生死锁是 0/1 阈值的告警规则，不考虑死锁的个数。一系统中遇到的死锁数通常很少，而一旦发生死锁，需要终止被线程执行的当前批处理，回滚死锁牺牲品的事务，回退给客户端一个错误信息。

连接使用情况

发生连接错误

SQL Server 发生连接错误是 0/1 阈值的告警规则。发生该错误可能有很多原因，如：远程主机强制关闭现有连接、超时过期。操作完成之前已过的超时期限或服务器未响应、无法生成 SSPI 上下文等，需要登录数据库并检查日志查看错误原因。

典型问题场景及其排查/解决方法

SQL Server 性能差

SQL Server 性能差体现在事务处理速率（TPS）、批处理（T-SQL）速率低的指标上，性能差有许多原因可能导致，我们需要联系多个指标进行排查。

检查内存使用率

原因：内存不足的情况下，缓存池无法缓存所有的热点数据，导致多次数据访问请求发送到磁盘
排查方法：检查大盘中的内存使用率 panel，检查内存使用率是否一直都很高。检查告警历史，查看是否提示内存资源不足。
解决方法：优化对应节点的磁盘资源；

检查 I/O 等待时间

原因：I/O 等待时间较长表明存在 I/O 问题和磁盘活动繁忙。
排查方法：检查大盘中的 I/O 等待时间 panel，检查 I/O 等待时间是否一直都很高。检查告警历史，查看是否提示内存资源不足。
解决方法：可能是出现大量的波峰访问，突然增大磁盘访问，考虑优化 SQL Server 架构；进一步检查节点的文件系统是否有 I/O 问题；优化对应节点的磁盘资源；

检查日志增长次数

原因：当数据库中执行任何修改时，SQL Server 会将修改写入日志缓冲区，然后将该缓冲区数据写入磁盘。当写入数据过多，日志内容来不及刷入磁盘。
排查方法：检查大盘中日志增长次数的 panel，检查是否有某段时间日志增长次数突然升高。
解决方法：为日志文件选择的磁盘必须在顺序读写吞吐量和最小延迟方面表现良好。

检查检查点（checkpoint）

原因：执行检查点时，SQL Server 将内存中的所有脏页刷新到磁盘，会影响整体数据库性能，给磁盘带来较大压力。
排查方法：查看检查点 panel，查看是否有检查点速率的数据，表示在该时间段进行了检查点操作。
解决方法：设计进行检查点的时机，尽量避开高峰时间段。

监控体系搭建

自建 Prometheus 监控 SQL Server 的痛点

通常我们当前的 SQL Server 都是部署在 ECS 上，因此自建 Prometheus 监控 SQL Server 时，我们将面临的典型问题有：

1. 由于安全、组织管理等因素，用户业务通常部署在多个相互隔离的 VPC，需要在多个 VPC 内都重复、独立部署 Prometheus，导致部署和运维成本高。

2. 每套完整的自建监控系统都需要安装并配置 Prometheus、Grafana、AlertManager 等，过程复杂、实施周期长。

3. 缺少与阿里云 ECS 无缝集成的服务发现（ServiceDiscovery）机制，无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能，则需要使用 Golang 语言开发代码（调用阿里云 ECS POP 接口）、集成进开源 Prometheus 代码、编译打包后部署，实现门槛高、过程复杂、版本升级困难。

4. 常用开源 Grafana SQL Server 大盘不够专业，缺少结合 SQL Server 原理/特征和最佳实践进行深入优化。

5. 缺少 SQL Server 告警指标模板，需要用户自行研究、配置告警项，工作量大。