产品动态 2026-10-19 4 分钟阅读炬鲸团队

SQL 风格日志检索：像查数据库一样查日志

介绍炬鲸 OBSERVE 的 SQL 风格日志检索：用 WHERE、GROUP BY、聚合函数直接查询海量日志，支持全文检索、字段过滤、时间窗口聚合，配合冷热分层把存储成本降下来。

为什么要把日志当数据库查

传统日志检索要么是 grep 式的关键词匹配，要么是写死条件的界面点选。前者快但弱，后者灵活但慢，一旦遇到「最近 5 分钟错误率最高的前 10 个接口」这类问题，两种方式都很别扭。

炬鲸 OBSERVE 把日志做成了可查询的表。采集时自动抽取 timestamp、level、service、trace_id、host、message 等字段并建立索引，之后你可以像写 SQL 一样对日志做过滤、排序和聚合。运维同学不需要重新学一套查询语言，会写 SQL 就能上手。

查询语法速查

基础的 WHERE 过滤支持常见的比较和逻辑运算：

SELECT * FROM logs
WHERE level = 'ERROR'
  AND service = 'order-service'
  AND timestamp BETWEEN '2026-10-19 10:00:00' AND '2026-10-19 11:00:00'
ORDER BY timestamp DESC
LIMIT 100

message 字段默认走全文索引，支持短语与通配：

SELECT * FROM logs
WHERE message CONTAINS 'connection refused'

聚合用 GROUP BY 配合 COUNT、AVG、P99 等函数。下面这条统计每个服务最近一小时的分位延迟：

SELECT service, COUNT(*) AS total, AVG(latency) AS avg_ms, P99(latency) AS p99_ms
FROM logs
WHERE timestamp > NOW() - INTERVAL 1 HOUR
GROUP BY service
ORDER BY p99_ms DESC

三个高频场景

排查单次请求：用 trace_id 串起整条调用链的所有日志，按时间排序还原执行过程。

SELECT timestamp, level, service, message
FROM logs
WHERE trace_id = 'a1b2c3d4'
ORDER BY timestamp

错误率巡检：按服务聚合错误占比，一眼看出哪个服务在恶化。

SELECT service,
       SUM(CASE WHEN level = 'ERROR' THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS error_rate
FROM logs
WHERE timestamp > NOW() - INTERVAL 15 MINUTE
GROUP BY service
HAVING error_rate > 5

关键字告警回溯：某条业务异常日志出现后，反查它前后 30 秒的上下文，还原事件全貌。

性能与成本

日志量大，全量建索引成本不低。OBSERVE 默认只对 message 建倒排索引，对高频字段建列索引，同时按时间分片。查询超过 7 天的数据会自动路由到冷存储，检索延迟略有上升，但每 GB 成本下降约 70%。生产环境建议：线上日志保留 30 天，其中近 7 天热存储，其余自动归档冷存储。

免费试用联系我们