融合型日志平台应该如何建设？

1. 企业建设统一日志平台的需求背景

随着业务的发展，IT系统逐渐呈现海量化和异构化的趋势。日志管理与分析在信息记录、操作审计、问题排查等场景中有重要的管理价值。现如今各中大型企业都会建设一套全公司上下统一的日志平台，以满足企业IT运维上的管理和分析诉求。

2. 日志平台常见建设路径与思考

为了实现最终“发挥日志价值”的业务目标，日志平台的总体建设路径可以总结为三个方面：

• 集中化
  将物理层、系统层、应用层异构且分散的日志集中存储和管理。
• 统一化
  即日志数据治理，通过规范例如统一日志格式和清洗脱敏规则，统一传输链路，收集并结构化日志数据，为其运营价值做铺垫。
• 运营价值最大化
  通过统一的平台提供高速稳定的检索分析和监测告警能力，全面提升日志数据的运营价值。

其中前两者，当前大多数国内企业已经颇有建设或即将完成构建。无论使用的是各云厂商或IT服务商提供的日志产品，还是自身基于开源技术组件构建的日志平台，总体上都能满足日志集中化和统一化的建设路径要求。

真正拉开各方建设差距的往往在于第三点。很多企业有着数年来积攒的海量日志，却只能在偶尔故障的时候进行不足百余次查询，并没有发挥和利用日志数据在流动中的价值。

而这部分也是各厂商集中发力的地方。早在日志作为业内标准产品推出的头几年，也正逢大数据AI概念火爆，一些专注日志领域的服务商或云产品，都在探索通过日志大数据来帮助智能运维的能力。然而从现实来看，真正通过日志大数据实践到智能化运维阶段的企业至今仍寥寥无几。这或许应当引发一些我们更加深入的思考，日志数据是否真的应该直接用于做智能分析等场景？

3. “融合”的日志平台建设思路

接着我们来分析这一问题：日志数据是否真的应该直接用于做智能分析等场景？

我们基于最原始的信息论来审视下日志本身包含的信息量。这时我们会发现，现有的操作系统、语言运行环境、开发框架上固定的输出信息占据了日志数据的绝大多数，其数据量大但有价值的特征向量却少得可怜。基于这种特征的数据去做统计意义上的分析尚且可以，但至于做算法模型、做AI预测等，即使最终可以通过极为庞大数据量来获取不错的结果，但不得不说存在很大的效率问题，事倍功半，消耗的成本也将是企业难以接受的。

举个反例就是，如今流行的各短视频平台，他们的算法之所以强大，是因为数据大多都是UGC的，样本具备广泛的多样性和偶然性，信息熵高，模型训练效率也高。而日志呢，几十上百TB的数据可能只来源于个位数开发者大脑的一点点创造性。如果企业真的在用日志做智能化，很大程度上可能不是日志平台本身做的，或者日志平台只是在处理业务中的问题，一旦数据要求脱敏或者业务本身简单，它便原型毕露。

那如何建设日志平台来真正利用好日志数据呢？

其实很早之前的一句话总结的非常好，“日志是排障的最后一公里”。这句话其实不止是说日志本身的信息量可以帮助开发者最终确定问题的根因，仔细分析还可以发现其另一层意思：“日志只是最后一公里，需要联合前面的可观测体系可以实现真正的极速定位”。

这张图是可观测元年极为火爆的一张图，十分清晰地阐释了指标数据、链路数据、日志数据在整个可观测体系中的定位。也指明了一条如何最大化利用各类型数据达到数字化运营目标的道路，那就是——结合上下游数据，共同构建平台，实现ITOA。那么日志平台，便需要更好地联通上游，和其他观测系统共同完成对象建模和信息流串联，扮演好这个体系中应有的角色。用这种“融合”的思路来进行日志平台的建设，是当今一种更加理性的建设思路。

举一个简单的日志运用场景为例：

日志关键字告警是我们一种非常常见的告警手段，通过检测某些关键字出现或者未出现的次数来判断当前系统的运行状态。假设当前出现了一条业务自定义的关键字告警，分散建设的日志平台和在可观测体系下建设的日志平台的区别如下所示。

4. 建设路径

那么这样一种基于可观测理论体系建设的日志平台应该从哪些方面进行建设呢？

除了前文提到的集中管理和统一规范，与以往常规建设思路不一样的地方可以主要概括为以下三点：

• 统一观测对象建模 ：基于CMDB或其他建模手段建立全局统一观测对象模型，构建多维业务对象级联关系，方便数据的定位寻址。
• 数据关联打标：在日志明细中埋入traceid和spanid，metric指标上报埋入业务对象标签。
• 提供界面或工具支持来源于上游的快速检索和分析能力：提供基于时间统计维度的，可以在依赖对象之间下钻分析的能力。

完成这三点之后，日志作为“最后一公里”的价值将被极大地发挥出来。这种思路和之前最大不一样的点就在于，我们并非希望日志平台基于自己的数据量优势去扩展其边界以外的能力，而是协同体系中应对不同场景更适合的平台，共同达成一些业务目标。

目前很多厂商也在逐步整合自己全链路的产品，从而形成一整套完整解决方案。这个趋势在云原生开始普及的时代愈发的明显，我们能看到从头部云厂商到小型IT服务商，都在着力构建完整的上下游链路。而通过日志大数据做智能运维这个方向，如今更多是被其他大数据平台所承载，更多企业客户会选择将清洗后的日志数据作为其业务大数据的一个数据源，而并非在日志平台本身建设。

未经允许不得转载：木盒主机 » 融合型日志平台应该如何建设？