共计 1657 个字符，预计需要花费 5 分钟才能阅读完成。
随着云原生技术的疾速倒退，微服务架构、容器及 Kubernetes 等技术的一直迭代，对于海量日志的治理提出了更高的要求，如容器内磁盘是否长久化，HPA 时如何保证数据不失落，海量日志如何进行牢靠的传输，微服务数量达到肯定规模时日志该如何治理，另外，不同的云商之间有各自的免费策略，应该怎么做到最大化节省成本等等。
【云资源优化服务 SpotMax 充分利用云原生个性，基于微服务架构，可在保障用户服务稳固的同时充分利用 Spot 实例，实现云端降本增效。戳链接理解 SpotMax】
“云原生日志流实战”将会通过实操加解说的形式，和大家一起探讨在云背景下收集海日志的架构及实现细节。接下来为大家展现的这套架构，目前曾经通过实际测验，稳固撑持了线上每日百亿至千级别的日志的收集。咱们将一步步率领大家入手实现一个部署在 k8s 集群的日志采集器。
fluentd 与 Docker
市场上罕用的开源日志采集工具个别有 logstash、FLUME、fluentd。其中 FLUME、fluentd 的设计理念比拟相像。fluentd 是基于 C + Ruby 的一套开源工具，FLUME 是分布式的、牢靠、可用的 Apache 我的项目，然而绝对 fluentd 来说，配置较为简单。本次课程咱们次要应用的是较为轻量级的开源工具 fluentd。
fluentd 配置简略，对日志的预处理也非常简单不便。咱们来看一下 fluentd 官网的 document（docs.fluentd.org)：
首先来看 input、output 插件。应用 input 插件，咱们能够从本地、或者通过 tcp、udp 流获取到日志，而后咱们会给每一个日志打 tag，前面通过 match 该 tag 能够做进一步的解决：如过滤、格式化等。最终咱们能够通过 Output 插件实现落地。例如落到本地文件，或者存到亚马逊的 s3，或打到 kafka，等等。
左侧菜单栏中可见 container deployment，其中有 docker image——这就是 docker 的一个根底镜像。咱们在前面的实操中会从这里获取到根底镜像，来生成一个容器。
简略介绍一下 Docker 的个性：docker 采纳的是沙盒机制，即每个运行的程序是做资源隔离的，不同程序之间不会相互影响。
如下图所示，docker 采纳了一种远程管理形式。这里有两个概念：image 镜像、container 容器，他们的关系就像一个类和对象的关系一样，一个 image 能够生成多个 container。
咱们能够通过 dockerbuild 的形式来 build 一个镜像，能够通过 docker pull/push 的形式，以及 dockerhub（相似 github）做一个近程的提交，也能够用 docker run 指定一个镜像，运行一个容器。
日志采集器架构
首先，咱们看一下采集器的简略架构，假如咱们有一个 http 的服务，产生了一个日志。个别的状况下，咱们会在本地部署一个 crontab 做一个定时工作的压缩上传，也可能会把它打到一个实时的 kafka 队列。
个别状况下这么解决，是没有问题的，但如果咱们的服务性能足够好，产生了大量的日志，会产生什么？
如下是 CPU 的负载图：咱们看到每小时都有一个尖峰，因为每小时咱们做一个压缩，上传的时候会占肯定的 CPU，因而十分不利于抗流量服务，做 hpa(主动伸缩)。此外，解决日志的程序，跟业务机耦合在一起，也会占肯定的资源。
那么，怎么解决这个问题？
如果咱们面对的是海量日志，对数据的一致性要求没有那么高，咱们就会想到：能不能先把日志通过实时的形式传到另外一个集群，由该集群做反对解决？
因而，咱们演化出这样的一个架构：
能够看到，该架构中多了一个日志聚合层的集群。咱们能够在抗流量服务机器上部署 fluentd 的 client 端，在聚合层部署 fluentd 的 server 端。这样，咱们就能够把日志通过 TCP、UDP 实时传输到日志聚合层，由聚合层做一个解决。
因而，咱们要率领大家实现的，就是如何把日志聚合层，打包成一个产品，最终部署到 k8s 集群上。下一期，咱们将率领大家实现简略的实操演示