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

优势
占用机器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博客