StarRocks 如何監(jiān)控 SQL

作者：crossoverJie 2025-11-14 08:11:10

在 StarRocks 中審計(jì)日志記錄了所有用戶的查詢和連接信息，理論上我們只需要對(duì)這些日志進(jìn)行分析就可以得到相關(guān)的慢 SQL，高 CPU、高內(nèi)存的 SQL 信息。

StarRocks 監(jiān)控中有一個(gè)很關(guān)鍵的指標(biāo)，就是針對(duì)慢 SQL 的監(jiān)控。

類似于這樣的監(jiān)控界面：

由于這些數(shù)據(jù)都是存放在日志文件里的我們想把他拿到 grafna 里展示的話得額外處理下。

結(jié)構(gòu)化日志

默認(rèn)情況^[1]下審計(jì)日志是以文本格式輸出的，當(dāng)然我們也可以使用一個(gè)審計(jì)插件^[2]，將審計(jì)日志寫(xiě)入到一張單獨(dú)的表里供后續(xù)分析，也可以實(shí)現(xiàn)類似的效果。

具體使用可以參考官方文檔^[3]：

圖片

這里我們選擇一個(gè)更簡(jiǎn)單的方法，我們可以將日志輸出為 JSON 格式，然后再將其結(jié)構(gòu)化，為每個(gè)字段創(chuàng)建索引，存入到單獨(dú)的日志服務(wù)里。

圖片

由于我們使用了云廠商的日志服務(wù)能力，只需要為這個(gè)日志文件（fe/log/fe.audit.log）配置一個(gè)采集服務(wù)，然后為其中的字段創(chuàng)建索引即可。

圖片

這樣我們可以就可以通過(guò)云廠商提供的 grafna 插件將這里的日志作為一個(gè)數(shù)據(jù)源集成到 grafna 中。

之后就可以在 grafna 中直接使用云廠商提供的查詢語(yǔ)法來(lái)查詢我們剛才的審計(jì)日志了。

IsQuery:"true"|SELECT QueryId,Stmt,Time,CpuCostNs,MemCostBytes,ScanBytes,ScanRows,ReturnRows ORDER BY CpuCostNs DESC LIMIT 10

比如這樣的查詢語(yǔ)句含義是：限制為查詢的 SQL（還有其他的 alter delete 等 SQL）、按照 CPU 耗時(shí)排序。

CREATE TABLE starrocks_audit_db__.starrocks_audit_tbl__ (
  `queryId` VARCHAR(64) COMMENT "查詢的唯一ID",
  `timestamp` DATETIME NOT NULL COMMENT "查詢開(kāi)始時(shí)間",
  `queryType` VARCHAR(12) COMMENT "查詢類型（query, slow_query, connection）",
  `clientIp` VARCHAR(32) COMMENT "客戶端IP",
  `user` VARCHAR(64) COMMENT "查詢用戶名",
  `authorizedUser` VARCHAR(64) COMMENT "用戶唯一標(biāo)識(shí)，既user_identity",
  `resourceGroup` VARCHAR(64) COMMENT "資源組名",
  `catalog` VARCHAR(32) COMMENT "數(shù)據(jù)目錄名",
  `db` VARCHAR(96) COMMENT "查詢所在數(shù)據(jù)庫(kù)",
  `state` VARCHAR(8) COMMENT "查詢狀態(tài)（EOF，ERR，OK）",
  `errorCode` VARCHAR(512) COMMENT "錯(cuò)誤碼",
  `queryTime` BIGINT COMMENT "查詢執(zhí)行時(shí)間（毫秒）",
  `scanBytes` BIGINT COMMENT "查詢掃描的字節(jié)數(shù)",
  `scanRows` BIGINT COMMENT "查詢掃描的記錄行數(shù)",
  `returnRows` BIGINT COMMENT "查詢返回的結(jié)果行數(shù)",
  `cpuCostNs` BIGINT COMMENT "查詢CPU耗時(shí)（納秒）",
  `memCostBytes` BIGINT COMMENT "查詢消耗內(nèi)存（字節(jié)）",
  `stmtId` INT COMMENT "SQL語(yǔ)句增量ID",
  `isQuery` TINYINT COMMENT "SQL是否為查詢（1或0）",
  `feIp` VARCHAR(128) COMMENT "執(zhí)行該語(yǔ)句的FE IP",
  `stmt` VARCHAR(1048576) COMMENT "SQL原始語(yǔ)句",
  `digest` VARCHAR(32) COMMENT "慢SQL指紋",
  `planCpuCosts` DOUBLE COMMENT "查詢規(guī)劃階段CPU占用（納秒）",
  `planMemCosts` DOUBLE COMMENT "查詢規(guī)劃階段內(nèi)存占用（字節(jié)）",
  `pendingTimeMs` BIGINT COMMENT "查詢?cè)陉?duì)列中等待的時(shí)間（毫秒）",
  `candidateMVs` varchar(65533) NULL COMMENT "候選MV列表",
  `hitMvs` varchar(65533) NULL COMMENT "命中MV列表",
  `warehouse` VARCHAR(128) NULL COMMENT "倉(cāng)庫(kù)名稱" 
)

