类 SQL 检索：排查日志不用再学一套查询语言

日志系统最劝退人的往往不是采集，而是查询。ES 的 Lucene 语法、Loki 的 LogQL，每换一套工具就得重新背一遍操作符。炬鲸 OBSERVE 在检索上做了一个决定：直接用类 SQL 的 WHERE 条件，让写过 SQL 的人一分钟上手。

用 WHERE 语法查日志

检索页的查询条件就是一条 WHERE 子句。想查 user-service 的错误日志，直接写：

level="ERROR" and serviceName="user-service"

支持的字段覆盖排障常用维度：level、serviceName、projectName、companyName、content、traceId、threadName、host、nodeIp，以及链路侧的 code、cost、path、method、query。运算符支持 =、!=、>、>=、<、<=、LIKE，条件之间用 and / or 连接。几个常用例子：

level="WARN" and serviceName="order-service"

content LIKE "%timeout%"

cost>=3000

traceId="abc123..."

相比 Elasticsearch 的 query DSL，条件更短，也更容易在群里向同事口述排查意图。

白名单校验：防注入但不阉割查询

类 SQL 查询最大的顾虑是注入。炬鲸 OBSERVE 做了两层约束：

1. 列名白名单：WHERE 里出现的字段必须在白名单内，传一个不存在的列会直接报错，而不是落到数据库执行。
2. 关键字禁用：SELECT、INSERT、UPDATE、DROP、UNION、GROUP BY 等一律拒绝。

编译时会把条件参数化，值走占位符而不是字符串拼接，从根上避免拼接注入。这意味着检索页可以直接对租户开放，不用把查询能力藏起来。

AI 助手：自然语言转查询条件

不会写条件也没关系。检索页的 AI 助手默认用规则引擎把自然语言翻译成 WHERE：

• 「查 user-service 的错误日志」→ level="ERROR" and serviceName="user-service"
• 「查包含 timeout 的日志」→ content LIKE "%timeout%"
• 「查 5xx」→ 提示同时到 Tracing 页用 code>=500

如果配置了外部模型（AI_API_URL / AI_API_KEY），规则识别不出来时会回落给大模型补全条件，返回前同样过一遍白名单校验。

和监控大盘、链路打通

检索不是孤立的。检索页顶部能切时间窗、按服务聚合看时间线，点开单条日志能看到解析好的字段——时间、级别、线程名、traceId。拿到 traceId 可以直接切到 Tracing 页看这条请求的耗时、状态码、路径和请求/响应体。「检索 → 聚合 → 单条 → traceId 下钻」这条链路，是排障最顺手的顺序。下一篇文章讲怎么用 5 分钟把日志接进来。