从采集到检索：日志管理全链路能力拆解

采集：先解决"数据进得来"

日志平台的第一道坎是采集。业务系统散在各处，格式五花八门，接入方式不统一，后面再强的检索都无从谈起。炬鲸 OBSERVE 支持三类采集方式：部署在主机上的 Agent、兼容 Filebeat/Fluentd 的采集插件，以及原生 OTLP 接收。Kubernetes 环境用 DaemonSet 部署采集组件，自动发现 Pod 并采集 stdout 日志，容器重建也不丢数据。

选型上给一条建议：容器化程度高的团队优先用 OTLP 直采，省去中间一层；传统虚机和物理机环境用 Agent 就近采集，由 Agent 做缓冲、压缩和断点续传，网络抖动时也不丢日志。采集端只做两件事——尽力收上来、失败重试，别把解析负担压到应用侧。

解析：把半结构化的日志变成字段

原始日志是一堆文本，只有拆成字段才能检索和聚合。平台支持三种解析方式：JSON 自动解析、正则/Grok 提取、键值对（key=value）解析。原则是"采集时尽量保留原始内容，解析时再定字段"，原始 message 字段始终保留，方便回溯。

字段设计有讲究：高频检索的字段（trace_id、user_id、service、level）要建索引，只偶尔查的字段（如详细堆栈）可以只存不建索引。字段名尽量统一——一个团队里 level 有人叫 severity、有人叫 log_level，检索时要写三遍条件，统一命名能省掉大量沟通成本。

索引与检索：查询为什么快

检索快不快，取决于索引怎么建。平台对字符串字段建倒排索引，对数值和时间字段建列式索引，两者分开，全文检索走倒排、范围统计走列式，各干各的。

查询用 SQL 风格语法，运维不用学新语言。一个典型例子：

SELECT level, count(*)
FROM logs
WHERE service = 'order-service'
  AND ts >= now() - 1h
  AND message LIKE '%timeout%'
GROUP BY level

也支持正则、模糊匹配和 histogram() 时间分桶。查询慢的时候，先看是不是没走索引——条件里用了前导通配符（%xxx）或对字段做了函数运算，索引就失效了。

冷热分层与成本控制

日志量涨起来后，成本是最大顾虑。平台按数据冷热分层：近 7 天的热数据放 SSD，秒级查询；更早的数据自动压缩归档到廉价存储，查询稍慢但可查。分层规则可配，比如错误日志保留更久、DEBUG 日志尽早淘汰。

成本优化三件事：一是按需采集，只收 ERROR/WARN 或指定业务日志；二是采样，超高频的访问日志按比例抽；三是定留存周期，过了周期自动清理。日志的价值在"可追溯"，而不是"无限留存"，把预算花在真正需要查的数据上。