審計(jì)數(shù)據(jù)里的信息非常豐富，可以組合出各種查詢條件。

比如：

? 限制查詢時(shí)間大于多少，可以只查詢慢 SQL

? 根據(jù)內(nèi)存占用排序

? 執(zhí)行失敗的 SQL

大家可以按需選擇。

開(kāi)源替換

如果沒(méi)有使用云廠商，一些開(kāi)源組件也能滿足以上需求：

? 結(jié)構(gòu)化存儲(chǔ)日志

? 根據(jù)字段創(chuàng)建索引

? 類 SQL 查詢

? 支持 grafna 數(shù)據(jù)源，方便做可視化

服務(wù)名稱	索引能力	查詢語(yǔ)言	Grafana 支持	優(yōu)點(diǎn)	缺點(diǎn)	適用場(chǎng)景
Elasticsearch^[4]	全文索引、倒排索引	Elasticsearch DSL（類 SQL）	官方插件，集成完善	功能強(qiáng)大、生態(tài)成熟、搜索能力強(qiáng)	資源占用大、運(yùn)維成本高、JVM 調(diào)優(yōu)復(fù)雜	大規(guī)模日志搜索、全文檢索
Loki^[5]	僅索引標(biāo)簽（Label）	LogQL	原生支持，集成最佳	輕量級(jí)、成本低、與 Grafana 生態(tài)完美	全文搜索能力弱、不適合復(fù)雜查詢	中小規(guī)模、成本敏感、Grafana 用戶
ClickHouse^[6]	主鍵索引、二級(jí)索引、跳數(shù)索引	標(biāo)準(zhǔn) SQL	官方插件支持	查詢速度極快、擅長(zhǎng) OLAP、支持復(fù)雜聚合	不適合高頻更新、需要結(jié)構(gòu)化設(shè)計(jì)	結(jié)構(gòu)化日志分析、大數(shù)據(jù)量聚合查詢
OpenSearch^[7]	全文索引、倒排索引	OpenSearch DSL（兼容 ES）	兼容 ES 插件	完全開(kāi)源、無(wú)商業(yè)限制、功能與 ES 相近	社區(qū)相對(duì)較小、資源占用仍較大	ES 的開(kāi)源替代方案

內(nèi)部日志支持 JSON

StarRocks 還有定期執(zhí)行的內(nèi)部 SQL，目前這些 SQL 也是會(huì)記錄日志，但只是記錄的純文本，無(wú)法很好的對(duì)其進(jìn)行監(jiān)控。

我們就出現(xiàn)過(guò)內(nèi)部 SQL 大量占用了 CN 的 CPU 資源，將它的執(zhí)行時(shí)間控制到 00:00:00~08:00:00 之后就會(huì)好很多了，只是不會(huì)影響到白天的業(yè)務(wù)使用。

/**  
 * The start time of day when auto-updates are enabled */@ConfField(mutable = true)  
publicstaticStringstatistic_auto_analyze_start_time="00:00:00";  

/**  
 * The end time of day when auto-updates are enabled */@ConfField(mutable = true)
publicstaticStringstatistic_auto_analyze_end_time="23:59:59";

主要是這兩個(gè)配置控制的時(shí)間范圍，修改之后 CN CPU 使用有明顯的下降：

圖片