基于云原生日志分类处理方案与落地实践

日志在企业应用中是最有价值的数据之一，追溯过去的记录，记录现在的状态，探寻未来的趋势。本文将分享云平台环境下大流量日志基于云原生技术的价值密度分类处理方案与落地实践，在提升企业日志服务质量、降低企业日志存储成本方面具有参考意义。

说明：为规避业务敏感数字，涉及相关数据以N表示。

方案背景与起源

360搜索是业务QPS峰值达数十万级的典型互联网大并发场景，高流量的业务伴随着大流量的日志，在日志输出效益、治理方面带来很大的挑战。在企业对于日志的价值目标输出落地以及存储管理成本方面，需要根据企业自身的特点和需求做出合适的解决方案，从而规避一刀切粗放的处理模式，有效的提升日志整体的服务质量。

在360搜索日志的价值输出方面，按照用途分为以商务分析的打点日志、以监控业务基本运行状况的监控分析日志、以日常运维排错的消费日志、以及反映基础平台健康状况的平台日志。

从分类特点的角度对日志提出了基于价值分类特性的不同要求。打点日志终端服务于商务，是商务正确输出商业分析数据，对宏观市场定位的重要数据支撑，需要保证日志的准确、稳定、连续，不丢失、不重复、不中断，价值密度很高，在管理上也提出了更高的要求，而这部分日志在总体的日志总量中的占比不到20%。业务监控日志实时反映出业务的QPS、延迟、处理能力等各方面的业务健康态、汇总分析层面指标，作为大屏投放输出企业的基本运营情况，这部分日志在总量日志中占比一般会达到30%。日常排错日志以及平台运行日志需要根据业务的重要性、消费频率、故障应急等输出合适的方案，在量比方面穿插于前两者之间，占比通常会超80%。

针对以上背景，结合云原生技术及企业自身特点，输出云计算平台价值密度的落地实践方案。

方案解决了哪类问题

方案起源一方面为有效解决不同类的日志服务质量问题，另一方面从企业运营成本角度降低基于云原生的资源成本。

从搜索运营及成本的角度，在大业务流量规模下，需要解决日志在企业运营中不同角色、不同用途日志使用面临的问题，尽可能的发挥日志价值。以搜索云以下方面去分析：

总日志流量峰值在数GB/s，基于消息缓冲会形成日近百T左右的存储资源用量。

20%的商务打点日志需要保障7*24小时稳定运行，提供商务分析数据，重要性高但属于离线分析计算，可接受24小时延迟，数据占比也集中在个别重要业务的输出。

为应对数据的连续性以及准确性，通过消息集群建立缓冲生产与消费。总流量峰值在N百MB/s，单日志最大峰值在N百兆MB/s，以N个数据中心Kafka几十台物理集群支撑，保留时常在24-72小时自动清理。为防止集群故障造成数据丢失，运行数百消费进程实时消费落HDFS留存。而该部分日志不涉及存储索引引擎检索以及可视化需求。

30%的业务分析日志大屏提供业务健康运行态监控，通过UDP输入原生全文索引ES，总流量峰值在N GB/s，单日志最大峰值不超过N百MB/s。以TB级ES集群提供支撑，以ES的索引查询能力和聚合计算输出业务运行监控数据运行指标和分析指标，在可视化及延迟及故障告警方面存较高要求。

80%的业务与平台运行日志用于日常排错，这部分日志与打点日志共用消息集群提供短期存储，根据需求进行短期消费。在检索查询、聚合、日志告警、消费资源、可视化方面有较强需求。

基于以上场景，分析主要问题集中在以下几个方面：

1. 没有分类处理不同特性日志，输出不同角色、不同用途的日志使用需求。

2. 依托于消息集群提供缓存存储存留时间过短，存在大部分日志存已过期自动清理，无法消费使用问题。若增加留存时间，需加大消息集群规模，会有资源用量成倍增长的问题。

3. 消息集群提供缓冲存储的方式，不具备存储索引引擎检索能力，消费后数据入ES或其它引擎存储造成二次资源占用，或临时消费到本地文件存在文件过大无法检索问题。

4. 消费带来消费进程的资源占用，在流量较大的场景，准确实时获取数据需要按生产者分区数设定消费数，二次耗用资源。

5. 人工干预过多，带来终端用户、管理者使用的复杂度，有统一管理降低人工依赖的需求。

6. 日志源、管理端、终端端点过多，没有有效的统一管理，存较高风险。

7. 日志使用需求方的可视化、检索、聚合、时效性无法分类覆盖。

8. 升级的风险考量评估。接入采集、版本升级、集群切换等场景，每次需要提前做风险评估预案，很难做到全覆盖。

9. 日志采集不统一，多采集、多存储、多引擎、多输出，造成新业务纳管困难，有较强统一采集需求。

10. 从提供日志服务给业务使用，需要从功能支撑、资源利用、风险评估、机房划分综合考量针对性梳理方案。

方案特性与