2023年6月30日发(作者：)

K8S集群⽇志收集⽅案K8S集群⽇志收集⽅案K8S集群⽇志收集⽅案在⼤型分布式部署的架构中，不同的服务模块部署在不同的服务器中，问题出现时，⼤部分情况需要根据问题暴露的关键信息定位具体的服务器和服务模块。常见的解决思路是建⽴⼀套集中式⽇志收集系统，将所有节点上的⽇志统⼀收集、管理、访问，将极⼤提⾼定位问题的效率。⼀个完整的集中式⽇志系统，需要包含以下⼏个主要特点：收集－能够采集多种来源的⽇志数据传输－能够稳定的把⽇志数据传输到中央系统存储－如何存储⽇志数据分析－可以⽀持 UI 分析警告－能够提供错误报告，监控机制⽬前在K8S集群内部收集⽇志有以下⼏种⽅案编号⽅案优点缺点1每个app的镜像中都集成⽇志收集组件部署⽅便，kubernetes的yaml⽂件⽆须特别配置，可以为每个app⾃定义⽇志收集配置强耦合，不⽅便应⽤和⽇志收集组件升级和维护且会导致镜像过⼤需要对kubernetes的yaml⽂件进⾏单独配置，略显繁琐2单独创建⼀个⽇志收集组件跟app的容器⼀起运⾏在同⼀个pod中将所有的Pod的⽇志都挂载到宿主机上，每台主机上单独起⼀个⽇志收集Pod低耦合，扩展性强，⽅便维护和升级3完全解耦，性能最⾼，管理起来最⽅便需要统⼀⽇志收集规则，⽬录和输出⽅式⽅案⼀基本不考虑⽅案⼆⽅案⼆就是常见的ELK（Elasticsearch、Logstash、Kibana）+ Filebeat。引⼊了各类Lib Beats（Package Beat、Top Beat、FileBeat等）运⾏在app应⽤的Pod中收集⽇志，转发给Logstash。此⽅案将⼿机端的Logstash替换为beats，更灵活，消耗资源更少，扩展性更强。同时可配置Logstash 和Elasticsearch 集群⽤于⽀持⼤集群系统的运维⽇志数据监控和查询。简单介绍下ELKElasticsearch + Logstash + Kibana（ELK）是⼀套开源的⽇志管理⽅案Logstash：负责⽇志的收集，处理和储存Elasticsearch：负责⽇志检索和分析Kibana：负责⽇志的可视化Elasticsearch简介默认情况下，ES集群节点都是混合节点，即在中默认: true和: true。当ES集群规模达到⼀定程度以后，就需要注意对集群节点进⾏⾓⾊划分。ES集群节点可以划分为三种：主节点、数据节点和客户端节点。master-主节点 维护元数据，管理集群节点状态；不负责数据写⼊和查询。: : falsedata-数据节点 负责数据的写⼊与查询，压⼒⼤。: : truedata-客户端节点 负责任务分发和结果汇聚，分担数据节点压⼒。: : falsedata-混合节点 综合上述三个节点的功能。: : trueFilebeat⼯作原理Filebeat由两个主要组件组成：prospectors 和 harvesters。这两个组件协同⼯作将⽂件变动发送到指定的输出中。Harvester（收割机）：负责读取单个⽂件内容。每个⽂件会启动⼀个Harvester，每个Harvester会逐⾏读取各个⽂件，并将⽂件内容发送到制定输出中。Harvester负责打开和关闭⽂件，意味在Harvester运⾏的时候，⽂件描述符处于打开状态，如果⽂件在收集中被重命名或者被删除，Filebeat会继续读取此⽂件。所以在Harvester关闭之前，磁盘不会被释放。默认情况filebeat会保持⽂件打开的状态，直到达到close_inactive（如果此选项开启，filebeat会在指定时间内将不再更新的⽂件句柄关闭，时间从harvester读取最后⼀⾏的时间开始计时。若⽂件句柄被关闭后，⽂件发⽣变化，则会启动⼀个新的harvester。关闭⽂件句柄的时间不取决于⽂件的修改时间，若此参数配置不当，则可能发⽣⽇志不实时的情况，由scan_frequency参数决定，默认10s。Harvester使⽤内部时间戳来记录⽂件最后被收集的时间。例如：设置5m，则在Harvester读取⽂件的最后⼀⾏之后，开始倒计时5分钟，若5分钟内⽂件⽆变化，则关闭⽂件句柄。默认5m）。Prospector（勘测者）：负责管理Harvester并找到所有读取源。ctors:- input_type: log paths: - /apps/logs/*/spector会找到/apps/logs/*⽬录下的所有⽂件，并为每个⽂件启动⼀个Harvester。Prospector会检查每个⽂件，看Harvester是否已经启动，是否需要启动，或者⽂件是否可以忽略。若Harvester关闭，只有在⽂件⼤⼩发⽣变化的时候Prospector才会执⾏检查。只能检测本地的⽂件。Filebeat如何记录⽂件状态：将⽂件状态记录在⽂件中（默认在/var/lib/filebeat/registry）。此状态可以记住Harvester收集⽂件的偏移量。若连接不上输出设备，如ES等，filebeat会记录发送前的最后⼀⾏，并再可以连接的时候继续发送。Filebeat在运⾏的时候，Prospector状态会被记录在内存中。Filebeat重启的时候，利⽤registry记录的状态来进⾏重建，⽤来还原到重启之前的状态。每个Prospector会为每个找到的⽂件记录⼀个状态，对于每个⽂件，Filebeat存储唯⼀标识符以检测⽂件是否先前被收集。Filebeat如何保证事件⾄少被输出⼀次：Filebeat之所以能保证事件⾄少被传递到配置的输出⼀次，没有数据丢失，是因为filebeat将每个事件的传递状态保存在⽂件中。在未得到输出⽅确认时，filebeat会尝试⼀直发送，直到得到回应。若filebeat在传输过程中被关闭，则不会再关闭之前确认所有时事件。任何在filebeat关闭之前为确认的时间，都会在filebeat重启之后重新发送。这可确保⾄少发送⼀次，但有可能会重复。可通过设置shutdown_timeout 参数来设置关闭之前的等待事件回应的时间（默认禁⽤）。Logstash⼯作原理：Logstash事件处理有三个阶段：inputs → filters → outputs。是⼀个接收，处理，转发⽇志的⼯具。⽀持系统⽇志，webserver⽇志，错误⽇志，应⽤⽇志，总之包括所有可以抛出来的⽇志类型。Input：输⼊数据到logstash。⼀些常⽤的输⼊为：file：从⽂件系统的⽂件中读取，类似于tial -f命令syslog：在514端⼝上监听系统⽇志消息，并根据RFC3164标准进⾏解析redis：从redis service中读取beats：从filebeat中读取Filters：数据中间处理，对数据进⾏操作。⼀些常⽤的过滤器为：grok：解析任意⽂本数据，Grok 是 Logstash 最重要的插件。它的主要作⽤就是将⽂本格式的字符串，转换成为具体的结构化的数据，配合正则表达式使⽤。内置120多个解析语法。mutate：对字段进⾏转换。例如对字段进⾏删除、替换、修改、重命名等。drop：丢弃⼀部分events不进⾏处理。clone：拷贝 event，这个过程中也可以添加或移除字段。geoip：添加地理信息(为前台kibana图形化展⽰使⽤)**Outputs：outputs是logstash处理管道的最末端组件。**⼀个event可以在处理过程中经过多重输出，但是⼀旦所有的outputs都执⾏结束，这个event也就完成⽣命周期。⼀些常见的outputs为：elasticsearch：可以⾼效的保存数据，并且能够⽅便和简单的进⾏查询。file：将event数据保存到⽂件中。graphite：将event数据发送到图形化组件中，⼀个很流⾏的开源存储图形化展⽰的组件。Codecs：codecs 是基于数据流的过滤器，它可以作为input，output的⼀部分配置。Codecs可以帮助你轻松的分割发送过来已经被序列化的数据。⼀些常见的codecs：json：使⽤json格式对数据进⾏编码/解码。multiline：将汇多个事件中数据汇总为⼀个单⼀的⾏。⽐如：java异常信息和堆栈信息。为什么要在ELK基础上引⼊Lib Beats？在进⾏⽇志收集的过程中，我们⾸先想到的是使⽤Logstash，因为它是ELK stack中的重要成员，但是在测试过程中发现，Logstash是基于JDK的，在没有产⽣⽇志的情况单纯启动Logstash就⼤概要消耗500M内存，在每个Pod中都启动⼀个⽇志收集组件的情况下，使⽤logstash有点浪费系统资源，我们选择使⽤Filebeat替代，经测试单独启动Filebeat容器⼤约会消耗12M内存，⽐起logstash相当轻量级。Kibana简介Kibana通常与 Elasticsearch ⼀起部署，Kibana 是 Elasticsearch 的⼀个功能强⼤的数据可视化 Dashboard，Kibana 允许你通过 web界⾯来浏览 Elasticsearch ⽇志数据。⽅案三此⽅案就是K8S官⽅推荐的EFK（ELasticsearch、Fluentd、Kibana）⽅案此⽅案通过DaemonSet的⽅式在集群内部每个节点上运⾏⼀个Fluent Pod统⼀收集上层应⽤层的⽇志并反馈到ElasticsearchFluentd简介Fluentd是⼀个Ruby语⾔开发的开源数据收集器，通过它能对数据进⾏统⼀收集和消费，能够更好地使⽤和理解数据。Fluentd将数据结构化为JSON，从⽽能够统⼀处理⽇志数据，包括：收集、过滤、缓存和输出。Fluentd是⼀个基于插件体系的架构，包括输⼊插件、输出插件、过滤插件、解析插件、格式化插件、缓存插件和存储插件，通过插件可以扩展和更好的使⽤Fluentd。Fluentd 通过⼀组给定的数据源抓取⽇志数据，处理后（转换成结构化的数据格式）将它们转发给其他服务，⽐如 Elasticsearch、对象存储等等。Fluentd ⽀持超过300个⽇志存储和分析服务，所以在这⽅⾯是⾮常灵活的。主要运⾏步骤如下：⾸先 Fluentd 从多个⽇志源获取数据结构化并且标记这些数据然后根据匹配的标签将数据发送到多个⽬标服务去Fluentd配置⼀般来说我们是通过⼀个配置⽂件来告诉 Fluentd 如何采集、处理数据的，下⾯简单和⼤家介绍下 Fluentd 的配置⽅法。⽇志源配置⽐如我们这⾥为了收集 Kubernetes 节点上的所有容器⽇志，就需要做如下的⽇志源配置：@id @type tailpath /var/log/containers/*.logpos_file /var/log/e_format %Y-%m-%dT%H:%M:%S.%NZtag etes.*format jsonread_from_head true上⾯配置部分参数说明如下：id：表⽰引⽤该⽇志源的唯⼀标识符，该标识可⽤于进⼀步过滤和路由结构化⽇志数据type：Fluentd 内置的指令，tail表⽰ Fluentd 从上次读取的位置通过 tail 不断获取数据，另外⼀个是http表⽰通过⼀个 GET 请求来收集数据。path：tail类型下的特定参数，告诉 Fluentd 采集/var/log/containers⽬录下的所有⽇志，这是 docker 在Kubernetes 节点上⽤来存储运⾏容器 stdout 输出⽇志数据的⽬录。pos_file：检查点，如果 Fluentd 程序重新启动了，它将使⽤此⽂件中的位置来恢复⽇志数据收集。tag：⽤来将⽇志源与⽬标或者过滤器匹配的⾃定义字符串，Fluentd 匹配源/⽬标标签来路由⽇志数据。路由配置上⾯是⽇志源的配置，接下来看看如何将⽇志数据发送到 Elasticsearch：@id elasticsearch@type elasticsearch@log_level infoinclude_tag_key truetype_name fluentdhost "#{ENV['OUTPUT_HOST']}"port "#{ENV['OUTPUT_PORT']}"logstash_format true@type filepath /var/log/fluentd-buffers/flush_mode intervalretry_type exponential_backoffflush_thread_count 2flush_interval 5sretry_foreverretry_max_interval 30chunk_limit_size "#{ENV['OUTPUT_BUFFER_CHUNK_LIMIT']}"queue_limit_length "#{ENV['OUTPUT_BUFFER_QUEUE_LIMIT']}"overflow_action blockmatch：标识⼀个⽬标标签，后⾯是⼀个匹配⽇志源的正则表达式，我们这⾥想要捕获所有的⽇志并将它们发送给 Elasticsearch，所以需要配置成**。id：⽬标的⼀个唯⼀标识符。type：⽀持的输出插件标识符，我们这⾥要输出到 Elasticsearch，所以配置成 elasticsearch，这是 Fluentd 的⼀个内置插件。log_level：指定要捕获的⽇志级别，我们这⾥配置成info，表⽰任何该级别或者该级别以上（INFO、WARNING、ERROR）的⽇志都将被路由到 Elsasticsearch。host/port：定义 Elasticsearch 的地址，也可以配置认证信息，我们的 Elasticsearch 不需要认证，所以这⾥直接指定 host 和 port即可。logstash_format：Elasticsearch 服务对⽇志数据构建反向索引进⾏搜索，将 logstash_format 设置为true，Fluentd 将会以logstash 格式来转发结构化的⽇志数据。Buffer： Fluentd 允许在⽬标不可⽤时进⾏缓存，⽐如，如果⽹络出现故障或者 Elasticsearch 不可⽤的时候。缓冲区配置也有助于降低磁盘的 IO。Docker Image获取所需Docker image都可以从DockerHub或者获取⽬前Elasticsearch、Logstash、Kibana、Filebeat以及Fluentd都没有官⽅的ARM64镜像但是，Elasticsearch、Logstash、Kibana有提供DockerFile，另外，此三组件镜像版本必须⼀致Filebeat和Fluentd的⾮官⽅镜像：kasaoden/filebeat:7.2.0-arm64carlosedp/fluentd-elasticsearch:latest