1. 为什么 2026 年日志选型会让人如此头疼过去几年我一直帮团队做可观测性建设日志这块从 ELK 一路折腾到 ClickHouse再到各种云厂商托管服务说实话每次做选型都像在开盲盒。尤其到了 2026 年这个问题的复杂度又上了一个台阶数据量翻倍增长、微服务和容器化让日志来源越来越多、合规审计要求变严、成本预算却在收紧。好几条线一起绞进来单纯比较“哪个工具能搜日志”已经解决不了问题了。我见过太多团队踩同一个坑看到某个日志分析平台的功能清单很全压测数据也漂亮就直接迁过去了。结果用上三个月发现真正干活的时候总在关键环节卡住——要么采集端扛不住高峰期写入要么查询语句复杂一点就超时要么告警噪音大到你直接关掉通知。最后整个平台沦为“事故之后翻日志用的黑匣子”跟建设初衷完全背离。这篇文章我想把自己这几年的日志平台选型经验梳理一遍重点拆解 2026 年一个合格的日志分析平台到底应该在哪些地方扛得住以及你在评估产品时真正该盯着哪些指标。我尽量不堆术语用做过的实际案例说话如果你正在做技术选型或者准备升级现有日志系统应该能有直接参考价值。我自己理解的日志分析平台本质上是解决三个问题你能多快拿到日志、你能多深挖出问题、你能多省成本地把日志留住。围绕这三个问题选型的坐标系就清晰了。2. 架构选型前的自我检查别让“需求不清”成为选型失败的第一因2.1 先算清楚你的数据盘子很多人一上来就拉着各个厂商聊功能聊了半天发现连自己要处理多少日志量都说不明白。我习惯在选型前先做一个粗略的规模测算这个步骤决定了你后面选存储引擎、定配置规格、谈价格的基础方向做错的话后面全是错的。测算的核心是四个数峰值写入速率每秒多少条、单条日志平均大小、日增存储量、保留周期内总存储量。举个例子假设你有 200 个微服务实例每个实例每秒产生 20 条日志那峰值写入就是 4000 条每秒如果平均每条 1KB那就是大约 4MB/s一天下来原始数据约 345GB。这个数字再乘上你计划的保留周期——比如 30 天——就是 10TB 级别的存储盘子。如果还涉及业务日志的审计留存保留周期可能是 180 天甚至更长那就要按 60TB 去准备。这个盘子算完之后你会发现市面上很多轻量级方案根本不用看了同时也会逼你想清楚另一个问题你真的需要全量存所有日志吗如果把 debug 级别的日志直接丢弃把结构化业务日志和普通运行日志分级存储总量可能直接砍掉一半。这是省钱的第一步也是选型前必须先做的取舍。2.2 梳理使用角色和数据流日志平台的使用者往往不只是运维。在你评估任何一个产品之前我建议先把团队里的使用角色都拉出来问一圈需求研发人员要看错误堆栈和链路关联SRE 要看趋势和告警安全团队要做审计检索管理层要的是报表和成本趋势。每个角色的使用习惯完全不同这直接决定了你需要的查询能力边界。我记得有个项目的研发同学抱怨说旧平台搜日志太不方便每次要找某个用户 ID 相关的记录都要在一堆 JSON 里人工翻。后来我们做了日志结构化解析把 user_id、order_id、api_name 这些字段单独提取出来配合索引优化查找效率提升了非常多。这就是一个典型的从“全文检索”升级为“结构化检索”的需求而这点在你选型时必须确认平台能支持而不是采购之后再想办法。2.3 把 SLA 要求写下来而不是写在心里日志平台也是要谈 SLA 的。索引延迟多少分钟、查询 P99 延迟多少秒、一年可用性几个九、数据丢失容忍度是多少这些都应该在选型之前量化清楚。我见过一个金融客户要求日志从产生到可搜索的延迟不能超过 30 秒这个要求直接淘汰了好几个号称“准实时”但实际索引窗口要几分钟的产品。这里我想提醒一个反直觉的点查询快和写入快往往是矛盾的没有一个系统能在所有指标上同时做到极致。你必须在“写入实时性、查询性能、资源成本”三角里做取舍不同的取舍方向造就了不同类型的日志分析平台。3. 2026 年日志分析平台的核心能力拆解3.1 采集与传输PipeLine 能力是真正的分水岭很多人在看日志平台时第一个关注的是存储和查询我反而建议先看采集端。原因很简单如果日志根本没被可靠地收集进来后面的一切能力都是空中楼阁。2026 年的采集端已经不是一个 agent 把文件读走就完事了它要承担的工作包括多来源接入容器标准输出、宿主机文件、K8s Events、云平台审计日志、数据库慢查询日志等多格式解析JSON、文本、多行异常栈、Syslog、Grok 规则解析简单的数据清洗脱敏、过滤、字段提取、格式标准化可靠投递缓冲区策略、重试机制、削峰填谷以我实际用过的采集器为例Filebeat 轻量但能力有限Fluent Bit 的性能和插件生态更好Logstash 功能最全但吃资源。如果你选商业平台要问清楚它内置的 agent 在极端情况下的表现——比如采集端写满磁盘、目标端短暂不可用、日志突然暴涨五倍流量时agent 会不会丢数据缓存策略是怎么设计的。有一个特别容易被忽略的点是多行日志的处理。Java 应用抛异常时一条日志实际上是一个多行堆栈如果采集端按行拆分再发送后面解析和排障时完全没法看。所以采集端必须支持多行合并规则multiline以异常堆栈的起始行标记作为分界把整块堆栈作为一条日志处理。这个细节看似简单但很多平台在真实场景里都处理不好。3.2 存储引擎没有万金油只有合适不合适存储是整个日志分析平台的心脏也是选型中最需要花费精力的部分。2026 年主流的日志存储方案基本可以归成三类全文检索引擎型如 Elasticsearch 系的优势是全文检索能力强、生态成熟、Kibana 可视化做得好、查询语法灵活。缺点也明显在高写入压力下索引膨胀快存储成本高冷热分层做起来需要精细运维。列式 OLAP 型如 ClickHouse在海量日志场景下写入吞吐极高、压缩比好、聚合分析速度极快特别适合做日志的统计分析和明细查询。它的短板在于单条日志的全文检索能力较弱对精确匹配和模糊查询支持不如 ES 那么自然运维门槛也更高。云原生托管型如各家云厂商的日志服务的卖点是免运维、弹性扩缩容、与云产品打通顺畅计费模式通常是按写入量存储量查询次数组合。长期看如果量很大费用会非常可观但在中小团队、云上业务场景里确实省心。我目前的倾向是如果日志量每天几个 TB 起步、大量场景是结构化日志分析那列式 OLAP 型更划算如果你的场景以分布式系统的全文检索排障为主、对查询语法要求灵活ES 系仍然不过时。选型最忌讳的是拿着一家的性能优势去硬套另一个场景我的建议是同时跑 PoC拿自己的真实日志做基准测试别只看官网 benchmark。3.3 查询与分析你以为你在比功能其实你在比场景覆盖日志查询能力拆开来看有三个层次检索、分析、关联。检索是“把符合条件的日志翻出来”分析是“对日志做聚合统计和可视化”关联则是把日志和链路追踪、指标数据串在一起看问题。2026 年的日志平台如果只能做第一层第二层已经很难满足生产级排障需求了。检索层面你要关注的是查询语法是否够灵活、索引字段是否可自定义、查询响应在百亿级数据量下能否稳定在秒级。分析层面要看它是否支持类 SQL 语法、内置了多少常用的聚合函数、能否直接基于结构化字段做 Group By、Top N、分位数计算。关联层面这就涉及到日志与 traceID 的串联、日志上下文跳转等能力。我一直强调一个观点“能查”和“查得快”是两件事“能查出来”和“能查明白”又是两回事。做选型时一定让厂商拿真实业务日志来演示排障全流程从一条错误日志反查上下游链路看整个排查链路顺不顺。我见过很多平台演示时用的是精心准备的 demo 数据一到你的业务场景里就各种不顺手。3.4 告警与智能化从看得见到看得懂日志平台不只是“事后查”更要“事中发现”。告警能力现在已经成为日志平台的标配但不同平台的告警质量天差地别。我最在意的是三个能力灵活阈值、智能基线、降噪机制。灵活阈值指的是你能基于任意检索结果和聚合结果设告警还支持同比环比、突增突降这类相对阈值。智能基线是平台自动学习历史数据的正常波动范围当出现偏离时触发告警——这个能力在业务量有周期性波动的场景里特别有用能避免每天固定阈值导致的大批误报。降噪机制则是告警合并、抑制、路由和值班排班的综合能力没有降噪的告警系统基本等于没有告警系统。2026 年还有一个明显趋势是 AIOps 功能开始进入日志平台比如异常检测、日志聚类、根因分析。我要泼一盆冷水这些功能在 demo 里都很好但真正生产中能稳定落地、减少 MTTR 的比例还不高。选型时可以把智能化能力当作“加分项”别把它当作“决定项”核心的检索、聚合、告警这些“笨功能”才是你每天都要依赖的生命线。3.5 成本控制存储压缩比和生命周期管理是隐形胜负手日志平台烧钱的速度可能超出你的预期。我算过一笔账如果一个集群每天写入 2TB 原始日志保留 30 天按常见的 1:3 压缩比换算存储空间就要准备 20TB 左右如果用云盘且开启多副本这个成本再翻倍。不少团队最后是被日志账单惊醒才开始认真考虑降本的。因此存储压缩比和生命周期管理能力必须纳入核心评估项。压缩比受日志格式影响很大JSON 日志的压缩效果通常好于纯文本重复字段多的日志压缩比可以到 1:5 甚至更高。你在 PoC 时一定要拿自己真实的生产日志样本跑一遍压缩测试看看平台承诺的压缩比是否靠谱。生命周期管理要看平台支不支持冷热分层、归档到对象存储、按索引或按分区策略自动清理。我目前的典型配置是热数据保留 3 天在 SSD 上保证查询性能温数据 30 天在普通云盘上超过 30 天的按需归档到对象存储备查。这样存储成本可以压缩 50% 以上而排障时最常用的近几天日志性能完全不受影响。4. 选型前的需求清单与主流方案对比4.1 一份可以直接抄的需求清单我不想讲太玄的方法论直接把我们在选型前整理的需求清单列出来你可以按自己的情况增删评估维度具体检查项你的要求值 / 备注采集能力支持哪些数据源接入容器、主机、云服务、DB 日志等采集可靠性高峰期缓存策略、断网重传、是否可能丢数据明确不丢数写入性能单节点每秒可写入多少条 / 多少 MB按峰值估算索引延迟从产生到可检索的延迟按 SLA 要求查询性能百亿级数据量下关键词查询响应时间P99 不超过 3 秒查询语法支持 Lucene / SQL / 自定义 DSL团队熟悉哪个结构化分析是否支持自定义字段解析和索引必须有可视化内置仪表盘是否够用可否自定义按团队习惯告警阈值类型、降噪、值班路由必须有降噪关联能力traceID 关联、日志与指标联动加分项存储压缩比实测压缩比按实际测试确认冷热分层是否支持分层存储与自动迁移必须有成本模型按写入量 / 存储量 / 查询次数如何计费按量估算年度成本私有化 / SaaS数据合规要求部署形态按合规要求运维复杂度组件数量、升级方式、故障恢复团队是否有专职运维这张表的好处是逼着你在看产品之前先把需求想清楚。如果你发现自己填不上这张表那就说明你还没准备好选型先去把需求调研做扎实再说。4.2 自建开源 vs 商业平台 vs 云托管三条路的真实账单我分别走过这三条路每条路都有各自的“隐藏成本”这里展开说一下。自建开源方案比如 ELK 或 ClickHouse 自建看起来零授权费但真实成本都藏在运维里。ES 集群要想稳定运行节点规划、分片策略、索引生命周期、冷热迁移、内存和磁盘水位都要专人负责。我见过一个团队用 ES 存储量没过 20TB 就开始频繁出问题最后招了一个专职 ES 运维才压住。如果你的团队没有专职 ES 经验自建这条路要非常谨慎。ClickHouse 自建类似查询快是快但分布式表引擎、副本策略、数据 TTL 这些概念的学习曲线非常陡。商业平台指提供完整软件交付和服务的方案核心价值在于省运维、能力打包完整。好的商业平台能把采集、解析、存储、告警、可视化这些环节都打通开箱即用技术支援和 SLA 也有保障。缺点是授权费用和资源绑定扩展性有时候受限于厂商的实现而且你要确认它是否支持跨云、是否容易被厂商锁定。云托管服务最大的优势是弹性伸缩和零运维按量付费的模式也适合快速起步。劣势是长期成本不可控日志这种持续写入的数据规模上来之后每个月的账单会非常刺激。此外数据都在云厂商的地盘上如果未来做多云或迁回自建数据导出和迁移也是一笔隐形成本。我的建议是中小团队、业务快速变化期优先考虑云托管或商业 SaaS想清楚自己的核心业务是什么别把宝贵人力耗在维护日志系统上中大型团队、数据合规要求高、有专职运维能力则重点考虑商业私有化方案或自建 专业服务组合。4.3 与可观测性体系的联动日志不是孤岛2026 年聊日志平台一定绕不开可观测性的大背景。业界常说的“三支柱”——日志、指标、链路追踪——本来是三种不同数据类型的采集和分析体系但在排障实践中它们是互相辅助的。一个完整的排障流程通常是指标先发现异常日志定位具体错误链路追踪还原调用全貌。你在选型日志平台时一定要看它跟指标平台和链路追踪系统的联动能力。比如日志中提取出的 traceID 能不能一键跳转到对应的链路追踪页面某个服务错误率飙升时能不能快速关联到该服务同一时间窗口的 error 日志如果你的日志和指标是两套独立烟囱排障的时候就要在多个系统之间来回切换每一个切换都是在消耗排障黄金时间。5. 实操一次 PoC我建议你这样评估同类产品5.1 PoC 环境搭建和测试数据准备纸上谈兵聊完了真正动手选型时必须做 PoC概念验证。我不建议直接拿厂商提供的 demo 环境点一点就说“体验不错”那样的验证没有价值。正确的做法是搭建一套最小可用的测试环境把你们真实的日志数据灌进去按照真实场景进行测试。准备测试数据时最好包含几类典型样本正常业务日志JSON 结构化、系统运行日志纯文本、异常堆栈日志多行、高峰期突发日志。数据量上不要只放几百 MB建议灌入至少几十 GB 到上百 GB 的真实样本把索引、压缩、查询都放到接近生产的状态下测不然很多性能问题根本暴露不出来。5.2 我自己的 PoC 测试清单以下是我每次做日志平台 PoC 都会跑一遍的测试项你可以直接抄写入压测用 logstash 或自写脚本模拟高峰期写入速率观察平台是否有背压、丢数、写入延迟突然攀升的情况关注 CPU、内存、磁盘 IO 的表现。查询压测准备 10-20 条模拟真实排障的查询语句包括精确匹配、模糊匹配、范围查询、聚合分析压测并发查询场景下的响应时间和成功率。结构化解析拿真实业务日志测试平台内置解析器能否自动识别 JSON 字段能否通过自定义配置提取复杂格式字段解析失败率有多高。聚合分析跑一批常见分析用例例如按服务名分组统计错误数 Top 10、按时间窗口统计 P95 延迟、按用户维度统计错误分布观察响应速度。告警配置配置一条带条件的告警修改数据触发告警测试从触发到通知到达的完整链路时间以及告警噪声的干扰程度。成本估算记录测试期间的实际存储空间结合厂商给出的计费模型折算成你们的预估月度成本拿这个数字上会跟老板谈预算。5.3 如何读懂压测数据不被“高指标”带偏压测数据不是越高越好关键是读懂指标背后的含义。一个平台声称单节点每秒写入 10 万条你要追问是在什么配置、什么数据样本、什么一致性级别下测出来的。写入吞吐高但查询延迟上去了这种“单点极端值”没有意义。我自己的经验是关注三个综合指标写入 P99 延迟、查询 P99 延迟、压缩比。这三个值放在同一个资源规格下比较才能反映平台在真实负载下的整体表现。另外一定要测“并发用户数”对查询延迟的影响日志平台通常不是一个人在用团队 10 个人同时排障时查询响应是否还能扛住比单用户毫秒级响应更关键。还有一个容易被忽视的点测试要跑足够久。很多平台在刚开始跑的时候性能很好跑上几小时甚至一天后随着数据量增长、后台合并、GC 等因素叠加性能就开始明显下降。你至少要跑 24 小时最好跨过一个完整的业务高峰周期才能看到真实水平。6. 运维视角的额外把关这些隐藏工程问题比功能更重要6.1 索引和分区的弹性管理能力日志场景的数据特性是“永远在涨”所以平台对索引和分区的自动化管理能力至关重要。评估时要问清楚索引/分区按什么策略自动创建是否可以按天、按小时自动滚动数据量增长后是否需要人工干预去调整分片数量有没有内置的索引生命周期策略我踩过很深的坑是早期用 ES 的时候没规划好分片数数据量涨到一个阈值后集群健康状态变成黄色查询性能骤降最后只能半夜做 reindex。所以我现在对“自动化索引管理”这个能力极其看重。商业平台或者云托管服务通常把这层封装得很好你只需要设置保留周期和副本数自建方案的话就要花时间把 ILM 策略提前设计好。6.2 查询限流与资源隔离机制日志平台的典型问题是“一个慢查询拖垮整个集群”。如果平台没有查询限流和资源隔离机制团队里某个同学写了一条全量扫描的查询很可能把整个集群的 CPU 打满影响所有用户的检索体验。这个能力在生产环境非常重要但在选型阶段非常容易被忽略。好的平台应该有类似查询超时自动终止、大查询队列排队、按用户或按项目做资源配额、慢查询审计日志这些机制。云托管服务通常在网关层做了比较好的隔离自建方案就需要你用网关和负载均衡自己去设计。6.3 多租户与权限体系如果你的日志平台要服务多个业务团队多租户隔离和细粒度权限控制就不是可选项而是刚需。需要确认是否支持项目/空间级别的数据隔离是否有基于角色的访问控制RBAC能否做到某团队只能看自己业务的日志而不能跨团队搜索敏感字段能否在查询结果里自动脱敏合规要求高的行业比如金融和医疗日志中经常包含个人敏感信息脱敏能力在选型中要放在很高的优先级。我见过一个方案日志采集端可以做字段级脱敏但查询时如果直接查原始索引还是能看到明文那就等于没有脱敏。所以验证脱敏效果时一定要实测用有权限和无权限的账号分别查同一批数据确认输出内容确实不同。6.4 高可用与容灾方案日志平台本身挂了怎么办这个问题如果没提前想清楚出事时就是二次事故。你要评估写入链路是否有缓冲机制消息队列做削峰填谷和故障缓冲存储层是否支持多副本跨可用区容灾如何实现故障恢复的 RPO 和 RTO 目标能否满足业务要求我的建议是写入链路至少要有本地缓冲目标端不可用时数据不丢存储层至少双副本数据不是一次写入就没备份了。如果业务对审计日志有强合规要求还要考虑跨区域异地备份这个需求会显著影响你的存储成本和方案复杂度。7. 2026 年的新趋势AI、OTel 与成本治理哪些值得跟进7.1 AI 辅助排障从“关键字搜索”到“语义理解”2026 年日志平台最热的话题之一是 AI 辅助排障。用自然语言描述你想要查的内容AI 能自动生成查询语句发现异常日志聚集时AI 能自动聚类并总结出共性甚至能根据历史故障模式和当前日志特征给出根因分析建议。我的态度是积极试用但要保持理性预期。AI 功能目前最适合的场景是辅助缩短排障路径比如你把一条报错信息粘贴进去它能帮你自动提取关键字、关联相关日志、给出可能的原因列表。但如果指望 AI 自动定位所有故障根因那还不太现实尤其是一些涉及复杂分布式链路的问题AI 的推理链还容易跑偏。选型时重点关注 AI 功能的实现深度。有些平台只是接了个大模型 API摆个聊天框就叫 AI真正有价值的是基于平台内数据构建的上下文理解比如 AI 能结合你的日志结构、历史告警记录、服务拓扑来回答排障问题而不是从通用知识库给你讲一堆空泛的大道理。7.2 语义约定 OTel 的普及正在改变数据接入方式OpenTelemetry 逐渐成为可观测性数据的标准协议对日志选型有直接影响。以前每个日志平台都有自己的 agent 和数据结构接入一个新平台要适配一次。OTel 普及之后日志可以按照统一的标准采集和传输平台之间迁移的成本显著降低。选型时可以问一个关键问题平台是否原生支持 OTel 日志协议能否自动识别 OTel 的 resource、attribute、trace_id 这些标准字段支持得好你后续接 Kubernetes、接微服务框架、接链路追踪系统都会顺手很多而且未来如果要换平台数据迁移也要容易得多。7.3 成本治理从“事后看账单”到“前置预算控制”2026 年各家企业都在提降本增效日志领域的成本治理也变得更精细。过去的做法是月底看账单傻眼现在好一点的平台支持预算预警、成本分摊、按团队维度可视化分析费用来源。更进一步的还有写入侧的成本控制比如在采集端就做日志过滤和采样只保留有分析价值的日志进入存储。我建议把“成本治理能力”纳入选型的正式评估项而不是后期再补救。评估时问清楚平台能不能按项目/团队维度拆分成本能不能设置预算阈值并自动预警能不能在采集端直接配置日志过滤规则这几个能力直接决定了你的日志账单在一年后会不会失控。8. 常见问题速查我自己踩过的选型坑和避坑经验Q1日志平台要不要选大而全的一体化平台我踩过这个坑答案是取决于团队规模和阶段。大而全意味着学习成本高、模块耦合重、可能很多功能你用不上但资源照占。我的建议是先列自己的核心场景按需求清单匹配够用 有扩展空间比功能多更重要。场景清单之外的功能再好都是噪音。Q2商用平台的压缩比承诺靠谱吗不靠谱的居多主要原因是压缩比跟数据特征强相关。JSON 日志重复字段多、文本日志相似度高压缩比能到很高但如果是高基数的随机文本压缩比就明显下降。唯一的办法是把你的真实数据样本拿过去做压缩测试让厂商用你的数据跑一遍把结果白纸黑字写进合同或者报价单而不是听他说“一般能压到 1:5”。Q3开源方案免费所以成本低对吗这是最大的误区。开源软件的显性成本是零但总拥有成本要算上人力运维、故障处理、定制开发、培训成本。我见过一个小团队选 ELK 自建半个月时间全部耗在集群调优和排障上业务迭代全停了。算总账的时候自建方案对团队运维能力的要求必须折成成本。Q4如何判断平台查询快不快不要信“毫秒级响应”这种宣传让厂商提供一个在百亿级数据量下的查询演示或者直接拿你的生产数据做基准测试。查询性能要看并发场景下的 P99而不是空集群单请求的延迟。此外一定要测“复杂聚合查询”的表现实际排障时最卡的就是这种查询而 demo 里往往只演示最简单的关键字搜索。Q5买日志平台时哪些“隐性成本”容易被忽略最常见的是流量费和 API 调用费。有些云托管服务按写入流量计费日志量大时网络流出费用可能比存储费还高查询次数过多也有额外费用。另外还有多副本费用、跨可用区流量费、长期存储归档的取回费用。建议你根据实际使用量预估一下这些附加项不然上线后第一个月的账单会颠覆你的预算。9. 选型之后部署、迁移和落地的三条经验选定平台只是开始真正的挑战在落地阶段。我这里分享三条实际经验。第一迁移一定要有并行期。不要把旧平台直接停掉新平台和旧平台并行运行至少两周验证新平台的数据完整性和查询结果一致性。我就是因为太信任新平台的“无缝迁移”承诺结果切开旧系统后发现有一部分历史日志的时间字段解析有问题导致按时间检索总是漏数据最后又花了一周做数据修复。并行期虽然会带来双份成本但对比数据丢失和业务故障这点成本非常值。第二上线初期要提前做日志规范治理。很多团队的日志是“想打什么打什么”格式五花八门。平台上线前最好花点时间统一日志格式规定必填字段时间、级别、服务名、traceID推荐结构化格式限制敏感信息打印。好的日志规范能让平台的解析和检索效果翻倍也能让告警准确率高很多。这是一件前期投入少、后期回报极高的工程。第三提前定义好字典和命名规范。服务名、环境名、机房名这些字段如果不统一后面做聚合分析和维度筛选时会非常痛苦。比如同一个服务在日志里叫“order-service”和“order_svc”在聚合统计时就被当成两个服务了数据的价值就打了折扣。平台落地时顺便把命名规范定下来并且通过采集端的标准化处理来强制统一不要让研发自由发挥。以我自己的经验来看日志分析平台选型最重要的不是追逐最新最热的技术名词而是想清楚你的团队现状、数据规模、核心场景和成本预算然后拿着一个明确的需求清单去横评。宁可多花两周做 PoC 把数据测扎实也不要仓促上线一个在关键场景里掉链子的系统——日志平台是排障时的生命线选型省的那点时间将来都会在故障里加倍还回来。