【Kubernetes 企业项目实战】04、基于 K8s 构建 EFK+logs
目录
一、日志对我们来说到底重不重要？
日志打印的常见级别
二、常见的日志收集方案
2.1 EFK
2.2 ELK Stack
2.3ELK+
2.4 其他方案
三、EFK 组件详细介绍
3.1 组件介绍
3.2 组件介绍
1） 和 Beat 关系
2） 是什么？
3） 工作原理
4）传输方案
3.3 组件介绍
1） 工作原理
2）常用 input 模块
3）常用的 模块
4）常用
5）常用 code 插件
3.4 组件介绍
3.5 、、 对比分析
1）
2）
3）
4）
5）
6）
k8s 集群角色
IP
主机名
配置
控制节点
192.168.78.143
k8s-
3vcpu / 3Gi 内存
工作节点
192.168.78.144
k8s-node1
3vcpu / 3Gi 内存
工作节点
192.168.78.145
k8s-node2
3vcpu / 3Gi 内存
一、日志对我们来说到底重不重要？
在生产环境或者测试环境，如果某个服务或者业务组件出现问题，如何定位和排查？需要靠日志，日志是定位问题的重要手段，就像办案人员要根据现场留下的线索推断案情一样。
监控和日志是企业必须具备的。
日志打印的常见级别
日志打印通常有四种级别，从高到底分别是：ERROR、WARN、INFO、DEBUG。应该选用哪种级别是个很重要的问题。
日志级别中的优先级是什么意思？在你的系统中如果开启了某一级别的日志后，就不会打印比它级别低的日志。例如，程序如果开启了 INFO 级别日志，DEBUG 日志就不会打印，通常在生产环境中开启INFO 日志。
那么应该打印什么级别的日志呢？首先我们应该明确谁在看日志。
通常来说，系统出了问题客户不会进到系统对着控制台查看日志输出，所以日志所面对的主体对象必然是软件开发人员(包括测试测试、维护人员)。
下面我们假设几种场景来帮助我们理解日志级别：
程序开发结束后交由给测试人员进行测试，测试人员根据测试用例发现某个用例的输出和预期不符，此时他的一反应该是查看日志。此时的日志是 INFO 级别日志不会出现 DEBUG 级别的日志，现在就需要根据日志打印分为两种情况决定他下一步操作：
通过查看 INFO 日志发现是由于自己操作失误，造成了程序结果和预期不符合，这种情况不是程序出错，所以并不是 bug，不需要开发人员到场。
通过查看 INFO 日志发现自己的操作正确，根据 INFO 日志查看并不是操作失误造成，这个时候就需要开发人员到场确认。
以上两种情况是理想情况，测试人员仅根据 INFO 级别的日志就能判断出程序的输出结果与预期不符是因为自己操作失误还是程序 bug。更为现实的情况实际是测试人员并不能根据 INFO 级别的日志判断是否是自己失误还是程序 bug。
综上，INFO 级别的日志应该是能帮助测试人员判断这是否是一个真正的 bug，而不是自己操作失误造成的。假设测试人员现在已经初步判断这是一个 bug，并且这个 bug 不那么明显，此时就需要开发人员到场确认。开发人员到达现场后，第一步应该是查看 INFO 日志初步作判断验证测试人员的看法，接着如果不能判断出问题所在则应该是将日志级别调整至 DEBUG 级别，打印出DEBUG 级别的日志，通过 DEBUG 日志来分析定位 bug 出在哪里。所以，DEBUG 级别的日志应该是能帮助开发人员分析定位 bug 所在的位置。
ERROR 和 WARN 的级别都比 INFO 要高，所以在设定日志级别在 INFO 时，这两者的日志也会被打印。根据上面 INFO 和 DEBUG 级别的区别以及适用人员可以知道，ERROR 和 WARN 是同时给测试和开发、运维观察的。WARN 级别称之为“警告”，这个“警告”实际上就有点含糊了，它不算错，你可以选择忽视它，但也可以选择重视它。例如，现在一个 WARN 日志打出这么一条日志“系统有崩溃的风险”，这个时候就需要引起足够的重视，它代表现在不会崩溃，但是它有崩溃的风险。或者出现“某用户在短时间内将密码输出很多次过后才进入了系统”，这个时候是不是系统被暴力破解了呢？这个级别日志如同它的字面含义，给你一个警告，你可以选择忽视，也可以重视，但至少它现在不会给系统带来其他影响。
ERROR 级别称之为“错误”，这个含义就更明显了，就是系统出现了错误，需要处理。较为常见的就是捕获异常时所打印的日志。
二、常见的日志收集方案
常见的进行日志分析的方法：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，把所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
对大量的日志业务数据进行分析，如平台 PV、UV、IP、 等维度进行分析查询等。另外安全审计、数据挖掘、行为分析等都少不了日志对其作为支撑。
2.1 EFK
在 集群上运行多个服务和应用程序时，日志收集系统可以帮助你快速分类和分析由 Pod 生成的大量日志数据。 中比较流行的日志收集解决方案是 、 和 （EFK）技术栈，也是官方推荐的一种方案。
是一个实时的，分布式的，可扩展的搜索引擎，它允许进行全文本和结构化搜索以及对日志进行分析。它通常用于索引和搜索大量日志数据，也可以用于搜索许多不同种类的文档。
通常与 一起部署， 可以把 采集到的数据通过（仪表板）可视化展示出来。 允许你通过 Web 界面浏览 日志数据，也可自定义查询条件快速检索出 中的日志数据。
是一个流行的开源数据收集器，我们在 集群节点上安装 ，通过获取容器日志文件、过滤和转换日志数据，然后将数据传递到 集群，在该集群中对其进行索引和存储。
2.2 ELK Stack
：日志存储和搜索引擎。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制， 风格接口，多数据源，自动搜索负载等。
：是一个完全开源的工具，他可以对你的日志进行收集、过滤，并将其存储供以后使用（支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作）。
：是一个开源和免费的工具， 可以为 和 提供的日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。
工作流程：
应用程序（）–> –> –> –> 浏览器（）：
收集 产生的 Log，并存放到 集群中，而 则从 集群中查询数据生成图表，再返回给 。
考虑到聚合端（日志处理、清洗等）负载问题和采集端传输效率，一般在日志量比较大的时候在采集端和聚合端增加队列，以用来实现日志消峰。
2.3ELK+
（采集）—> （聚合、处理）—> （存储）—> （展示）
2.4 其他方案
ELK 日志流程可以有多种方案（不同组件可自由组合，根据自身业务配置），常见有以下：
三、EFK 组件详细介绍 3.1 组件介绍
是一个分布式的免费开源搜索和分析引擎，适用于包括文本、数字、地理空间、结构化和非结构化数据等在内的所有类型的数据。 在 的基础上开发而成，由 N.V.（即现在的 ）于 2010 年首次发布。 以其简单的 REST 风格 API、分布式特性、速度和可扩展性而闻名，是 Stack 的核心组件； Stack 是一套适用于数据采集、扩充、存储、分析和可视化的免费开源工具。人们通常将 Stack 称为 ELK Stack（代指 、 和 ），目前 Stack 包括一系列丰富的轻量型数据采集代理，这些代理统称为 Beats，可用来向 发送数据。
3.2 组件介绍
是 Beats中的一员。Beats 是一个轻量级日志采集器，Beats 家族有 6 个成员，早期的 ELK 架构中使用 收集、解析日志，但是 对内存、cpu、io 等资源消耗比较高。相比 ，Beats 所占系统的 CPU 和内存几乎可以忽略不计。
目前 Beats 包含六种工具：
：网络数据（收集网络流量数据）；：指标（收集系统、进程和文件系统级别的CPU和内存使用情况等数据）；：日志文件（收集文件数据）；：事件日志（收集事件日志数据）；：审计数据（收集审计日志）；：运行时间监控（收集系统运行时的数据）。
是用于转发和收集日志数据的轻量级传送工具。 监视你指定的日志文件或位置，收集日志事件，并将它们转发到 或 中。
的工作方式如下：启动 时，它将启动一个或多个输入，这些输入将在为日志数据指定的位置中查找。对于 所找到的每个日志， 都会启动收集器。每个收集器都读取单个日志以获取新内容，并将新日志数据发送到 ， 将聚集事件，并将聚集的数据发送到为 配置的输出。
工作的流程图如下：
有两个主要组件：
：一个 负责读取一个单个文件的内容。 逐行读取每个文件，并把这些内容发送到输出。每个日志文件启动一个 。
Input：一个 input 负责管理 ，并找到所有要读取的源。如果 input 类型是 log，则inpu t查找驱动器上与已定义的 log 日志路径匹配的所有文件，并为每个文件启动一个 。
在任何环境下，应用程序都有停机的可能性。 读取并转发日志行，如果中断，则会记住所有事件恢复联机状态时所在位置。
带有内部模块（，，Nginx， 和 MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。
不会让你的管道超负荷。 如果是向 传输数据，当 忙于处理数据，会通知 放慢读取速度。一旦拥塞得到解决， 将恢复到原来的速度并继续传播。
保持每个文件的状态，并经常刷新注册表文件中的磁盘状态。状态用于记住 正在读取的最后偏移量，并确保发送所有日志行。 将每个事件的传递状态存储在注册表文件中。所以它能保证事件至少传递一次到配置的输出，没有数据丢失。
1、.
如果你希望使用 直接向 输出数据，需要配置 .：
output.elasticsearch:hosts: ["192.168.78.143:9200"]2、.
如果使用 t向 输出数据，然后由 再向 输出数据，需要配置 .。 和 一起工作时，如果 忙于处理数据，会通知 放慢读取速度。一旦拥塞得到解决， 将恢复到原来的速度并继续传播。这样，可以减少管道超负荷的情况。
output.logstash:hosts: ["192.168.78.143:5044"] 3、.kafka
如果使用 向 kafka 输出数据，然后由 作为消费者拉取 kafka 中的日志，并再向 输出数据，需要配置 .：
output.kafka:enabled: truehosts: ["192.168.78.143:9092"]topic: elfk8stest3.3 组件介绍
是一个开源数据收集引擎，具有实时管道功能。 可以动态地将来自不同数据源的数据统一起来，并将数据标准化到你所选择的目的地。 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理，提供 Web 接口用于查询和统计。
数据往往以各种各样的形式，或分散或集中地存在于很多系统中。 支持各种输入选择 ，可以在同一时间从众多常用来源捕捉事件。能够以连续的流式传输方式，轻松地从你的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。
数据从源传输到存储库的过程中， 过滤器能够解析各个事件，识别已命名的字段以构建结构，并将它们转换成通用格式，以便更轻松、更快速地分析和实现商业价值。
能够动态地转换和解析数据，不受格式或复杂度的影响：
1、利用 Grok 从非结构化数据中派生出结构；
2、从 IP 地址破译出地理坐标；
3、将 PII 数据匿名化，完全排除敏感字段；
4、整体处理不受数据源、格式或架构的影响。
尽管 是我们的首选输出方向，能够为我们的搜索和分析带来无限可能，但它并非唯一选择。 提供众多输出选择，你可以将数据发送到你要指定的地方。
有两个必要元素：input 和 ，一个可选元素：。 这三个元素，分别代表 事件处理的三个阶段：输入 > 过滤器 > 输出
在实际应用场景中，通常输入、输出、过滤器不止一个。 的这三个元素都使用插件式管理方式，可以根据应用需要，灵活的选用各阶段需要的插件，并组合使用。
支持各种输入选择 ，可以在同一时间从众多常用来源捕捉事件。能够以连续的流式传输方式，可从日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。
过滤器是 管道中的中间处理设备。可以将条件过滤器组合在一起，对事件执行操作。
input {kafka {bootstrap_servers => "192.168.78.143:9092"auto_offset_reset => "latest"consumer_threads => 5decorate_events => truetopics => ["elktest"]}
}output { elasticsearch { hosts => ["192.168.78.143:9200"]index => "elkk8stest-%{+YYYY.MM.dd}"}
} 3.4 组件介绍
是一个针对日志的收集、处理、转发系统。通过丰富的插件系统，可以收集来自于各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统之中。
常常被拿来和 比较，我们常说 ELK，L 就是这个 agent。 是随着 和 es 一起流行起来的 agent。
3.5 、、 对比分析
常见的日志采集工具有 、、、、 等等，那么他们之间有什么区别呢？什么情况下我们应该用哪一种工具？
是一个开源数据收集引擎，具有实时管道功能。 可以动态地将来自不同数据源的数据统一起来，并将数据标准化到你所选择的目的地。
优势
主要的优点就是它的灵活性，主要因为它有很多插件，详细的文档以及直白的配置格式让它可以在多种场景下应用。我们基本上可以在网上找到很多资源，几乎可以处理任何问题。
劣势
致命的问题是它的性能以及资源消耗(默认的堆大小是 1GB)。尽管它的性能在近几年已经有很大提升，与它的替代者们相比还是要慢很多的。这里有 与 性能对比以及 与 的性能对比。它在大数据量的情况下会是个问题。
另一个问题是它目前不支持缓存，目前的典型替代方案是将 Redis 或 Kafka 作为中心缓冲池。
典型应用场景
因为 自身的灵活性以及网络上丰富的资料， 适用于原型验证阶段使用，或者解析非常的复杂的时候。在不考虑服务器资源的情况下，如果服务器的性能足够好，我们也可以为每台服务器安装 。我们也不需要使用缓冲，因为文件自身就有缓冲的行为，而 也会记住上次处理的位置。
如果服务器性能较差，并不推荐为每个服务器安装 ，这样就需要一个轻量的日志传输工具，将数据从服务器端经由一个或多个 中心服务器传输到 。
随着日志项目的推进，可能会因为性能或代价的问题，需要调整日志传输的方式(log )。当判断 的性能是否足够好时，重要的是对吞吐量的需求有着准确的估计，这也决定了需要为 投入多少硬件资源。
作为 Beats 家族的一员， 是一个轻量级的日志传输工具，它的存在正弥补了 的缺点。 作为一个轻量级的日志传输工具可以将日志推送到中心 。
在版本 5.x 中， 具有解析的能力(像 过滤器)— 。这也就意味着可以将数据直接用 推送到 ，并让 既做解析的事情，又做存储的事情。也不需要使用缓冲，因为 也会和 一样记住上次读取的偏移，如果需要缓冲(例如，不希望将日志服务器的文件系统填满)，可以使用 Redis/Kafka，因为 可以与它们进行通信。
优势
只是一个二进制文件没有任何依赖。它占用资源极少，尽管它还十分年轻，正是因为它简单，所以几乎没有什么可以出错的地方，所以它的可靠性还是很高的。它也为我们提供了很多可以调节的点，例如：它以何种方式搜索新的文件，以及当文件有一段时间没有发生变化时，何时选择关闭文件句柄。
劣势
的应用范围十分有限，所以在某些场景下我们会碰到问题。例如，如果使用 作为下游管道，我们同样会遇到性能问题。正因为如此， 的范围在扩大。开始时，它只能将日志发送到 和 ，而现在它可以将日志发送给 Kafka 和 Redis，在 5.x 版本中，它还具备过滤的能力。
创建的初衷主要是尽可能的使用 JSON 作为日志输出，所以传输工具及其下游的传输线不需要猜测子字符串里面各个字段的类型。这样，它为几乎所有的语言都提供库，这也意味着，我们可以将它插入到我们自定义的程序中。
优势
和多数 插件一样， 插件是用 Ruby 语言开发的非常易于编写维护。所以它数量很多，几乎所有的源和目标存储都有插件(各个插件的成熟度也不太一样)。这也意味这我们可以用 来串联所有的东西。
劣势
因为在多数应用场景下，我们会通过 得到结构化的数据，它的灵活性并不好。但是我们仍然可以通过正则表达式，来解析非结构化的数据。尽管，性能在大多数场景下都很好，但它并不是最好的，和 -ng 一样，它的缓冲只存在与输出端，单线程核心以及 Ruby GIL 实现的插件意味着它大的节点下性能是受限的，不过，它的资源消耗在大多数场景下是可以接受的。对于小的或者嵌入式的设备，可能需要看看 Bit，它和 的关系与 和 之间的关系类似。
典型应用场景
在日志的数据源和目标存储各种各样时非常合适，因为它有很多插件。而且，如果大多数数据源都是自定义的应用，所以可以发现用 的库要比将日志库与其他传输工具结合起来要容易很多。特别是在我们的应用是多种语言编写的时候，即我们使用了多种日志库，日志的行为也不太一样。
是 提供的传输工具，它用来将日志传输到 (一个基于 SaaS 平台的 API)，因为 会暴露 API，所以 可以很容易将数据推送到 。
优势
可以获取 /var/log 下的所有信息，解析各种格式(，Solr，， HTTPD 等等)，它可以掩盖敏感的数据信息，例如，个人验证信息(PII)、出生年月日、信用卡号码等等。它还可以基于 IP 做 GeoIP 丰富地理位置信息(例如 logs)。同样，它轻量又快速，可以将其置入任何日志块中。在新的 2.0 版本中，它以第三方 node.js 模块化方式增加了支持对输入输出的处理插件。重要的是 有本地缓冲，所以不像 ，在数据传输目的地不可用时会丢失日志。
劣势
尽管 有些比较有意思的功能(例如接收 或 日志)，但是它并没有 灵活。
典型应用场景
作为一个可以做所有事情的传输工具是值得选择的(提取、解析、缓冲和传输)。
阿里云日志服务的生产者，目前在阿里集团内部机器上运行，经过 3 年多时间的考验，目前为阿里公有云用户提供日志收集服务。
采用 C++ 语言实现，对稳定性、资源控制、管理等下过很大的功夫，性能良好。相比于、 的社区支持， 功能较为单一，专注日志收集功能。
优势
占用机器cpu、内存资源最少，结合阿里云日志服务的 E2E 体验良好。
劣势
目前对特定日志类型解析的支持较弱，后续需要把这一块补起来。
绝大多数 Linux 发布版本默认的 守护进程， 可以做的不仅仅是将日志从 读取并写入 /var/log/ 。它可以提取文件、解析、缓冲(磁盘和内存)以及将它们传输到多个目的地，包括 。可以从此处找到如何处理 以及系统日志。
优势
是经测试过的最快的传输工具。如果只是将它作为一个简单的 / 使用，几乎所有的机器都会受带宽的限制，但是它非常擅长处理解析多个规则。它基于语法的模块()无论规则数目如何增加，它的处理速度始终是线性增长的。这也就意味着，如果当规则在 20-30 条时，如解析 Cisco 日志时，它的性能可以大大超过基于正则式解析的 grok ，达到 100 倍(当然，这也取决于 grok 的实现以及 的版本)。
它同时也是我们能找到的最轻的解析器，当然这也取决于我们配置的缓冲。
劣势
的配置工作需要更大的代价(这里有一些例子)，这让事情变得非常困难。
文档难以搜索和阅读，特别是那些对术语比较陌生的开发者。
5.x 以上的版本格式不太一样(它扩展了 的配置格式，同时也仍然支持旧的格式)，尽管新的格式可以兼容旧格式，但是新的特性(例如 的输出)只在新的配置下才有效，然后旧的插件(例如 输出)只在旧格式下支持。
尽管在配置稳定的情况下， 是可靠的(它自身也提供多种配置方式，最终都可以获得相同的结果)，它还是存在一些 bug 。
典型应用场景
适合那些非常轻的应用(小 VM、 容器)。如果需要在另一个传输工具(例如，)中进行处理，可以直接通过 TCP 转发 JSON ，或者连接 Kafka/Redis 缓冲。
还适合我们对性能有着非常严格的要求时，特别是在有多个解析规则时。那么这就值得为之投入更多的时间研究它的配置。
上一篇文章： 【 企业项目实战】03、基于 发送报警到多个接收方（下）.Sky的博客-CSDN博客
下一篇文章：【 企业项目实战】04、基于 K8s 构建 EFK++kafka 日志平台（中）.Sky的博客-CSDN博客
