你可能对日志并不感兴趣。

不过没关系，本文也不打算介绍Loggie如何采集日志。

首先请不要被Loggie的名称限度了思维，我想从新定义一下：

什么是Log？

从实质上，Log即为Data。而Data，在咱们平时的开发中无处不在。

援用出名经典野猪书《Designing Data-Intensive Applications》（还没看过这本书的请不要错过）里的一句话：

现今很多应用程序都是数据密集型（data-intensive） 的，而非计算密集型（compute-intensive） 的。因而CPU很少成为这类利用的瓶颈，更大的问题通常来自数据量、数据复杂性、以及数据的变更速度。

不论咱们是CRUD boy或者YAML工程师，恐怕写代码的时候最常接触和思考的，还是如何设计各种数据模型，如何解决内存、磁盘或网络上的字节，通常这些过程中，会波及到协定编解码(JSON/ProtoBuf)，数据存储(SQL/NoSQL)与通信(HTTP/RPC)，消息传递(MQ)等等。

然而，咱们在工作中，往往会更加关注我的项目的业务逻辑，疏忽背地的技术实质和形象，以及工程化的难题与挑战。长期以来，很容易成为某些第三方库的纯熟封装工，框架API的机械使用者，他人嘴里的「调包侠」。

如何防止陷入这种窘境？一个好的方法是抉择一个适合的开源我的项目，从我的项目里学习总结和提炼，尝试对其中的代码进行批改、补充或者优化。

真正适合的抉择其实并不多，当然你也能猜到，这里我向你举荐Loggie。

因为，Loggie有着直观、通用的数据链路模型：source → interceptor → sink，典型的数据密集型利用，没有太多的业务属性，易于扩大开发，极致简略但却又无所不包。

**Loggie是什么？
**

仅从日志的场景来解释，Loggie（https://github.com/loggie-io/...） 是一个基于Golang的轻量级、高性能、云原生日志采集Agent和直达解决Aggregator，反对多Pipeline和组件热插拔，提供了：

一栈式日志解决方案：同时反对日志直达、过滤、解析、切分、日志报警等

☁ 云原生的日志状态：疾速便捷的容器日志采集形式，原生的Kubernetes动静配置下发

生产级的个性：Loggie排汇了咱们长期的大规模运维教训，造成了全方位的可观测性、疾速排障、异样预警、自动化运维能力

但须要再次强调的是，Loggie里的Log只是Data或者Events在一种具体场景下的名称，采集日志只是其中一个叫file source的组件，Loggie里还有很多其余的source/interceptor/sink：

所以，格局大点，我更违心形容Loggie为：CloudNative Events Connector And Processor。

（云原生的数据连接器，连贯了各种数据源，能够对各种数据流进行解决、转换与路由）

从应用状态上Loggie可划分为：

Sidecar状态：部署在每个业务容器一起，用于采集容器日志在内的数据
Agent状态： 每个节点一个或者每个Pod一个，用于采集日志或者其余数据
Aggregator状态： 用于直达、转发和解决，可独立部署成集群
基于简略间接的Source → Interceptor → Sink 模型，以及多Pipeline设计，Loggie能够用在很多的场景：

数据采集： 采集容器日志、节点日志，采集Prometheus metrics、Kubernetes Events等
数据直达：作为中转折去做数据的聚合、转发、分流
数据处理： 进行流式数据的切分、转换、解决
日志报警： 进行异样日志的检测与报警
......

然而，这些都不重要，重要的是：

为什么你应该理解一下Loggie？
Loggie是一个“麻雀虽小，五脏俱全”的我的项目，特地如果你是一个Gopher，日常写Golang或者正在学习，Loggie几乎就是为你量身打造。

思考到Loggie的应用场景，Loggie须要谋求极致的轻量化、极致的性能、极致的稳定性以及可维护性。Data-intensive的各种case，在Loggie中都可能有集中的体现。

比方：

