日志功能是任何一个系统或组件必不可或缺的组成部分，我们每次规划建设一套系统或一个服务的时候，都少不了需要考虑日志的问题。容器云平台也是一样，不但要考虑容器云平台自身的日志，还要考虑部署于平台的业务应用、业务服务以及云上中间件的日志。再推广一点，以微服务的思想来构建容器云平台，日志作为独立的组件微服务，不仅容器云平台可以访问使用日志中心服务，其他平台、其他组件同样也可以访问日志中心服务。这样日志中心服务就可以成为基础的组件服务，服务于整个公司的系统、应用、服务等，而不仅仅是服务于某个特定的系统、应用、服务。真正做到一次建设，永久使用。
基于上面的考虑，我们提出容器云平台日志中心需求。
一、日志中心需求概述
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作为日志组件。
Elastic Search(ES)以集群的形式来存储采集到的日志数据，提供保存、查询、分析等能力。Logstash等作为日志采集的工具，根据不同的业务场景和业务需求，选择合适的工具采用合适的方法采集需要的日志数据，或发送到Elastic Search(ES)，或发送到监控中心作为监控的数据源之一。Kibana或者Graylog来图表化或图像化展示业务日志的详细情况。
四、组件介绍
1．日志采集
ELK支持多种beats工具来采集日志数据，比如filebeats，采集日志文件的数据，Metricbeats采集指标数据，PacketBeats采集网络数据，Topbeats采集系统资源情况数据，Heartbeats采集运行时健康检查数据等等。Beats有很多中，也可以根据需要自己实现。ES beats概要页面给出的关系图如下：Beats采集到的数据可以直接发送给ES或者通过logstash转换，由Kibana来展示。
回到我们实际的需求，我们希望业务应用的日志全部打到标准输出，容器云平台通过标准输出来采集日志。日志中心同样需要考虑支持多租户，和容器云平台多租户能力打通。租户只能看到自己的应用和服务的日志，以及容器云平台自身和租户自身资源的运行时信息。这会涉及到容器云平台的权限中心设计。这也是我们为什么一再强调权限中心设计的重要性的原因。权限管理是贯穿整个容器云平台能力的基础功能。作为容器云组件的日志中心的设计也离不开对权限和多租户能力的支持。
容器中应用服务日志输出到标准输出，通过Logstash的组件来从标准输出中采集日志，每个服务的每条日志有固定的格式和标签来区分。将容器日志发送到 STDOUT 和 STDERR 是 Docker 的默认日志行为。实际上，Docker 提供了多种日志机制帮助用户从运行的容器中提取日志信息。这些机制被称作 logging driver。 Docker 的默认 logging driver 是 json-file。json-file 会将容器的日志保存在 json 文件中，Docker 负责格式化其内容并输出到 STDOUT 和 STDERR。路径为： /var/lib/docker/containers/<contariner ID>/<contariner ID>-json.log
对于日志文件存储量的评估计算，根据Kubernetes v1.10的文档，一个node上支持不超过100个pods的部署数量，整个集群平均每节点不超过30个Pods 60个容器，那么单一节点能支持的容器数是多少（假定资源足够）？至多支持100个pods，容器数可能也不超过200个。所以一个node上的日志量按照5个rotation日志文件数，每个文件200M计算，不会超过200M x 5 x 200 = 200G，基于这样的计算，我们配置一个node节点挂载200G的磁盘卷用于日志文件存储。默认应用服务的日志文件大小不超过200M，文件数量不超过5个，文件写满后自动覆盖最旧的文件。
应用日志是必须采集的，还有平台日志，也是监控数据的重要来源。不同的日志需要考虑分类分级，在日志采集的时候就需要考虑清楚。平台日志更多的时候是为了平台正常运行而作为监控的数据，需要对接监控中心。业务应用的日志可能需要根据具体业务来确定存储时间，平台的日志基本上不需要存储很长时间，其价值往往也就是体现在实时监控用。
2．日志转换
在某些情况下可能需要实现日志转换，其实logstash已经提供了强大的filter日志转换能力。当然也可以根据需要自定义实现，这里不再赘述。日志转换比较需要关注的一点可能是字符编码的问题。对于英文来说不存在的编码问题在我们处理中文的时候可能会是个严重问题。
3．日志中心Server
日志采集组件就相当于日志中心的Client端，采集之后的数据需要进行存储、分析、统计、查询、展示等，这是ELK的主要功能。不过对于容器云平台来说，日志采集是重要的考虑，日志中心Server可能会需要支持不同的方案，不只是ELK。目前我们选择的是开源的ELK为主的方案，后期也许会根据实际需要进行调整，比如采用商用的日志工具。所以，日志中心跟容器云平台需要松耦合的架构设计。
4．日志展示
目前选择的Kibana是日志分析展示的工具，我们也有团队使用Greylog，Greylog可视化能力更强。具体选择什么工具，个人观点，适合自己就好。
5．配置更新
不管平台或是应用服务，日志采集方式或者输出目的地可能需要变更。以前我们使用log4j，要修改日志路径，需要修改配置文件，然后重启服务。使用容器云日志中心服务，则要复杂很多。不管是标准输出或是log4j等日志文件，数据最终是要被送到日志中心Server的。日志中心Server可能变更，日志传输接口需要调整更新，比如logging-drivers可能需要变更。容器云平台需要支持这样的需求。所以日志采集(Client)和日志Server是松耦合的架构，容器云平台的日志采集模块和容器云平台之间也需要考虑松耦合的设计。容器云平台可以提供日志配置（作为容器云平台配置）能力，实现平台级配置更新。
五、日志中心组件定位
容器云平台日志中心的定位，也决定着日志中心的能力建设规划和设计。从我们考虑来说，云计算平台是基础设施，不管IaaS、PaaS需要有对基础设施资源的管理和运维能力。采用容器技术实现的容器化PaaS平台或叫容器云平台也是一样，虽然目前一些资源管理能力还不具备，但仍然能通过相应的技术和方式提供基础设施资源和开发、测试、托管、运维等平台能力。日志作为每个平台每个服务都不可回避的能力，使之成为一个平台级的服务也是一种很好的选择。在建设容器云平台时，日志功能单独拿出来实现日志中心，再逐步集成其他应用和系统的日志，日志中心逐步会成为企业内的日志平台，最终一个企业可能就只有这一个日志中心平台。这样，所有业务日志的归集也便于日志的分析和价值挖掘。
结束语
我们在这里提供了一种方案，但更多的是提供一种思想，在做方案设计时全面的看待问题，表面看起来不相关的东西都存在着内在的联系。容器云平台的设计和架构，关键不是容器的问题，容器本身只是一种工具，只是一种实现的手段，关键是为了支撑业务。要支撑业务，就不仅仅是说我有容器就万事大吉了。如何使用容器来支撑业务，构建业务平台，满足大部分业务的持续集成、持续运营运维等需求，才是我们需要重点思考的方面。
热门专题
