如何进行关于k8集群器日志收集的总结

日志文件记录

这种日志输出我们无法从以上方法查看日志内容,只能尾巴<代码> 日志文件查看。

在k8官方文档中,对于以上两种形式的日志形式我们如果想收集并分析日志的话,官方推荐以下两种对策:对于第一种文档中这样说:

创建一个集群时,每个容器的标准输出和标准错误输出可摄入使用Fluentd代理运行> <李>

第二容器,使用gcr.io/google_containers/fluentd-sidecar-es: 1.2发送日志Elasticsearch形象。我们建议附加资源约束100 CPU和200 mi记忆的容器,在示例。李李

<>

两个容器的体积份额。The emptyDir volume type is a good choice for this because we alt="如何进行关于K8s集群器日志收集的总结">

对于fluentd官方对其的定义是：

统一日志层

Fluentd通过在后端系统之间提供统一的日志记录层来从后端系统中解耦数据源。 此层允许开发人员和数据分析人员在生成日志时使用多种类型的日志。 统一的日志记录层可以让您和您的组织更好地使用数据，并更快地在您的软件上进行迭代。 也就是说fluentd是一个面向多种数据来源以及面向多种数据出口的日志收集器。另外它附带了日志转发的功能。

fluentd特点

1. 部署简单灵活

2. 开源

3. 经过验证的可靠性和性能

4. 社区支持，插件较多

5. 使用json格式事件格式

6. 可拔插的架构设计

7. 低资源要求

8. 内置高可靠性

fluentd与Logstash

引用一张图对比这两个日志收集工具。具体它们两个项目的对比请参考：

Fluentd vs. Logstash: A Comparison of Log Collectors

fluentd与zeroMQ

把这两个产品放在一起比较实属不怎么合适，因为它们属于不同的阵营，完成不同的功能需求。由于fluentd具有消息转发的功能，姑且将其与以zeroMQ为例的消息中间件的关系做个说明： 在大型系统架构中，有使用zeroMQ进行大量的日志转发工作。在fluentd中有两个项目完成日志的中转路由的任务：golang编写的：fluentd-forwarder 和c写的fluent-bit

那么是否意味着你需要做出选择呢？其实不然。 着眼fluentd的定义和zeroMQ的定义。其实它们是一种合作关系。如果你是大型的架构系统，日志量很庞大。我推荐你使用fluentd进行日志收集，将zeroMQ作为fluentd的出口。就是说fluentd完成统一收集，zeroMQ完成日志传输。如果你的系统并不庞大，你就无需zeroMQ来传输了。

因此你也无需关注这两个产品的性能比较。虽然它们都有高性能的定义。

zeroMQ的性能测试结果：zeroMQ 与JeroMQ性能对比

容器日志收集总结

如上所描述的一样，无论你的业务容器日志呈现方式有什么不同，你都可以使用统一的日志收集器收集。以下简介三种情况下日志手机方式推荐：

1. k8s集群
   这种方式上文中已经提到了官方的解决方案，你只需要安装此方案部署即可。

2. docker swarm集群
   docker swarm目前暂时没有提供日志查看机制。但是docker cloud提供了与kubectrl logs类似的机制查看stdout的日志。目前还没有fluentd插件直接对服务进行日志收集，暂时考虑直接使用使用跟容器一样的机制收集。docker service create 支持--log-driver

3. 自己部署的docker容器
   从docker1.8内置了fluentd log driver。以如下的形式启动容器，容器stdout/stderr日志将发往配置的fluentd。如果配置后，

   如何进行关于k8集群器日志收集的总结