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