类 SQL 日志检索：让排查回到你熟悉的语法

排查问题时，你最想要的往往不是「看日志」，而是「快速过滤出那几条相关日志」。传统日志平台的查询语法五花八门，有的用 Lucene、有的用自定义 DSL，换一个平台就要重新学一遍。炬鲸 OBSERVE 的检索直接采用类 SQL 语法，运维和开发的上手成本几乎为零。

为什么选择 SQL 式检索

SQL 是技术人员最通用的语言，不需要记忆新关键字。同时 SQL 的 WHERE、GROUP BY、ORDER BY 天然适合日志分析：过滤、聚合、排序一步到位。更关键的是字段类型是明确的——数字字段可以比较大小、时间字段可以做区间查询，而不是把所有内容都当字符串处理。这决定了查询引擎能用对索引，而不是每次全表扫。

常用查询示例

按服务和时间过滤，只看错误日志：

SELECT * FROM logs
WHERE service = 'order-service'
  AND level = 'ERROR'
  AND timestamp BETWEEN '2025-08-01 00:00:00' AND '2025-08-01 23:59:59'
ORDER BY timestamp DESC
LIMIT 100;

统计各服务一小时内错误率：

SELECT service,
       count_if(level = 'ERROR') AS err_cnt,
       count(*) AS total,
       round(count_if(level = 'ERROR') * 100.0 / count(*), 2) AS err_pct
FROM logs
WHERE timestamp >= now() - interval '1 hour'
GROUP BY service
HAVING count_if(level = 'ERROR') > 0
ORDER BY err_cnt DESC;

定位慢请求并关联 trace_id：

SELECT trace_id, request_path, latency_ms, status_code
FROM logs
WHERE latency_ms > 1000
  AND timestamp >= now() - interval '30 minute'
ORDER BY latency_ms DESC;

字段提取与索引

类 SQL 检索要快，关键在于日志字段化。建议在采集侧用正则或 JSON 解析，把 request_path、status_code、latency_ms、trace_id 这些字段显式提出来，而不是塞进 message 里事后全文匹配。对半结构化日志，在配置里声明字段类型：数字和布尔字段走倒排索引之外的范围索引，范围查询才能命中索引加速。

检索性能建议

三个实用原则：一是尽量带时间条件，缩小扫描范围；二是避免在 WHERE 里对字段做函数运算（如 to_lower(service)），否则索引失效；三是高频查询用预聚合或物化视图替代实时全量扫描。如果单次查询返回超过 1 万行，说明过滤条件可能太宽，先加约束再下钻。