你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用指标和警报监视 Azure SQL 数据库
适用于： 
Azure SQL 数据库
可使用 Azure Monitor 指标监视数据库和弹性池资源的消耗和运行状况。 如指标值表明存在潜在问题，可使用警报发送通知。
指标
指标是按固定时间间隔测量的一系列数值，通常使用 count、percent、bytes 等单位来度量。具体取决于指标的性质，可使用聚合（例如total、count、average、minimum、maximum）来计算一段时间内的指标值。 可按维度划分某些指标。 每个维度均为数值提供了更多上下文。
Azure SQL 数据库可用指标的示例包括：CPU percentage、Data space used、Deadlocks、Tempdb Percent Log Used。
有关 Azure SQL 数据库中所有可用指标，请参阅数据库指标和弹性池指标。
注意
有些指标仅适用于特定类型的数据库或弹性池。 每个指标的描述都会包含其使用是否仅限于特定的数据库或弹性池类型（例如 vCore、超大规模、无服务器等）。
在 Azure SQL 数据库门户中，“概述”页面的“监视”选项卡上列出了几个常用指标。 利用这些指标，可以快速评估数据库或弹性池的资源消耗和运行状况。
在“关键指标”下，选择“查看所有指标”或单击图表中的任意位置，以打开指标资源管理器。 在“指标”页中，可查看数据库或弹性池资源的其他所有可用指标。 在指标资源管理器中，可更改图表的时间范围、粒度和聚合类型，更改图表类型，扩展范围以包括其他 Azure 资源的指标，创建警报规则等。此外，还可选择资源菜单中“监视”下的“指标”菜单项打开指标资源管理器。
使用指标监视数据库和弹性池
可使用指标监视数据库和弹性池的资源消耗和运行状况。 例如，可以：
- 根据应用程序工作负载调整数据库或弹性池的大小
- 检测资源消耗量的逐步增加，并主动纵向扩展数据库或弹性池
- 检测性能问题并排除故障
下表列出了 Azure SQL 数据库中常用的指标。
| 指标名称 | 指标 ID | 说明 |
|---|---|---|
| CPU 百分比 | cpu_percent |
此指标表示 CPU 消耗与数据库或弹性池用户工作负载限制之间的关系（以百分比表示）。 有关详细信息，请参阅用户工作负荷和内部进程的资源消耗量。 |
| SQL 实例 CPU 百分比 | sql_instance_cpu_percent |
此指标显示用户和系统工作负载的总 CPU 消耗（以百分比表示）。 由于此指标和“CPU 百分比”指标的衡量标准不同，因此无法直接进行比较。 有关详细信息，请参阅用户工作负荷和内部进程的资源消耗量。 |
| 数据 IO 百分比 | physical_data_read_percent |
此指标表示数据文件 IO 消耗与数据库或弹性池用户工作负载限制之间的关系（以百分比表示）。 有关详细信息，请参阅数据 IO 治理。 |
| 日志 IO 百分比 | log_write_percent |
此指标表示事务日志写入吞吐量消耗与数据库或弹性池用户工作负载限制之间的关系（以百分比表示）。 有关详细信息，请参阅事务日志速率治理。 |
| 工作线程百分比 | workers_percent |
此指标表示工作线程消耗与数据库或弹性池用户工作负载限制之间的关系（以百分比表示）。 |
| DTU 百分比 | dtu_consumption_percent |
此指标表示DTU 消耗与数据库或弹性池用户工作负载限制之间的关系（以百分比表示）。 “DTU 百分比”由其他三个指标得出：“CPU 百分比”、“数据 IO 百分比”和“日志 IO 百分比”。 在任何时间点，“DTU 百分比”均为这三个指标中的最高值。 |
| 已用 CPU | cpu_used |
此指标表示 CPU 消耗与数据库或弹性池用户工作负载限制之间的关系（以 vCore 数量表示）。 有关详细信息，请参阅诊断和排查 Azure SQL 数据库上的高 CPU 问题。 |
| 已用 DTU | dtu_used |
此指标显示数据库或弹性池所使用的 DTU 数量。 |
| 计费的应用 CPU | app_cpu_billed |
对于无服务器数据库，此指标显示计费的计算量（CPU 和内存），以 vCore 秒表示。 有关详细信息，请参阅无服务器计算层中的计费。 |
| 应用 CPU 百分比 | app_cpu_percent |
对于无服务器数据库，此指标表示 CPU 消耗与应用包最大 vCore 限制之间的关系（以百分比表示）。 有关详细信息，请参阅无服务器计算层中的监视。 |
| 应用内存百分比 | app_memory_percent |
对于无服务器数据库，此指标表示内存消耗与应用包最大内存限制之间的关系（以百分比表示）。 有关详细信息，请参阅无服务器计算层中的监视。 |
| 会话计数 | sessions_count |
此指标显示数据库或弹性池已建立的用户会话数。 |
| 已用数据空间 | storage |
对于数据库，此指标显示数据库数据文件所使用的存储空间量。 |
| 已用数据空间 | storage_used |
对于弹性池，此指标显示弹性池中所有数据库的数据文件所使用的存储空间量。 |
| 已分配的数据空间 | allocated_data_storage |
此指标显示数据库的数据文件或弹性池中所有数据库的数据文件占用的存储空间量。 数据文件可能包含空白空间。 因此，“分配的数据空间”通常高于同一数据库或弹性池“使用的数据空间”。 有关详细信息，请参阅管理 Azure SQL 数据库中数据库的文件空间。 |
| 已用数据空间百分比 | storage_percent |
对于数据库，此指标表示数据库中数据文件使用的存储空间量与数据库数据大小限制之间的关系。 对于弹性池，此指标表示弹性池中所有数据库的数据文件所使用的存储空间量与弹性池数据大小限制之间的关系（以百分比表示）。 数据库或弹性池的数据大小限制配置可能低于“最大”数据大小限制。 要查找“最大”数据大小限制，请参阅 vCore 数据库、vCore 弹性池、DTU 数据库和 DTU 弹性池的资源限制。 |
| 分配的数据空间百分比 | allocated_data_storage_percent |
对于弹性池，此指标表示弹性池中所有数据库数据文件占用的存储空间量与池的数据大小限制之间的关系（以百分比表示）。 |
| Tempdb 日志已用百分比 | tempdb_log_used_percent |
此指标表示 tempdb 数据库中事务日志空间的消耗与最大日志大小之间的关系（以百分比表示）。 有关详细信息，请参阅 Azure SQL 数据库中的 tempdb。 |
| 成功的连接数 | connection_successful |
此指标显示与数据库成功建立的连接数。 此指标可拆分为 SslProtocol 和 ValidatedDriverNameAndVersion 两个维度，以查看使用特定加密协议版本或使用特定客户端驱动程序的连接数。 |
| 失败的连接数：系统错误 | connection_failed |
此指标显示由于内部服务错误而导致数据库连接失败的尝试次数。 通常，此类为暂时性错误。 此指标可拆分为 Error 和 ValidatedDriverNameAndVersion 两个维度，以查看由于特定错误或特定客户端驱动程序而导致连接失败的尝试次数。 |
| 失败的连接数：用户错误 | connection_failed_user_error |
此指标显示由于用户可更正的错误（如密码错误或连接被防火墙阻止）而导致数据库连接失败的尝试次数。 此指标可拆分为 Error 和 ValidatedDriverNameAndVersion 两个维度，以查看由于特定错误或特定客户端驱动程序而导致连接失败的尝试次数。 |
| 死锁数 | deadlock |
此指标显示数据库中的死锁次数。 |
| 可用性 | availability |
可用性是基于可用于连接的数据库来确定的。 对于每个一分钟的数据点，可能的值为 100% 或 0%。 有关详细信息，请参阅可用性指标。 |
可用性指标
可用性指标跟踪各个 Azure SQL 数据库级别的可用性。 此功能目前以预览版提供。
可用性粒度为连接中断的一分钟。 可用性是基于可用于连接的数据库来确定的。 如果用户在某一分钟内建立与数据库连接的所有连续尝试均因服务问题而失败，则该分钟即被视为停机时间或不可用。 如果间歇性不可用，则连续不可用的持续时间必须跨越分钟边界，才能被视为停机时间。 通常，显示可用性的延迟不到三分钟。
下面是用于计算每一分钟间隔的可用性的逻辑：
- 如果至少有一个成功的连接，则可用性为 100%。
- 如果所有连接因用户错误而失败，则可用性为 100%。
- 如果没有连接尝试，则可用性为 100%。
- 如果所有连接因系统错误而失败，则可用性为 0%。
- 目前，无服务器计算层尚不支持可用性指标数据，并将显示为 100%。
因此，可用性指标是派生自以下现有指标的复合指标：
- 成功的连接数
- 失败的连接数：用户错误
- 被防火墙阻止
- 失败的连接数：系统错误
用户错误包括因用户配置、工作负载或管理而失败的所有连接。 系统错误包括因与 Azure SQL 数据库服务相关的暂时性问题而失败的所有连接。
由用户配置导致的错误示例：
由用户工作负载导致的错误示例：
由用户管理导致的错误示例：
- 纵向扩展或缩减数据库或弹性池
- 异地复制计划内或计划外故障转移
- 故障转移组计划内或计划外故障转移
- 处于种子设定状态的异地辅助数据库
- 由于时间点还原 (PITR)、长期还原 (LTR) 或从已删除数据库还原而处于还原状态的数据库
- 尚未完成复制的数据库（数据库副本）
警报
可创建警报规则来，在一个或多个指标值超出预期范围时发出通知。
可通过多种方式设置警报规则的范围，以满足自己的需求。 例如，警报规则范围可设置为：
- 单一数据库
- 弹性池
- 资源组中的所有数据库或弹性池
- Azure 区域内订阅中的所有数据库或弹性池
- 所有区域内订阅中的所有数据库或弹性池
警报规则会定期评估回溯周期聚合的指标值，并将其与阈值进行比较。 可配置阈值、评估频率和回溯期周期。
如果触发了警报规则，系统会根据通知首选项（在链接到警报规则的操作组中指定）发出通知。 例如，可接收电子邮件、短信或语音通知。 警报规则还可以触发 Webhook、自动化 Runbook、函数、逻辑应用等操作。可将警报与受支持的 IT 服务管理产品集成。
有关警报的详细信息，请参阅 Azure Monitor 警报概述。 要熟悉指标警报，请查看指标警报、管理警报规则和操作组。
建议的预警规则
警报规则中使用的指标和最佳阈值因 Azure SQL 数据库中各种客户工作负载而异。
下表中推荐的警报提供了入门指导，有助于为 Azure SQL 数据库资源定义最优警报配置。 根据个人要求，配置可能与此示例有所不同。 可使用不同的阈值、评估频率或回溯周期。 可选择创建其他警报，或者针对不同的应用程序和环境使用不同的警报规则配置。
以下为典型警报规则配置的示例：
| 警报规则名称 | 指标（信号） | 警报逻辑 | 何时进行评估 | 建议的严重程度 |
|---|---|---|---|---|
| 用户 CPU 使用率高 | CPU 百分比 | 阈值：Static聚合： Average运算符： Greater than阈值： 90 |
检查间隔：1 minute回溯周期： 10 minutes |
2 - 警告 |
| CPU 总使用率高 | SQL 实例 CPU 百分比 | 阈值：Static聚合： Average运算符： Greater than阈值： 90 |
检查间隔：1 minute回溯周期： 10 minutes |
2 - 警告 |
| 工作线程使用率高 | 工作线程百分比 | 阈值：Static聚合： Minimum运算符： Greater than阈值： 60 |
检查间隔：1 minute回溯周期： 5 minutes |
1 - 错误 |
| 数据 IO 使用量高 | 数据 IO 百分比 | 阈值：Static聚合： Average运算符： Greater than阈值： 90 |
检查间隔：1 minute回溯周期： 15 minutes |
3 - 信息性 |
| 数据空间不足 | 已用数据空间百分比 | 阈值：Static聚合： Minimum运算符： Greater than阈值： 95 |
检查间隔：15 minute回溯周期： 15 minutes |
1 - 错误 |
tempdb 日志空间不足 |
Tempdb 日志已用百分比 | 阈值：Static聚合： Minimum运算符： Greater than阈值： 60 |
检查间隔：1 minute回溯周期： 5 minutes |
1 - 错误 |
| 死锁数 | 死锁数 | 阈值：Dynamic聚合： Total运算符： Greater than阈值敏感度： Medium |
检查间隔：15 minutes回溯周期： 1 hour |
3 - 信息性 |
| 失败的连接数（用户错误） | 失败的连接数：用户错误 | 阈值：Dynamic聚合： Total运算符： Greater than阈值敏感度： Medium |
检查间隔：5 minutes回溯周期： 15 minutes |
2 - 警告 |
| 失败的连接数（系统错误） | 失败的连接数：系统错误 | 阈值：Static聚合： Total运算符： Greater than单位： Count阈值： 10 |
检查间隔：1 minute回溯周期： 5 minutes |
2 - 警告 |
| 异常连接速率 | 成功的连接数 | 阈值：Dynamic聚合： Total运算符： Greater or Less than阈值敏感度： Low |
检查间隔：5 minutes回溯周期： 15 minutes |
2 - 警告 |
某些建议的警报规则使用动态阈值来检测可能需要注意的异常指标模式。 在收集到足够的历史数据以建立正常模式之前，不会触发基于动态阈值的警报规则。 有关详细信息，请参阅指标警报中的动态阈值。
默认情况下，指标警报为有状态， 这意味着一旦触发警报规则，警报只会触发一次。 警报在解决前一直处于 fired 状态，解决后 resolved 才会发送通知。 仅在先前的警报得到解决后，警报规则才会触发新的警报。 有状态警报可避免频繁通知正在发生的情况。 有关有状态和无状态警报的详细信息，请参阅警报和状态。