使用 SQL 进行数据库可靠性监控
数据库症状通常在服务器指标中变得明显之前就出现在应用程序中：调用者等待连接、一个操作指纹减慢、事务回滚、锁定阻止用户工作、副本落后或发布期间迁移失败。结构化应用程序事件将这些结果与响应所需的服务、发布、路由、租户影响和受控错误类别连接起来。
在应用程序边界发出有界事件
为每个数据库操作或逻辑事务记录一个完成事件。使用受控操作名称或标准化指纹代替原始 SQL。仅当支持影响分析时，才包括持续时间、结果、数据库角色、服务、发布和经过隐私审查的帐户标识符。
切勿记录查询参数、连接字符串、凭据、授权数据或不受限制的 SQL 文本。 deadlock、serialization_failure 和 connection_timeout 等错误类别比原始异常消息更安全、更容易分组。
{
"event_name": "database_query_completed",
"query_fingerprint": "checkout.select_with_line_items",
"service": "checkout-api",
"database_name": "app_production",
"status": "success",
"duration_ms": 842,
"rows_returned": 4,
"release": "2026.07.2",
"environment": "production"
}
使用 节点-postgres 集成 或 Prisma 集成 作为起点，然后集中包装器，以便每个操作都使用相同的字段名称、时钟、状态值和脱敏策略。
分开可靠性问题
一种通用的“数据库健康状况”评分隐藏了不同的故障模式。将焦点事件表或稳定事件名称用于：
- 查询完成：持续时间、标准化指纹、行、结果和发布。
- 池状态：活动、空闲、配置最大值、采集等待和超时。
- 事务：逻辑事务标识符、提交或回滚以及受控错误类型。
- 锁等待：阻塞和阻塞指纹、等待持续时间、分辨率和死锁检测。
- 复制或 CDC：消费者、区域、落后的秒数和字节以及当前状态。
- 迁移：迁移标识符、版本、持续时间、终端状态和回滚类别。
数据库可靠性配方收集 包含每个问题的模式、测试查询、确定性结果、可视化、边缘案例、仪表板计划和告警指南。您可以在调整之前在只读 浏览器 SQL 游乐场 中运行包含的灯具。
故意映射OpenTelemetry数据库字段
如果应用程序已发出 OpenTelemetry 数据库跨度，请重用字段的稳定含义，而不是创建竞争词汇表。当前的OpenTelemetry 数据库客户端跨度约定定义了db.system.name、低基数db.operation.name、db.namespace、db.collection.name、db.query.summary和数据库响应状态上下文。他们还警告说，查询文本可能是高基数，需要清理。
实用的结构化事件映射是：
| OpenTelemetry 上下文 | 结构化事件字段 | 复习笔记 |
|---|---|---|
db.system.name |
database_system |
保留有界数据库产品标识符。 |
db.operation.name |
operation_name |
使用受控动词，例如 SELECT 或稳定的客户端操作。 |
db.query.summary |
query_fingerprint |
更喜欢在收集之前生成低基数摘要。 |
db.response.status_code |
database_status_code |
仅当其语义已记录时才保留驱动程序或数据库代码。 |
| 跨度持续时间 | duration_ms |
说明是否包括池获取和网络时间。 |
| 跟踪和跨度上下文 | trace_id、span_id |
使用标识符进行关联，而不复制跨度有效负载。 |
映射并不能自动证明字段是安全的。查询摘要、集合名称、命名空间和响应消息仍然可以在某些系统中公开租户或架构详细信息。检查实际发出的值、上限基数，并默认保留原始查询文本和绑定值。
按顺序调查
从客户可见的持续时间和故障率开始，然后检查池获取是否可以解释延迟。按 p95 持续时间和总查询时间对操作进行排名：执行数千次的中等速度较慢的查询可能会比罕见的异常值消耗更多的应用程序时间。按操作和发布比较 SQLSTATE 或其他受控驱动程序代码，而不是对原始消息进行分组。
如果失败是事务性的，则将预期的可重试回滚与终端错误分开，并单独检查长时间运行的事务类。当涉及并发写入时，检查锁等待和死锁事件。在将池饱和解释为大小调整问题之前，比较连接打开、关闭、获取超时和受影响的请求。在信任下游读取模型之前，除了应用程序观察到的陈旧读取和故障转移结果之外，还要检查副本或 CDC 滞后。将迁移失败与部署时间戳对齐。
不要仅根据利用率来增加连接池限制。更大的池可以将争用转移到数据库中。要求等待呼叫者或超时，确认数据库容量并监视更改。
了解应用程序端边界
这些事件回答哪个应用程序工作流程、版本、区域或面向客户的请求遇到了数据库症状。它们不会取代数据库自己的诊断系统。使用数据库本机工具用于：
- 查询计划、优化器估计、缓冲区和缓存行为、表统计信息以及清理或压缩状态。
- 服务器等待事件、锁定图、活动会话检查、存储延迟和资源饱和度。
- 复制拓扑、预写日志保留、故障转移编排、备份验证和时间点恢复。
- 数据库或安全程序所需的权威审计、访问控制、加密和合规性证据。
在调查过程中结合两个视图：使用结构化应用程序事件来定位影响和所有权，然后使用受限数据库诊断来解释服务器端原因。避免仅仅为了方便连接而将敏感的服务器诊断复制到广泛的分析表中。
将经过验证的查询转化为操作
仪表板应在每个速率旁边保留交易量，使用完整的 UTC 存储桶，并保留从聚合到最近安全事件的路径。告警需要持续的条件、最小数量、所有者和记录的响应。单个缓慢的查询、短暂的滞后峰值或预期的回滚很少能证明页面的合理性。
在依赖查询之前测试合成成功、超时、死锁、重复和延迟事件情况。在仪表板旁边记录事件版本和阈值。 SQL 方法论 描述了自动配方检查； 数据库可靠性用例 将生成的信号连接到实施工作流程。