日志、指标、链路打通的统一可观测平台

三类数据，一个查询入口

排查故障最耗时的往往不是找原因，而是在多个系统之间来回切。日志在 A 平台、指标在 B 平台、链路在 C 平台，时间线对不齐，字段对不上。炬鲸 OBSERVE 的做法是把日志、指标、链路放进同一套存储与查询引擎，用统一的标签（app、env、instance）贯穿所有数据，任何一类数据都能顺着标签反查到另外两类。

类 SQL 的日志检索

检索框不是只能输关键字。OBSERVE 的日志查询支持 SQL 风格语法，筛选、聚合、排序、分页一条语句完成：

SELECT status, count(*) AS cnt
FROM access_log
WHERE path = '/api/order/create'
  AND ts > now() - interval 5 minute
GROUP BY status

字段类型在采集时自动识别：时间戳、数值、字符串分别建索引，避免"全文索引一把梭"带来的存储膨胀和慢查询。聚合结果秒级返回，排查接口错误率时不用先把几万条日志导出来再手工统计。

查询之外还有解析管线。采集 Agent 内置 JSON、正则、Grok 解析器，能把一行乱糟糟的 Nginx 或 Java 堆栈拆成结构化字段；多行日志（比如异常堆栈）按首行正则合并，避免一条堆栈被切成几百条独立日志。

指标与告警的降噪

指标支持 Prometheus 拉取和 Agent 推送两种模式。告警规则可以用 PromQL，也可以用更直白的阈值表达式。真正影响体验的是降噪策略：

• 同一节点同一规则 5 分钟内重复触发，只发一条；
• 多条同源告警折叠成一条带计数的事件；
• 恢复通知默认延迟，避免值班人被"恢复"消息半夜吵醒。

通知渠道覆盖企业微信、钉钉、邮件、Webhook，值班表按周轮转，告警的确认、升级、静默都有完整记录和审计轨迹。

链路与日志双向打通

Trace 接入 OpenTelemetry，支持 Span 检索和火焰图。核心是关联设计：每条日志自动带上 trace_id / span_id，从 Trace 里任意一个 Span 都能跳到它产生的日志；反过来，从一条报错日志也能反查整条调用链。慢请求排查不再靠"猜机器、猜时间段"。

仪表盘与权限

内置几十个常用仪表盘模板（服务 QPS、错误率、P99 延迟、主机资源），也能用图表编辑器拖拽自建。权限到项目级：日志、指标、链路分别授权，审计只读角色只能看不能导出，满足多人协作和合规审查的需要。

怎么落地

建议按"日志 → 指标 → 链路"的顺序接入。先跑通日志采集、检索、告警，再上指标，最后接 Trace，三类数据齐了才谈得上关联价值。存储默认冷热分层：热数据走 SSD，冷数据自动归档对象存储，保留周期和查询成本可以同时兼顾。单机即可起步，集群模式支持横向扩容，存储与计算节点分离，容量不够时加节点就行。