做开发的同学都知道日志的重要性,日志的种类一般有接口日志、错误日志、关键步骤日志、用户操作日志等。本文首要详细讲解运用kubernetes容器化布置的服务该如何记载和收集日志。

一、运用标准输出方法

将想要记载的日志内容输出到stdout或stderr即可(DockerEngine本身具有LogDriver 功用,可经过配置不同的LogDriver将容器的stdout经过DockerEngine写入到日志体系),由DockerEngine将日志写入到日志体系。

这种方法的长处是运用简单,可是缺陷也十分明显。所有的输出都混在一个流中,无法像文件一样分类输出,一个应用中一般都有几种类型的日志,这些日志的格局、用处不一,混在同一个流中将很难做分类和分析。

虽然运用Stdout是Docker官方引荐的方法,可是仅限于简单的场景。这种方法可定制化、灵活性、资源隔离性都比较差,一般不主张在出产环境中运用。

二、服务直写方法

在服务代码中将日志直接发送到日志体系(集成所运用日志体系的SDK或者自己实现SDK)。

这种方法的长处是日志文件不需求暂时存储到磁盘,也不需求布置额定的日志收集Agent,可根据事务特点进行定制,不受集群规模限制。

缺陷是日志直写会占用一定的服务器资源,例如cpu、内存、特别是网络IO,会影响服务的整体功能。

三、DaemonSet方法

经过修正Deployment文件使服务容器和宿主机同享一个目录,服务将日志输出这个目录下面。运用DaemonSet方法在每个node节点上面运转一个日志收集agent(例如filebeat、fluentd、logstash等)收集这个节点上指定目录下的所有日志文件到日志体系。

这种方法的长处资源相对占用要小许多,也可以做到日志分类收集,日志收集简直不影响服务的功能。缺陷是扩展性受限。

四、Sidecar 方法

经过修正Deployment文件在一个pod里面运转两个容器,一个容器运转服务,另一个容器运转日志收集agent,而且让这两个容器同享同一个目录,服务将日志输出这个目录下面,日志收集agent收集这个目录下的所有的日志文件到日志体系。

这种方法的长处是日志收集容器和事务服务容器是独立的,体系资源不会相互影响 ,灵活性强,不受集群规模限制。

缺陷是资源相对占用较多,由于针对每一个服务都要布置一个独立的agent容器,运维成本也相对较高。

小结

本文详细讲解了收集kubernetes容器化布置的服务日志的四种方法,每种方法都有优缺陷和对应的运用场景,需求根据实践场景挑选最合适的方法。