如何进行容器云平台日志中心设计？

日志功能是任何一个系统或组件必不可或缺的组成部分，我们每次规划建设一套系统或一个服务的时候，都少不了需要考虑日志的问题。容器云平台也是一样，不但要考虑容器云平台自身的日志，还要考虑部署于平台的业务应用、业务服务以及云上中间件的日志。再推广一点，以微服务的思想来构建容器云平台，日志作为独立的组件微服务，不仅容器云平台可以访问使用日志中心服务，其他平台、其他组件同样也可以访问日志中心服务。这样日志中心服务就可以成为基础的组件服务，服务于整个公司的系统、应用、服务等，而不仅仅是服务于某个特定的系统、应用、服务。真正做到一次建设，永久使用。

基于上面的考虑，我们提出容器云平台日志中心需求。

一、日志中心需求概述

1.组件服务化需求

我们以前也讨论过以微服务思想构建容器云平台，很重要的一点就是实现服务共享，一次建设，多次使用。日志功能是最基础的功能需求之一，为避免重复建设，重复投资，造成浪费，把公用的日志能力单独提取出来作为一个微服务组件，以实现服务共享、降低成本、节省时间，最大化收益的目的。

2.日志数据集中分析处理需求

技术的发展使日志数据也越来越显示出其价值。以前在无法处理分析大量日志的情况下，很多日志数据散落于各处，也由于竖井式的应用系统架构方式，日志数据归集繁琐，关联困难，日志数据很难保存，大多都过一段时间就会被删除。随着大数据分析技术的成熟，使我们能从大量的日志信息中挖掘获取到高价值信息、趋势，提供预测、决策支持。目前已经没有了技术限制，因此日志数据的归集也更便于数据的统计、查询、分析、存储等，更好的挖掘数据的价值。

在去中心化大行其道的今天，我们为什么强调集中化和中心化？其实并不矛盾。去中心化并不是没有中心，更多的是去单中心化，实现多中心化。在设计时需要自成一体，同时又是某一个中心的一员。宇宙——银河系——太阳系——地球——生物——细胞——原子……，他们都依附于一个中心，都是一个中心，同时并行的中心又有很多个。这样是一个生态系统。我们在做软件设计、软件架构的时候，同样可以参考这样的思想，避免只见树木不见森林。

3.简化开发，专注于业务实现

简化业务系统、业务应用、业务服务研发，直接调用日志服务，不再关注日志格式、存储、运维等问题，专注于业务逻辑研发。

4.日志格式标准化，采集规范化，存储统一化

不同的系统不同的应用格式不统一，首先把日志作为组件服务提出出来，在设计实施时只需要按照日志中心的标准格式来打印输出日志，也实现了日志采集的规范化，日志数据存储的统一化，这样对于日志的统计、分析等也易于处理。

5.可扩展性需求

要实现服务共享，可能就无法确切的预测到底需要多少资源，这就需要考虑可扩展性。随着业务的需要自动或手动扩展。容器云平台的扩展，更多是考虑横向的扩展，比如增加节点数，增加实例数，以支持更高的负载请求压力。最理想的方案是扩展无限制，但目前不太现实，所以单个节点或者单个实例的能力还是要满足相应的要求。容器技术理论很好，但落地时也会面临着这样那样的技术细节问题。所以不能盲目乐观，可扩展性是一个容器云平台需要认真面对的问题。

6.松耦合需求

松耦合需求也是一项很重要的内容。组件或服务易扩展，组件或服务之间耦合性不能太强。组件与组件之间，组件内部等都需要考虑松耦合的架构。组件服务彼此独立又相互关联，就象人与人之间的社会关系。不管容器云平台还是日志中心内部的架构，都应该是一种松耦合的架构。组件可以独立存在，也可以被替换。

7.开放性，标准化需求

在遵循相应的开放性标准或规范的情况下，松耦合的组件很容器被替换。如果是私有标准，就可能会增加很多工作量。所以在做设计的时候需要考虑开放性的需求。

8.实时准实时处理需求

日志的采集和处理到查询展示通常情况下是有一个可以忍受的延迟时间。比如，1秒或2秒，如果超过5秒，体验明显就会不好。所以日志中心设计也需要考虑日志的实时或准实时处理。可能不同的日志需要考虑分级，所采用的技术和方法会有不同。比如交易类就可能需要实时的日志记录、采集、展示。管理类可以接受准实时的日志延迟。

9.支持不同的日志格式、日志类型需求

日志格式有多种多样，日志中心需要考虑支持不同的日志格式，比如文本，json文件，jms消息等，还可能涉及到字符编码等。对于我们来说，最基本的需求是支持业务应用服务日志的标准输出采集，平台各组件运行日志采集，中间件运行日志采集等。这些数据归集于Elastic Search(ES)，通过Kibana或者Graylog来查询展示。

二、设计原则

基于前面需求的讨论，容器云平台日志中心设计原则也就体现出来了：

1.组件中心化原则：实现日志集中存储、集中管理、集中查询分析等能力。通过组件服务化实现特定的功能，这些是基础的、可共享的、自成一体的、有独立中心的功能组件。

2.可扩展性原则：通过采用分布式架构，支持在不更改整体架构的前提下进行系统横向扩容。可借助于Elastic Search(ES)的扩展能力来实现。

3.松耦合原则：容器云平台架构采用松耦合架构，平台日志中心通过标准的接口和容器云平台连接，也方便客户已有系统的集成或平台组件的扩展和替换。

4.开放性和兼容性原则：标准化或通用的技术手段兼容主流的设备和系统、软件、工具等。

5.可靠性原则：提供可靠的采集、传输、存储、查询、分析等方面的能力。

6.准实时原则：日志的处理有时很难做到实时，可以考虑实现准实时的日志处理，根据业务的要求来确认日志的延迟性。尽可能做到准实时。

7.日志分类处理原则：对业务日志和组件运行资源使用等日志的处理是不一样的。组件运行资源使用等日志通常只作为实时监控的数据，不需要持久保存。业务日志通常是需要持久化存储，作为进一步统计分析的依据。

三、架构设计

容器云平台日志中心组件我们选择比较流行的ELK等作为基础组件，一些场景使用Graylog替换Kibana来更好的用图形化展示。一方面考虑在容器云平台前期建设过程中成本投入，开源组件也比较成熟且功能强大，足以满足前期支撑业务日志的需求。另一方面开源是个趋势，也需要逐步培养内部技术人员自主研发的能力，减少对商用软件公司的依赖。所以在规划建设容器云平台时选择ELK作为日志组件。

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!