日志平台选型别只看功能清单
日志平台的查询界面、冷热分层和告警插件都很容易做成一张漂亮的功能表，但选型时最先要确认的是日志要解决什么问题：事故排查、审计留存、产品分析还是安全检测。不同目标决定采集字段、保留时间、访问控制和成本边界，不能只靠“支持全文检索”来判断。
先看数据路径和所有权
从应用输出到采集器、传输队列、解析、存储和查询端，把每一跳的失败方式列出来。采集器断连时是阻塞应用、丢弃低优先级日志还是本地缓冲？缓冲的磁盘上限和清理规则是什么？这些选择需要与服务等级一致。结构化日志能提高查询可靠性，但字段数量与标签基数也必须受控。
{"level":"error","service":"checkout","request_id":"...","message":"payment provider timeout"}日志不应包含密码、令牌、完整身份证件或未脱敏的请求体。脱敏规则要在进入共享平台前执行，并用测试样本验证；仅依赖检索时再隐藏，数据已经扩散。访问控制需要按团队、租户和敏感级别划分，审计查询行为。
评估查询与成本的真实形态
用真实的时间范围、字段过滤和并发查询验证性能，不要只测少量样例。高基数字段、无限制的正则检索和长保留期会显著影响成本。为常用排障路径准备索引和保存查询，为少用的原始日志设计归档与取回流程。保留期限应来自合规与业务需求，而不是平台默认值。
平台还需要能说明数据是否完整：采集延迟、丢弃量、解析失败和存储写入错误都应可观测。否则工程师看到“没有日志”时，无法判断是真的没有发生还是链路断了。告警和仪表盘同样应版本化，避免一次查询语法升级让关键面板静默失效。
迁移与故障准备
试点时并行写入小范围数据，比较字段、时间戳、查询结果和权限效果。提前演练访问凭据轮换、存储不可用、索引膨胀和回退。选择能让团队清楚管理数据、控制成本并在事故时快速取证的平台，才比功能清单更接近实际价值。
还要确认平台对多行日志、时钟偏差和采样的处理方式。解析错误不应悄悄丢弃原文；至少要计数并保留受限的排查入口。对安全事件设置更严格的保存和访问流程，同时避免把所有业务日志都以同样的高成本长期存放。
培训与运行手册也是选型的一部分。值班人员应能在有限时间内查到服务、时间范围和关联请求，知道查询为空时如何检查采集链路。平台再强，不能被团队在事故中使用，就没有达到目的。
定期根据实际事故更新查询示例和字段说明，才能让平台配置持续贴近团队的工作方式。
同时清理已失效的示例与权限。
避免错误用法被继续复制。
并定期复核效果。
持续改进。
