云联信息：日志检索用得好，排查能快十倍

一、先定字段再建索引

把常用查询字段建索引：时间、请求ID、状态码、用户ID、接口路径。全字段建索引成本高且没必要，按查询习惯选。

二、结构化比纯文本好查

日志打成JSON，每个字段独立，查询时能精确过滤。纯文本只能靠关键词匹配，查到一堆无关结果，还得人工筛。

三、请求ID要贯穿全链路

一个请求从网关到应用再到数据库，每段日志都带同一个请求ID。出问题时用一个ID把所有相关日志串起来，比按时间猜快得多。

四、分级存储降低成本

最近七天的日志放热存储，方便快速检索；更早的转冷存储或者归档。全部放热存储，费用会失控。

五、采样要谨慎

为了省成本做日志采样，可能恰好把出问题的那条采样掉。错误日志不建议采样，正常流水日志可以按比例采。

六、设置保留期限

日志按合规要求和实际需要设保留期，过期自动清理。无限期保留既贵又慢，检索时还要在大量无用数据里翻。

七、常用查询存成模板

把高频查询保存成模板：查某接口的错误、查某用户的全部请求、查慢请求分布。下次直接调用，不用重新写语法。

八、告警和日志联动

关键错误日志触发告警，告警内容里附上检索链接，点开就能看到上下文。这一步能把平均定位时间压缩很多。

九、日志内容要注意脱敏

手机号、身份证、银行卡不要明文写进日志。确需记录时做掩码处理。日志泄露的后果，往往比故障本身更严重。

日志量要预估

每天产生多少G日志，直接决定存储成本。上线前按请求量估算：每请求一行日志、每行几百字节，乘以日请求量就是日增量。估完再决定采样比例。

关键字段要能联合检索

单看请求ID没用，要能同时按用户、接口、状态码组合过滤。设计日志格式时就把这几个字段结构化，后面查询才灵活。

告警不要只看错误数

错误数突然下降也可能是异常，比如服务挂了没有请求。结合请求量一起判断，避免漏报。

日志权限要分级

日志里可能有用户信息和业务数据，不是所有人都该看全部。按角色分配查询权限，敏感字段做脱敏处理。

日志和业务指标对照看

日志里的错误数、慢请求数与业务的下单量、成功率对照，能看出技术与业务之间的因果关系。只看技术指标，容易忽略真正影响收入的问题。

云联信息【资深云服务专家微信：cloud7591】更倾向于先用小规格实例验证方案，跑通后再等比放大，省下的试错成本很可观。