JMS的API结构

Pod-1

Logdir

容器内日志收集主要解决方案

server-1

Log-collector

server-3

方案说明：日志采集插件（Log-collector）与应用（App）部署在一起，日志采插件作为后台成运行，应用将日志写入容器环境的操作系统目录当中，日志采集插件读取日志并进行预处理，完成后送到MQ当中，最后与方案1                   一样，将日志持久化到ElasticSearch当中                 为了解决宿主机日志收集存在的问题，同时不增加工作量和难度，我们可以考虑将日志采集工具集成到应用的基础镜像之中，应用基于基础镜像来生成应用镜像，在镜像启动的时候会把日志采集工具以后台进程的方                   式拉起来，搜集到日志后，日志采集工具可以将日志送到消息中间件，如Kafka，再由Logstash解析入ElasticSearch，最终用户可以通过Kibana进行日志检索。基于上述方式的部署，我们将采集工具和应用部署到                   一起，这样我们就能轻松的在日志采集工程中标识出日志所属的应用，同时因为日志是按照文件格式落到容器内部，一般的日志采集工具都能够通过multiline的方式来处理异常堆栈信息。对于日志增多的问题，还                     是需要应用引入滚动日志工具来解决 优点：实现难度小，不增加工作量，同时能够准确的标识出日志所述的应用和所属的文件，使得应用方能够更加精确的管理日志缺点：每个应用镜像中都会引入额外的日志采集工具，增加了应用容器额外的资源开销，同时日志采集工具和应用基础镜像紧耦合

server-2

Log Collector

Connection

ConnectionFactory

ELK

Pod-2

send To

方案说明： 通过在容器所在的宿主机部署日志采集插件（Log-collector）来对容器中的日志进行采集，采集预处理后输出到外部的消息队列当中（入Kafka等），在由通过类似于ELK的框架进行处理，最终日志持久化到                   ElasticSearch当中。                 我们知道，容器内应用输出到标准输出（stdout）和（标准错误输出）stderr的日志会被容器引擎所处理，例如docker就可以配置其日志引擎（logging driver），默认的logging driver是json-file，那么                   通过在宿主机中查看对应容器的logs文件，就可以查看到应用容器输出到标准输出的日志内容。优点：这样方式的部署，优点在于部署简单，日志采集资源开销小。缺点：         1. 应用容器的日志输出到stdout和stderr，同时被容器引擎处理后存储到宿主机本地，随着日志的增多（如果应用容器不停止），会大量占用宿主机磁盘空间             解决思路：引入滚动日志工具，将日志进行切割，并滚动生成，这样落盘的日志就不会一直消耗本地存储空间         2.我们在宿主机上进行日志采集，会统一部署一套日志采集工具，那么如何来标记日志是属于哪个应用以及日志属于哪个容器？            解决思路：对日志采集工具进行开发或者引入开源的日志采集工具，监听到容器的启动和停止，从而能建立容器与日志的对应关系，从而在采集日志的时候标识出日志属于哪个容器。         3.json-file格式的日志，对于某些开发语言（例如JAVA）异常堆栈信息是被分行处理，日志采集后还需要进行二次加工。            解决思路：目前来看只能通过对日志采集工具进行二次开发或者对日志进行二次处理来解决。可以看出，为了解决上述问题，我们不得不进行一些二次开发和处理工作，这增加了工作量和难度，所以除非有充足资源的情况下，可以采取该方案    

App Container

receivers From

App ProcessLog collector process

Container-3

create

Container-1

Pod-3

Session

方案说明：在Kubernetes中，Pod中可以存在多个容器，这些容器之间可以通过emptyDir的方式共享文件系统，基于上述的原理，我们能够将日志采集工具从应用基础镜像中剥离出来，单独部署于一个容器中，这个日志容                   器与应用容器存在于一个Pod之中，他们之间共享应用容器的日志文件，从而实现应用容器将日志写入本地容器内部文件，日志采集容器读取文件内容并进行解析和传输。优点：减小了日志采集工具与应用基础镜像的耦合缺点：每个应用Pod内都需要启动一个Sidecar日志采集容器，不过通过实际观察来看，该Sidecar日志采集容器只需要很小的资源，即可完成日志采集

Message

总结：        三种方案各有优劣点，方案一是比较理想的实施方式，其部署方式资源开销小，同时对应用侵入小，如果能够解决日志标识等问题，该方案应该是首选。方案二和方案三实施技术难度低，但对应用侵入较大，系统资源开            销也稍多一些。

MessageProducer

方案一：在宿主机上面实现日志采集

方案二：在镜像内集成日志采集组件

MQ

MessageConsumer

Container-2

Destination

方案三：基于Sidecar日志采集方式