乐趣区

关于云原生:为什么你应该了解-Loggie

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

不过没关系,本文也不打算介绍 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、可观测性等有较深入研究,具备丰盛的云原生分布式架构设计开发教训与我的项目实际。

退出移动版