拆解 OBSERVE 日志检索的类 SQL 结构化查询、全文模糊匹配、聚合分析与告警联动四块能力，给出可直接套用的查询语法与索引配置建议，帮团队把定位关键日志的时间从分钟级压到秒级。
日志平台最核心的能力是"把问题查出来"。线上报错时，能不能在几秒内定位到那条关键日志，决定了 MTTR 是五分钟还是两小时。炬鲸 OBSERVE 的日志检索围绕"快、准、省"三个目标设计，下面拆解它的核心能力，并给出能直接套用的查询语法。
传统日志检索只有关键词匹配，要查"状态码 500 且耗时超过 2 秒的请求"，要么靠正则硬凑，要么全量拉下来再 grep。OBSERVE 在采集阶段就把日志解析成结构化字段，写入时对常用字段建索引，查询端直接支持类 SQL 语法：
status_code >= 500 AND service = "order-svc" AND latency_ms > 2000字段类型决定了可用运算符：数值字段支持 >、<、BETWEEN，文本字段支持 =、LIKE、IN，时间字段支持相对时间窗（如 last 5m）。条件之间用 AND/OR/NOT 组合，括号控制优先级，复杂条件不再需要写脚本。
不是每行日志都有规范字段，报错堆栈、请求体这类长文本仍要靠全文检索。OBSERVE 内置倒排索引，支持分词后的模糊匹配 LIKE '%timeout%'，也支持 CONTAINS 'timeout' 做精确子串命中。中文场景默认按词切分，"支付超时"能命中"支付接口超时"，避免逐字匹配漏掉同义表达。对高频查询字段，可以在采集配置里声明为"索引字段"，检索延迟从秒级降到毫秒级。
定位到一条报错日志之后，接下来通常是"这个错误一共发生了多少次、集中在哪些实例"。聚合语法直接嵌在查询后面：
status_code >= 500 | stats count() by service, instance按 service 与 instance 分组计数，再配 top 10、sort by count desc 控制输出。聚合结果可一键切换成柱状图或折线图，一眼看出错误是突发尖峰还是持续劣化。
高频排查条件应保存为"已保存查询"，团队共享一套排查口径，新人不用从零摸索。更关键的是告警联动：把保存查询挂到告警规则上，例如"过去 5 分钟 5xx 超过 50 条"，告警触发时自动带上查询链接和命中日志摘要，收到告警的人点开就是现场，不必重新走一遍排查路径。
一条落地建议：上线前把"按服务、按环境"的基础查询都存好，出事时只改条件，比现场拼语法快得多。