一文看懂如何做好 SQL 质量监控

作者：顾汉杰（执少）

背景

在 SLS 中，用户可以通过 SQL 对日志数据（结构化、半结构化、无结构化）进行查询和分析。随着用户对 SQL 使用程度的不断加深，越来越多的用户希望了解自己使用 SQL 分析时的服务反馈（如请求量、成功率、数据量等等），以便对数据和分析行为进行精细管理或优化治理。

“现在我这个 Project 的 SQL 并发是多少？”

“奇怪，我 SQL 请求并不多，为什么会有这么多 SQL 请求，是哪个业务线（Logstore）用的？”

“我想了解我在 SLS 中使用 SQL 分析的整体情况，请问有什么监控数据或日志可以查看？

这些都是来自 SLS 真实用户的声音，可以看出用户对于自身 SQL 分析行为的监控和质量管理有着较强的需求。

为了提升用户 SLS SQL 的使用体验，我们提供了用户级 SQL 质量监控功能，希望能够帮助用户直观、清晰地了解自身使用 SQL 的情况。

通过 CloudLens 开启使用

我们将此功能集成于 CloudLens for SLS [ 1] 中，用户可以轻松开启该服务，并对 SQL 质量进行监控和管理。除此之外，CloudLens for SLS 还帮助您监控和管理所有 SLS 相关资源（包括采集接入、读写操作、作业、配额、SQL、计费等等），以提升您对日志服务资产的管理效率、快速了解其消耗情况。

服务开启后按照引导开通全局日志，数据同步可能需要一定时间（首次开启大约 10min），请耐心等待，随后在「报表中心 / SQL 质量监控」中即可查看完整 SQL 质量监控。

功能总览

总体上，我们为用户提供了 5 个维度的 SQL 质量监控：

SQL 健康分和使用报告

主要展示用户整体使用 SQL 的健康度和总体情况（包含一些很有意思的指标）。
SQL 服务指标

主要描述用户使用 SQL 时的整体服务情况，以便用户对服务现状有整体了解。
SQL 运行指标

主要描述 SQL 内部运行时的指标，以便用户了解自身 SQL 的实际处理表现和吞吐。
SQL Pattern

主要刻画用户提交的 SQL 范式（根据 SLS 原生 sql parse 解析并去除参数差异），以便用户识别出具有相同特征的分析业务，做相关管理和监控。
SQL 质量优化和建议

主要描述 SQL 请求的服务质量，包括用户侧错误，给出相关建议，推荐用户进行优化改善。

关于指标的说明：

所有指标以分钟为粒度，根据以下 4 个基础字段（Category 除外）作为分组维度，聚合分析计算得出。
所有指标目前不包含 JDBC 接入和 ScheduledSQL 的流量请求。
所有指标为当前状态，随产品形态和系统发展，未来可能增减指标，以帮助用户更明确的反馈服务情况。
所有指标的解释权归 SLS 所有。

SQL 健康分和使用报告

通过「SQL 健康分」，反馈用户使用 SLS SQL 服务的总体质量，进而驱动用户去做服务治理和质量优化。

UserStory： 很多时候，用户在使用 SQL 的过程中，常常由于 AK 失效/授权过期/索引未建立 / SQL 语法错误等各种客观原因，而发起了大量的无效 SQL 请求，不仅占用了 SQL 请求并发配额，对于用户自身服务器资源也是无效的消耗。通过 SQL 健康分，用户可以一目了然了解自己使用 SLS SQL 的健康情况，并进行针对的优化或者治理。

同时，我们提供了一份用户最近的「SQL 使用报告」。在这里，用户可以从全局视角看到当前账户下使用 SQL 的活跃 Project、活跃 Logstore、SQL 请求量、常用请求代理、SQL 整体表现（包括延时、数据量、数据行数、返回行数、预估并发量等）

SQL 服务指标

通过「SQL 服务指标」，用户可以了解自己使用 SQL 时更详细的服务质量，包括每分钟的请求 PV 数、平均延时、请求代理分布以及延时四分位的分布水平。

通过这些时序图的趋势展示，用户可以非常直观地了解自己在哪些时段出现过 SQL 请求量飙升或延时毛刺，以便辅助分析业务问题。将时间线拉长到 1 天，用户也可以了解到自己业务高峰一般处在 1 天中的什么时刻，延时毛刺是否与请求量相关等等。

SQL 运行明细指标

通过「SQL 运行明细指标」，用户可以更进一步地了解当前 SQL 执行情况，包括并发请求（预估）、各阶段平均延时、每分钟的处理数据量和处理行数，以及细化到 Logstore 的 SQL 热力分布情况等等。

关于并发请求（预估）和各阶段平均延时的说明

首先，回答大家一个问题：为什么要有 SQL 并发控制？

SLS SQL 执行涉及到分布式计算，计算过程消耗较多算力资源，而我们的服务是面向云上多租用户的，为了保证资源的公平使用，我们为每个租户设置了合理的并发额度。

每个用户会配置 1 个并发队列和 1 个排队队列，当用户提交一条 SQL 时，会进行并发控制，若并发队列有空余，则直接运行；若并发队列满，则排队等待；若排队队列再满，则并发超限报错。

UserStory： 有些用户当并发请求过高时，查询延时会有明显增高，这又是怎么回事呢？

其实，了解了上面的并发控制模型，就不难理解这一点：当一条 SQL 提交时，如果并发队列满，该 SQL 将在排队队列中等待，直到并发队列中最短的一条 SQL 执行完才能腾出空位来，这个时间间隔称为“QueuedTime（排队时间）”，所以，当出现排队时，SQL 端到端的总延时可能会增高，这其中包含了队列中等待在途 Query 完成的排队时间。

因此，为了让大家在日常使用过程中，更合理地使用并发，以及遇到并发超限时进行合理地优化处理，我们提供了并发请求（预估）和各阶段平均延时指标以供用户参考。

SQL Pattern 分析

我们提供「SQL Pattern分析」视图，将 SQL 中的变量参数进行了泛化，提炼出 SQL 语义特征，用户可以据此了解哪些特征 SQL 请求占比特多、执行特慢、处理量特大等等。

UserStory： 很多时候，用户提交的 SQL 是通过程序化方式以模板+参数的方式渲染生成最终 SQL 语句，有可能多条不同的 SQL 对应的其实是同一个业务，为了让用户能更加洞悉业务特征，快速识别出存在问题或异常的业务 SQL。

String sql = String.format("* | SELECT sum(price) from log where category = %s", category_id);
// request sql to sls...

质量优化和建议

用户可以通过「质量优化和建议」了解到自己使用 SQL 的整体请求成功/失败占比、错误码的分布，我们还会给出具体的优化建议。

UserStory： 很多时候，由于企业组织结构不同，在 SLS 上的资源可能分布在不同的团队，有可能运维部门负责资源的创建（如 Project/Logstore/索引），而数据部门负责数据的使用（如发起 SQL 请求），业务上的快速迭代和变化常常会导致某个 Logstore 已不存在、AK 失效、权限不足等，而数据部门却可能还一直在持续地发起大量的 SQL 请求，造成客户大量无效资源的消耗。这种情况下，各部门往往缺乏一个全局视角了解资源的整体使用情况和错误占比，我们通过优化建议可以让用户从全局视角了解到最需要优化和治理的方面，帮助提效。