【Kubernetes 企业项目实战】04、基于 K8s 构建 EFK+logs( 五 )

在版本 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++ 语言实现，对稳定性、资源控制、管理等下过很大的功夫，性能良好。相比于、的社区支持，功能较为单一，专注日志收集功能。