OneUptime SQL 监控SQL Query Monitor实战指南只读查询探测、多层安全防线与告警标准配置【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南围绕 OneUptime 的 SQL 查询监控功能展开讲解它如何从探针Probe按计划执行只读 SQL 查询、依据结果行数、标量值、执行耗时、查询错误触发告警的完整机制覆盖支持的数据引擎、安全模型、配置项、查询编写规范、Monitor Secret 密码保护与告警标准Criteria搭建。读完本文你将掌握在 OneUptime 中安全落地「跑一条查询、必要时开一个 Incident」这一典型场景的完整实操方案并理解其探针侧实现的底层原理。功能定位为「执行查询并触发告警」而生SQL 监控SQL Query Monitor解决的是这样一个经典可观测性需求在业务数据库上按固定计划执行一条只读 SQL 查询并根据查询结果判断系统是否健康。典型用例包括最近五分钟内订单取消数量突然飙升消息队列表堆积过大某条关键业务记录意外消失。由于查询是在探针Probe上执行的而探针部署在你的网络内部OneUptime 云端永远不需要直连你的数据库。更关键的是完整的结果集永远不会离开探针——探针只回传一个小的、有边界的投影projection结果。支持的数据库引擎SQL 监控官方支持以下三种引擎默认端口与仓库中 SqlDatabaseType.ts 的getDefaultPort()实现一致引擎默认端口PostgreSQL5432MySQL3306Microsoft SQL Server1433官方测试覆盖仅限上述三种。使用相同网络协议与 SQL 方言的 MySQL 兼容、PostgreSQL 兼容引擎通常也能工作但不在官方测试范围之内。从源码看探针分别使用pg、mysql2/promise、mssql三个纯 JS 驱动连接对应引擎见 SqlMonitor.ts。工作原理探针回传的紧凑投影每次检查时探针完成以下动作连接数据库 → 在只读上下文中执行你的查询 → 最多读取有界行数 → 向 OneUptime 回传一个紧凑投影。随后你配置的监控标准Criteria针对该投影进行求值。探针只回传五类数据行数Row Count——查询返回的行数受「最大行数」参数约束标量值Scalar Value——第一行第一列的值这是SELECT COUNT(*)类查询最自然的取值首行First Row——第一行以「列/值」键值对形式呈现用于在检查摘要中提供上下文执行耗时Execution Time——查询执行耗时单位毫秒查询错误Query Error——查询失败时经过净化的错误消息。完整结果集永远不会发送到 OneUptime因此客户数据不会被复制进 OneUptime 的存储。这一点在源码中有直接印证shapeRows()方法只从结果中抽取rowCount、第一列的scalarValue和firstRow并在行数超过上限时置isRowsCapped标志见 SqlMonitor.ts。安全模型多层防线保障生产库安全在生产数据库上执行一条由客户提供的 SQL 属于敏感操作因此 SQL 监控在设计上就是只读的并叠加了多层控制1. 最小权限数据库用户首要防线始终使用一个专用的、只读的数据库用户连接该用户仅能访问查询所需的表。这是最重要的一层控制具体创建方法见下文「创建只读数据库用户」。2. 只读执行执行期强制在PostgreSQL和MySQL上探针会开启READ ONLY事务无论查询文本如何任何写入包括可写 CTE都会被拒绝Microsoft SQL Server没有只读事务探针改为在**始终回滚rollback**的事务中执行查询。源码印证PostgreSQL 执行器会执行START TRANSACTION READ ONLY并配合SET LOCAL statement_timeout见 SqlMonitor.tsMySQL 执行器同样执行START TRANSACTION READ ONLY见 SqlMonitor.tsSQL Server 执行器则始终在finally中回滚事务见 SqlMonitor.ts。3. 单语句 白名单首关键字查询必须是单条语句且以SELECT、WITH、VALUES、TABLE之一开头。堆叠语句如SELECT 1; DROP TABLE …以及写入/DDL 会在探针连接数据库之前被拒绝。校验是**注释感知comment-aware和字符串字面量感知string-literal-aware**的藏在注释或字符串里的关键字不会蒙混过关。源码印证SqlQueryValidator.getRejectionReason()会先剥离块注释/行注释stripComments和字符串字面量stripStringLiterals再检查分号、首 token 白名单ALLOWED_FIRST_TOKENS以及禁用关键字列表FORBIDDEN_CONSTRUCTS覆盖insert/update/delete/merge/truncate/drop/alter/...、远程数据源访问openquery/openrowset/...、系统存储过程xp_/sp_等见 SqlMonitor.ts。测试用例覆盖了「注释中隐藏写入关键字」「字符串中的分号不误判」「无分号的 T-SQL 第二条语句」等绕过手法见 SqlMonitor.test.ts。4. 语句超时每条查询都有硬性时间上限执行过久的查询会被取消。源码中 PostgreSQL 同时设置了服务端statement_timeout与客户端query_timeout兜底statementTimeoutInMs 2000MySQL/SQL Server 则用withHardTimeout()做客户端硬超时竞速见 SqlMonitor.ts。5. 有界行数探针最多读取「最大行数 1」行多出的 1 行用于检测截断从而限制探针内存占用与回传载荷大小。PostgreSQL 用游标FETCH FORWARD maxRows1SqlMonitor.ts、MySQL 用流式读取到上限即销毁连接SqlMonitor.ts、SQL Server 用SET ROWCOUNT maxRows1SqlMonitor.ts。6. 凭据脱敏数据库错误在存储前会被净化——密码以及任何连接字符串都会被脱敏凭据不会泄漏到错误消息中。源码中sanitizeError()会替换密码子串、其余 secret 型连接字段、postgres:///mysql://等连接 URI以及password形式的连接串键值对见 SqlMonitor.ts并有对应单测验证SqlMonitor.test.ts。前置条件一台探针Probe且对数据库主机和端口具备网络可达性。数据库可从公网访问时可用 OneUptime 托管探针运行在你网络内部时使用自托管探针。一个只读数据库用户及连接信息主机、端口、数据库名、用户名、密码。配置 SQL 监控新建一个监控器选择SQL QuerySQL 查询作为监控类型然后填写连接信息数据库类型Database Type——PostgreSQL、MySQL 或 Microsoft SQL Server选择类型会联动填充默认端口主机Host——探针可达的数据库主机例如db.internal端口Port——数据库端口数据库名Database Name——执行查询的目标数据库用户名Username——只读、最小权限的数据库用户密码Password——强烈建议用 Monitor Secret 以{{monitorSecrets.name}}形式引用而非明文输入见下文SQL 查询SQL Query——要执行的只读查询见「编写查询」使用 SSL/TLSUse SSL/TLS——开启后通过 TLS 连接若数据库使用自签名证书可同时关闭验证服务器证书Verify server certificate。高级选项参数默认值最大值说明连接超时ms1000030000等待建立连接的时间语句超时ms1500060000查询可运行时长的硬上限最大行数Max Rows1001000从数据库回读行数的上限这些上限在服务端/探针侧强制执行用户无法在界面上调得更高——常量与钳位函数定义于 MonitorStepSqlMonitor.tsexecute()在执行前会对三个参数分别调用clampSqlStatementTimeoutInMs、clampSqlConnectionTimeoutInMs、clampSqlMaxRows做归一化见 SqlMonitor.ts。补充SQL Server Windows 集成身份验证对于 Microsoft SQL Server官方英文文档还支持Windows 集成身份验证Windows Integrated Authentication模式以探针进程的运行身份建立受信连接此模式下用户名与密码字段被忽略、不会传给驱动。由于探针需要一个被域信任的身份此模式应使用自托管探针Windows 探针以拥有只读 SQL Server 登录的域账户运行探针服务Linux / macOS 探针为 SQL Server 所在域配置 Kerberos并给探针进程提供有效票据如通过 keytab。官方 Linux 探针镜像内置 Microsoft ODBC Driver 18、unixODBC 与 Kerberos 客户端需将 Kerberos 配置与票据缓存挂载进容器并保证探针进程可读非默认路径时设置KRB5_CONFIG或KRB5CCNAME。驱动探测细节探针宿主机需装有 Microsoft ODBC Driver。官方探针镜像内置ODBC Driver 18自托管/自定义探针会自动探测宿主机上注册的最新ODBC Driver N for SQL Server例如装的是 Driver 17 就用 17无需严格匹配 18。如需固定某个版本可设置探针环境变量SQL_SERVER_ODBC_DRIVER为精确驱动名。该逻辑实现于 SqlMonitor.tsresolveSqlServerOdbcDriver的解析顺序为环境变量覆盖 → 宿主机最新已注册驱动 → 镜像内置默认值。另外还需满足SQL Server 有合适的MSSQLSvc服务主体名SPN、探针与域控时钟同步、探针通过该 SPN 覆盖的主机名解析并访问 SQL Server。受信身份只需授予监控查询所需的数据库权限。编写查询查询必须是单条只读语句以SELECT、WITH、VALUES、TABLE之一开头。允许结尾有一个分号多条语句不允许。由于查询每次检查都会执行请保持查询廉价且有界优先使用索引列和窄时间窗口。以下是三种引擎下「统计最近取消订单数」的等价写法-- 统计近期取消订单PostgreSQL SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at NOW() - INTERVAL 5 minutes;-- 同样的思路MySQL SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at NOW() - INTERVAL 5 MINUTE;-- 同样的思路Microsoft SQL Server SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at DATEADD(minute, -5, GETDATE());对COUNT(*)类查询有一个容易混淆的点计数既可作为行数Row Count此时恒为1因为只返回一行也可作为标量值Scalar Value计数本身取自第一列。要针对「有多少」告警应比较标量值。这也与shapeRows()的实现一致标量值取第一行的第一列见 SqlMonitor.ts。使用 Monitor Secret 保护密码为避免数据库密码以明文存储在监控器上可以创建 Monitor Secret 并在密码字段中引用它进入 OneUptime 仪表盘 →Monitors → Settings → Secrets → Create Monitor Secret创建一个 secret例如dbPassword并授权该监控器访问它在监控器的密码字段填入{{monitorSecrets.dbPassword}}。OneUptime 在服务端解析该 secret 之后才会把配置下发给探针。OneUptime 永远不会替你创建这些 secret——是否引用由你决定。从源码看MonitorStepSqlMonitor的敏感字段密码以及其他任意字段都可包含{{monitorSecrets.name}}引用见 MonitorStepSqlMonitor.ts而sanitizeError()之所以脱敏用户名/主机/库名正是因为它们同样可能由 secret 支撑。配置告警标准Criteria添加标准来决定监控器何时被视为在线Online、降级Degraded或离线Offline。SQL 监控支持以下检查项SQL Is Online——数据库是否可达且查询是否成功SQL Query Row Count——返回的行数可与大于、小于、等于等操作符比较SQL Query Scalar Value——第一行第一列的值两侧均看似数值时按数值比较否则按字符串比较这是COUNT(*)类查询应使用的检查项SQL Query Execution Time (in ms)——查询耗时用于捕捉数据库变慢SQL Query Error——查询错误消息可在其为空/非空或匹配特定字符串时告警JavaScript Expression——用自定义 JavaScript 表达式实现完全控制参见 JavaScript Expressions。示例取消量突增时告警沿用上面的查询降级Degraded标准——SQL Query Scalar Value大于10离线Offline标准——SQL Query Scalar Value大于50或SQL Is Online为false。将告警标准关联到值班策略On-Call Policy即可在条件满足时通知到正确的人。创建只读数据库用户始终使用专用的只读用户连接数据库。以下是三种引擎的示例-- PostgreSQL CREATE USER oneuptime_ro WITH PASSWORD a-strong-password; GRANT CONNECT ON DATABASE orders TO oneuptime_ro; GRANT USAGE ON SCHEMA public TO oneuptime_ro; GRANT SELECT ON ALL TABLES IN SCHEMA public TO oneuptime_ro; -- 覆盖未来新建的表 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO oneuptime_ro;-- MySQL CREATE USER oneuptime_ro% IDENTIFIED BY a-strong-password; GRANT SELECT ON orders.* TO oneuptime_ro%; FLUSH PRIVILEGES;-- Microsoft SQL Server CREATE LOGIN oneuptime_ro WITH PASSWORD a-strong-password; USE orders; CREATE USER oneuptime_ro FOR LOGIN oneuptime_ro; ALTER ROLE db_datareader ADD MEMBER oneuptime_ro;注意事项查询每次检查都会执行务必保持廉价使用索引、窄时间窗口并把语句超时作为最后兜底只回传行数、第一格标量与首行——设计查询时把你要告警的值放在第一列若结果因超过最大行数被截断检查摘要会标记为 capped封顶。仅在必要时调大最大行数更大的结果集会占用更多探针内存写入与 DDL 永远被拒绝。如果你需要测试写入路径这不是本监控器的用途优先使用 Monitor Secret 而非明文密码确保凭据在静态时加密存储。总而言之OneUptime 的 SQL 查询监控通过「探针侧执行 只读事务 单语句白名单 超时与行数边界 凭据脱敏」的多层设计把「对生产数据库执行客户查询」这一高风险操作约束在安全范围内同时以紧凑投影的方式保证客户数据不出内网配合行数、标量值、耗时、错误与 JavaScript 表达式等检查项可以快速搭建覆盖数据库健康度与关键业务指标的可观测告警。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime SQL 监控（SQL Query Monitor）实战指南：只读查询探测、多层安全防线与告警标准配置
OneUptime SQL 监控SQL Query Monitor实战指南只读查询探测、多层安全防线与告警标准配置【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南围绕 OneUptime 的 SQL 查询监控功能展开讲解它如何从探针Probe按计划执行只读 SQL 查询、依据结果行数、标量值、执行耗时、查询错误触发告警的完整机制覆盖支持的数据引擎、安全模型、配置项、查询编写规范、Monitor Secret 密码保护与告警标准Criteria搭建。读完本文你将掌握在 OneUptime 中安全落地「跑一条查询、必要时开一个 Incident」这一典型场景的完整实操方案并理解其探针侧实现的底层原理。功能定位为「执行查询并触发告警」而生SQL 监控SQL Query Monitor解决的是这样一个经典可观测性需求在业务数据库上按固定计划执行一条只读 SQL 查询并根据查询结果判断系统是否健康。典型用例包括最近五分钟内订单取消数量突然飙升消息队列表堆积过大某条关键业务记录意外消失。由于查询是在探针Probe上执行的而探针部署在你的网络内部OneUptime 云端永远不需要直连你的数据库。更关键的是完整的结果集永远不会离开探针——探针只回传一个小的、有边界的投影projection结果。支持的数据库引擎SQL 监控官方支持以下三种引擎默认端口与仓库中 SqlDatabaseType.ts 的getDefaultPort()实现一致引擎默认端口PostgreSQL5432MySQL3306Microsoft SQL Server1433官方测试覆盖仅限上述三种。使用相同网络协议与 SQL 方言的 MySQL 兼容、PostgreSQL 兼容引擎通常也能工作但不在官方测试范围之内。从源码看探针分别使用pg、mysql2/promise、mssql三个纯 JS 驱动连接对应引擎见 SqlMonitor.ts。工作原理探针回传的紧凑投影每次检查时探针完成以下动作连接数据库 → 在只读上下文中执行你的查询 → 最多读取有界行数 → 向 OneUptime 回传一个紧凑投影。随后你配置的监控标准Criteria针对该投影进行求值。探针只回传五类数据行数Row Count——查询返回的行数受「最大行数」参数约束标量值Scalar Value——第一行第一列的值这是SELECT COUNT(*)类查询最自然的取值首行First Row——第一行以「列/值」键值对形式呈现用于在检查摘要中提供上下文执行耗时Execution Time——查询执行耗时单位毫秒查询错误Query Error——查询失败时经过净化的错误消息。完整结果集永远不会发送到 OneUptime因此客户数据不会被复制进 OneUptime 的存储。这一点在源码中有直接印证shapeRows()方法只从结果中抽取rowCount、第一列的scalarValue和firstRow并在行数超过上限时置isRowsCapped标志见 SqlMonitor.ts。安全模型多层防线保障生产库安全在生产数据库上执行一条由客户提供的 SQL 属于敏感操作因此 SQL 监控在设计上就是只读的并叠加了多层控制1. 最小权限数据库用户首要防线始终使用一个专用的、只读的数据库用户连接该用户仅能访问查询所需的表。这是最重要的一层控制具体创建方法见下文「创建只读数据库用户」。2. 只读执行执行期强制在PostgreSQL和MySQL上探针会开启READ ONLY事务无论查询文本如何任何写入包括可写 CTE都会被拒绝Microsoft SQL Server没有只读事务探针改为在**始终回滚rollback**的事务中执行查询。源码印证PostgreSQL 执行器会执行START TRANSACTION READ ONLY并配合SET LOCAL statement_timeout见 SqlMonitor.tsMySQL 执行器同样执行START TRANSACTION READ ONLY见 SqlMonitor.tsSQL Server 执行器则始终在finally中回滚事务见 SqlMonitor.ts。3. 单语句 白名单首关键字查询必须是单条语句且以SELECT、WITH、VALUES、TABLE之一开头。堆叠语句如SELECT 1; DROP TABLE …以及写入/DDL 会在探针连接数据库之前被拒绝。校验是**注释感知comment-aware和字符串字面量感知string-literal-aware**的藏在注释或字符串里的关键字不会蒙混过关。源码印证SqlQueryValidator.getRejectionReason()会先剥离块注释/行注释stripComments和字符串字面量stripStringLiterals再检查分号、首 token 白名单ALLOWED_FIRST_TOKENS以及禁用关键字列表FORBIDDEN_CONSTRUCTS覆盖insert/update/delete/merge/truncate/drop/alter/...、远程数据源访问openquery/openrowset/...、系统存储过程xp_/sp_等见 SqlMonitor.ts。测试用例覆盖了「注释中隐藏写入关键字」「字符串中的分号不误判」「无分号的 T-SQL 第二条语句」等绕过手法见 SqlMonitor.test.ts。4. 语句超时每条查询都有硬性时间上限执行过久的查询会被取消。源码中 PostgreSQL 同时设置了服务端statement_timeout与客户端query_timeout兜底statementTimeoutInMs 2000MySQL/SQL Server 则用withHardTimeout()做客户端硬超时竞速见 SqlMonitor.ts。5. 有界行数探针最多读取「最大行数 1」行多出的 1 行用于检测截断从而限制探针内存占用与回传载荷大小。PostgreSQL 用游标FETCH FORWARD maxRows1SqlMonitor.ts、MySQL 用流式读取到上限即销毁连接SqlMonitor.ts、SQL Server 用SET ROWCOUNT maxRows1SqlMonitor.ts。6. 凭据脱敏数据库错误在存储前会被净化——密码以及任何连接字符串都会被脱敏凭据不会泄漏到错误消息中。源码中sanitizeError()会替换密码子串、其余 secret 型连接字段、postgres:///mysql://等连接 URI以及password形式的连接串键值对见 SqlMonitor.ts并有对应单测验证SqlMonitor.test.ts。前置条件一台探针Probe且对数据库主机和端口具备网络可达性。数据库可从公网访问时可用 OneUptime 托管探针运行在你网络内部时使用自托管探针。一个只读数据库用户及连接信息主机、端口、数据库名、用户名、密码。配置 SQL 监控新建一个监控器选择SQL QuerySQL 查询作为监控类型然后填写连接信息数据库类型Database Type——PostgreSQL、MySQL 或 Microsoft SQL Server选择类型会联动填充默认端口主机Host——探针可达的数据库主机例如db.internal端口Port——数据库端口数据库名Database Name——执行查询的目标数据库用户名Username——只读、最小权限的数据库用户密码Password——强烈建议用 Monitor Secret 以{{monitorSecrets.name}}形式引用而非明文输入见下文SQL 查询SQL Query——要执行的只读查询见「编写查询」使用 SSL/TLSUse SSL/TLS——开启后通过 TLS 连接若数据库使用自签名证书可同时关闭验证服务器证书Verify server certificate。高级选项参数默认值最大值说明连接超时ms1000030000等待建立连接的时间语句超时ms1500060000查询可运行时长的硬上限最大行数Max Rows1001000从数据库回读行数的上限这些上限在服务端/探针侧强制执行用户无法在界面上调得更高——常量与钳位函数定义于 MonitorStepSqlMonitor.tsexecute()在执行前会对三个参数分别调用clampSqlStatementTimeoutInMs、clampSqlConnectionTimeoutInMs、clampSqlMaxRows做归一化见 SqlMonitor.ts。补充SQL Server Windows 集成身份验证对于 Microsoft SQL Server官方英文文档还支持Windows 集成身份验证Windows Integrated Authentication模式以探针进程的运行身份建立受信连接此模式下用户名与密码字段被忽略、不会传给驱动。由于探针需要一个被域信任的身份此模式应使用自托管探针Windows 探针以拥有只读 SQL Server 登录的域账户运行探针服务Linux / macOS 探针为 SQL Server 所在域配置 Kerberos并给探针进程提供有效票据如通过 keytab。官方 Linux 探针镜像内置 Microsoft ODBC Driver 18、unixODBC 与 Kerberos 客户端需将 Kerberos 配置与票据缓存挂载进容器并保证探针进程可读非默认路径时设置KRB5_CONFIG或KRB5CCNAME。驱动探测细节探针宿主机需装有 Microsoft ODBC Driver。官方探针镜像内置ODBC Driver 18自托管/自定义探针会自动探测宿主机上注册的最新ODBC Driver N for SQL Server例如装的是 Driver 17 就用 17无需严格匹配 18。如需固定某个版本可设置探针环境变量SQL_SERVER_ODBC_DRIVER为精确驱动名。该逻辑实现于 SqlMonitor.tsresolveSqlServerOdbcDriver的解析顺序为环境变量覆盖 → 宿主机最新已注册驱动 → 镜像内置默认值。另外还需满足SQL Server 有合适的MSSQLSvc服务主体名SPN、探针与域控时钟同步、探针通过该 SPN 覆盖的主机名解析并访问 SQL Server。受信身份只需授予监控查询所需的数据库权限。编写查询查询必须是单条只读语句以SELECT、WITH、VALUES、TABLE之一开头。允许结尾有一个分号多条语句不允许。由于查询每次检查都会执行请保持查询廉价且有界优先使用索引列和窄时间窗口。以下是三种引擎下「统计最近取消订单数」的等价写法-- 统计近期取消订单PostgreSQL SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at NOW() - INTERVAL 5 minutes;-- 同样的思路MySQL SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at NOW() - INTERVAL 5 MINUTE;-- 同样的思路Microsoft SQL Server SELECT COUNT(*) AS cancelled FROM orders WHERE status CANCELLED AND created_at DATEADD(minute, -5, GETDATE());对COUNT(*)类查询有一个容易混淆的点计数既可作为行数Row Count此时恒为1因为只返回一行也可作为标量值Scalar Value计数本身取自第一列。要针对「有多少」告警应比较标量值。这也与shapeRows()的实现一致标量值取第一行的第一列见 SqlMonitor.ts。使用 Monitor Secret 保护密码为避免数据库密码以明文存储在监控器上可以创建 Monitor Secret 并在密码字段中引用它进入 OneUptime 仪表盘 →Monitors → Settings → Secrets → Create Monitor Secret创建一个 secret例如dbPassword并授权该监控器访问它在监控器的密码字段填入{{monitorSecrets.dbPassword}}。OneUptime 在服务端解析该 secret 之后才会把配置下发给探针。OneUptime 永远不会替你创建这些 secret——是否引用由你决定。从源码看MonitorStepSqlMonitor的敏感字段密码以及其他任意字段都可包含{{monitorSecrets.name}}引用见 MonitorStepSqlMonitor.ts而sanitizeError()之所以脱敏用户名/主机/库名正是因为它们同样可能由 secret 支撑。配置告警标准Criteria添加标准来决定监控器何时被视为在线Online、降级Degraded或离线Offline。SQL 监控支持以下检查项SQL Is Online——数据库是否可达且查询是否成功SQL Query Row Count——返回的行数可与大于、小于、等于等操作符比较SQL Query Scalar Value——第一行第一列的值两侧均看似数值时按数值比较否则按字符串比较这是COUNT(*)类查询应使用的检查项SQL Query Execution Time (in ms)——查询耗时用于捕捉数据库变慢SQL Query Error——查询错误消息可在其为空/非空或匹配特定字符串时告警JavaScript Expression——用自定义 JavaScript 表达式实现完全控制参见 JavaScript Expressions。示例取消量突增时告警沿用上面的查询降级Degraded标准——SQL Query Scalar Value大于10离线Offline标准——SQL Query Scalar Value大于50或SQL Is Online为false。将告警标准关联到值班策略On-Call Policy即可在条件满足时通知到正确的人。创建只读数据库用户始终使用专用的只读用户连接数据库。以下是三种引擎的示例-- PostgreSQL CREATE USER oneuptime_ro WITH PASSWORD a-strong-password; GRANT CONNECT ON DATABASE orders TO oneuptime_ro; GRANT USAGE ON SCHEMA public TO oneuptime_ro; GRANT SELECT ON ALL TABLES IN SCHEMA public TO oneuptime_ro; -- 覆盖未来新建的表 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO oneuptime_ro;-- MySQL CREATE USER oneuptime_ro% IDENTIFIED BY a-strong-password; GRANT SELECT ON orders.* TO oneuptime_ro%; FLUSH PRIVILEGES;-- Microsoft SQL Server CREATE LOGIN oneuptime_ro WITH PASSWORD a-strong-password; USE orders; CREATE USER oneuptime_ro FOR LOGIN oneuptime_ro; ALTER ROLE db_datareader ADD MEMBER oneuptime_ro;注意事项查询每次检查都会执行务必保持廉价使用索引、窄时间窗口并把语句超时作为最后兜底只回传行数、第一格标量与首行——设计查询时把你要告警的值放在第一列若结果因超过最大行数被截断检查摘要会标记为 capped封顶。仅在必要时调大最大行数更大的结果集会占用更多探针内存写入与 DDL 永远被拒绝。如果你需要测试写入路径这不是本监控器的用途优先使用 Monitor Secret 而非明文密码确保凭据在静态时加密存储。总而言之OneUptime 的 SQL 查询监控通过「探针侧执行 只读事务 单语句白名单 超时与行数边界 凭据脱敏」的多层设计把「对生产数据库执行客户查询」这一高风险操作约束在安全范围内同时以紧凑投影的方式保证客户数据不出内网配合行数、标量值、耗时、错误与 JavaScript 表达式等检查项可以快速搭建覆盖数据库健康度与关键业务指标的可观测告警。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考