共计 3533 个字符，预计需要花费 9 分钟才能阅读完成。
你可能对日志并不感兴趣。
不过没关系，本文也不打算介绍 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、可观测性等有较深入研究，具备丰盛的云原生分布式架构设计开发教训与我的项目实际。
