介绍炬鲸 OBSERVE 日志检索引擎：支持 SQL 风格与管道语法、全文检索与字段精确过滤、上下文定位与慢查询诊断，帮助运维秒级定位故障，摆脱传统正则 grep 的低效。
传统日志排查靠 grep + 正则 + 管道，在几百 MB 的日志文件里勉强能用。但业务上量后，日志每天增长到 TB 级，分散在几百个节点上，grep 一个关键词可能要等几分钟，还要自己拼 sed、awk 去过滤字段。更麻烦的是，grep 只能做「包含/不包含」，做不了「按状态码分组统计」「按耗时排序找 Top N」「跨两个条件做关联」，而这些恰恰是定位问题的关键。炬鲸 OBSERVE 的日志检索引擎要解决的，就是把结构化查询的能力还给日志：让运维像写 SQL 一样查日志，而不是靠正则硬扛。
炬鲸的日志检索支持类 SQL 语法，查询对象是一张虚拟的 logs 表。比如要查某个服务最近一小时内状态码为 500 的请求，直接写：
SELECT * FROM logs
WHERE service = 'order-api' AND status = 500
AND timestamp > now() - 1h
ORDER BY timestamp DESC LIMIT 100;常用的聚合也直接支持：SELECT status, COUNT(*) AS cnt FROM logs GROUP BY status ORDER BY cnt DESC，一条语句就能看到错误分布。字段无需预先建索引，引擎会按查询模式自动选择索引路径，首查也有秒级响应。对于不熟悉 SQL 的新人，界面提供了查询构造器，点选字段和条件即可生成语句，降低上手门槛。
除了 SQL，炬鲸还支持管道（Pipe）语法，适合链式过滤的场景，写法更接近运维习惯：
service = 'payment' | status >= 400 | stats count() by uri | sort -count这条管道先过滤出 payment 服务的错误请求，再按 URI 统计错误数并降序排列。管道可以无限串联，每步结果即时预览，方便逐步收窄范围。字段过滤支持精确匹配、范围、前缀、正则、exists/nonexists 判断，JSON 日志里的嵌套字段用点号访问（如 http.headers.user_agent），自动完成类型推断，数字字段可直接比较大小。
查到目标日志只是第一步，下一步是看上下文。炬鲸支持在任意一条日志上「向上/向下翻上下文」，自动关联同一次请求（traceId / requestId）产生的全部日志，还原完整调用链。当检索变慢时，引擎会给出慢查询分析：命中行数、扫描的分片数、时间分布，并建议加时间范围、缩小服务范围或补充过滤条件。生产环境的常见做法是：先用宽时间窗口做聚合找出异常时段，再缩小窗口做精确检索，最后用上下文和链路关联定位根因。这套「聚合 → 精查 → 关联」的路径，比逐条 grep 快一个数量级。