作者：顧漢傑（執少）
背景
在 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
https://sls.console.aliyun.com/lognext/app/lens/sls?resource=/instancemenuoverview/dashboard/sql