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

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平台或叫容器云平台也是一样，虽然目前一些资源管理能力还不具备，但仍然能通过相应的技术和方式提供基础设施资源和开发、测试、托管、运维等平台能力。日志作为每个平台每个服务都不可回避的能力，使之成为一个平台级的服务也是一种很好的选择。在建设容器云平台时，日志功能单独拿出来实现日志中心，再逐步集成其他应用和系统的日志，日志中心逐步会成为企业内的日志平台，最终一个企业可能就只有这一个日志中心平台。这样，所有业务日志的归集也便于日志的分析和价值挖掘。

结束语

（编辑：武汉站长网）

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