队列模型的常识：如何保障队列里的事务或者at least once语义？在队列中如何实现重试、限流、去重、背压？如何设计一个长久化队列？
插件化设计模型：各种动静的配置（validate/defaults），各种组件的解偶与可插拔
极致的性能谋求：如何写出高性能的Golang代码，如何做到面向GC编程，这其中有哪些常见的bad taste？
可观测性：Loggie致力于可观测性的对立采集与转发，所以这里有prometheus metrics、openTelemetry等等。同时如何做好我的项目本身的可观测性？这关系到我的项目是否可能真的在线上稳固运行，以及长期运行的易用性与可维护性
Golang Runtime的一些入门，如何成为纯熟应用pprof的一把好手，如何疾速进行排障，以及在我的项目中怎么做继续的profile?
流式解决：Loggie是如何实现一个轻量级的流式解决性能，怎么去实现一个简略的带有逻辑判断的DSL？
Kubernetes Operator：这里有分布式的Controller，可选的集中式Operator，还有主动的sidecar注入，以及基于K8s编程的历史与演进
各类文件系统的常识：通过探索Loggie最罕用的file source设计，以及file sink和长久化队列，你可能理解如何高性能的和文件系统打交道
各种中间件：Loggie的各种source/sink，有对各种中间件SDK的选型，不论是Kafka、Elasticsearch以及后续的Clickhouse, Pulsar等网红中间件，你都能够找到可供参考的code example以及应用的最佳实际
自动化测试： 在Golang我的项目里如何集成动态代码查看，如何做e2e、集成、Fuzz、压测自动化测试？如何解决各种依赖的内部组件？
如果你深刻理解Loggie后，你会发现，平时里遇到的我的项目，或多或少都带有一点Loggie的影子。因为他们都遵循数据密集型利用实质的设计，都能够参考相似的解决思路，像江湖中的某种文治绝学，咱们平时练习了太多花里胡哨的招式，却始终没有领悟到巨匠们秘而不宣的心法，Loggie可能就是那个暗藏在石碑上的口诀。

另外，如果你在某个时刻，须要进行数据的传输和解决，请第一工夫想到Loggie，看看Loggie能不能满足你的需要。如果不能，能够考虑一下疾速开发一个Source、Sink或Interceptor组件，复用Loggie的能力，能够防止大量反复的开发工作，比方：

在Kubernetes集群中可不便、疾速的应用CRD下发配置，并且反对主动reload、反对指定集群，无需思考部署、配置更新等问题
依赖Loggie提供传输过程的稳定性和可靠性，保障at-least-once和重试机制，防止数据失落，以及数据量过多或过大造成的隐患
应用Loggie提供的一系列监控指标，比方队列长度、传输提早、发送QPS等，可疾速接入Prometheus，同时还可应用一些零碎内置的疾速排障的接口与能力
应用可插拔的Interceptor可用于自定义的数据处理、格局转换等，防止过多的定制化代码开发
当然，Loggie还是一个很年老的我的项目，正式开源后的这段时间，每天都有很多人在问各种问题、提各种需要、给各种倡议，Loggie还有太多的性能亟待研发，充斥了各种可能性，如果你感兴趣，欢送来提issues退出探讨，提PR为Loggie添砖加瓦。

接下来将有一系列文章，分享咱们在开发Loggie的一些思考和播种，我挑了几个通用的、有意思的主题组成了这个系列，权且命名为《A byte of Loggie》，本文可为序。

所以，实际上这是一个“挂着羊头卖狗肉”的系列，Loggie只是一个引子，引出的是在Loggie实际中的积淀、引申、形象和总结。

最初，第一篇预报：《A byte of Loggie: 各式各样的队列及其方法论》

请退出你的提早队列。

相干浏览：

云原生日志架构实际：网易数帆开源Loggie的三生三世

网易X工行：云原生日志零碎 Loggie 正式开源！

Loggie我的项目地址：https://github.com/loggie-io/...

作者简介： 傅轶，网易数帆 轻舟日志平台负责人、架构师。目前专一网易数帆轻舟云原生日志平台研发，致力于云原生技术及其生态体系建设和商业化落地，对Kubernetes、Serverless、可观测性等有较深入研究，具备丰盛的云原生分布式架构设计开发教训与我的项目实际。