作者：顾汉杰（执少）
布景
在 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 恳求，造成客户很多无效资源的耗费。这种状况下，各部分往往缺少一个大局视角了解资源的全体运用状况和过错占比，咱们经过优化主张能够让用户从大局视角了解到最需求优化和管理的方面，协助提效。
最终，别忘了，以上一切 SQL 质量目标和视图还能够经过筛选 Project 和 Logstore 来实现不同维度的细化剖析，期望您运用愉快并对您有用。
相关链接：
[1]CloudLens for SLS
