loggie在年初已开源:https://github.com/loggie-io/loggie
欢迎大家参与贡献!
2. 架构设计
基于golang,借鉴经典生产者-消费者模式的微内核设计。一个pipeline只有source、queue、sink、interceptor4个组件概念,且interceptor也不是必须的。pipeline支持配置热加载,组件热插拔,pipeline之间强隔离,防止相互影响。
2.1 pipeline设计
pipeline的设计初衷主要是为了隔离性。之前运维遇到的一个严重问题:云内使用filebeat采集多个业务的多个日志文件,但是其中一个日志文件的采集配置的topic被误删,导致发送到kafka失败而阻塞,进而导致整个物理机几点的所有日志都阻塞。因此我们需要一种泳道隔离手段,来隔离不用业务、不同优先级的日志,避免相互影响。
pipeline的简洁设计使得我们的扩展极其便捷。在概念上,一个pipeline只有4种组件:source、queue、sink、interceptor,而且interceptor不是必须的。越少的概念,扩展者者就有越少的学习成本。并且,为了进一步提高扩展性,pipeline中的所有组件都抽象为component,所有的组件拥有一致的生命周期与实现方式。不仅方便了扩展,也方便了loggie对组件的统一管理。
基于pipeline,我们实现了配置热更新,组件热加载。reloader与discovery组件可以基于K8S CRD、http监听等方式(预留接口,可以对接例如zookeeper、consul、apollo等配置中心),以pipeline维度进行reload。因此,在保证了reload能力的同时仍然满足了pipeline隔离的目的。
interceptor在loggie中是一个可选的组件,却在loggie中扮演着非常重要的角色。loggie中绝大多数的增强功能都是基于interceptor实现的,例如限流、背压、日志切分、encode&decode、字符编码、结构化等。用户可以根据实际情况选择对应的interceptor提升loggie的适应能力。
完整内置interceptor:https://loggie-io.github.io/docs/reference/pipelines/interceptor/overview/
对于一个日志采集agent来说,通常需要重点关心以下3点的设计与实现:
高效采集:高效指的是高性能的同时低能耗,即如何采集的快服务器资源占用有小。
公平性:例如写入快的文件不能影响写入慢的文件采集、最近更新的文件不能影响之前更新的文件的采集,删除文件的合理采集与释放。
可靠性:日志不丢失。包括进程崩溃重启、服务发布&迁移&容器漂移、下游阻塞等情况。
日志采集,我们关心的是这么几个问题:
如何及时发现新创建的文件?
如何及时发现最新的写入?
如何快速读取文件?
这其实是两方面的问题:
事件感知:及时发现文件事件。例如文件新建、删除、写入。
文件读取:高效读取文件内容。尽可能快的读取文件内容,减少磁盘io,cpu可控。
当我们无法及时发现文件写事件,会有什么影响呢?有两种情况:
如果这个文件正处于采集中(持有文件句柄),那这个文件的写事件没有影响。因为正在读这个文件,后续的写入理所当然能被读到。
如果这个文件处于不活跃状态(即文件已经读取到了末尾,并且一定时间内没有发现新内容,甚至文件的文件句柄被释放了),这个情况我们希望能及时感知文件的写事件以方便我们及时采集最新的写入内容。
因此,重要的是“不活跃”文件的写事件。
文件新建(滚动)事件?
当我们没有及时发现新建事件,会有什么影响呢?
首条日志写时间到发现时间之间的日志将会延迟采集(对于loggie来说,最大延迟在10s左右,因为默认的轮询时间间隔为10s),但是一旦感知到事件,采集可以很快追上进度。因此新建事件不那么重要。
文件删除事件?
当我们没有及时发现删除事件,会有什么影响呢?有3种场景:
文件被删除后,希望未采集完成的文件继续采集:这种情况,删除事件迟到不总要。因为当文件还未采集完,及时发现的删除事件没有意义;当文件采集完后,未及时发现的删除事件仅影响文件句柄释放延迟。
文件被删除后,希望尽快释放磁盘空间:仅仅导致文件句柄释放延迟,即磁盘空间释放延迟(大概在10s左右)。
文件被删除后,希望未采集完的文件给予一定的容忍时间再释放磁盘空间:这种情况近会导致文件最终释放延迟的时间=容忍时间+事件迟到时间。
因此,删除事件不重要。
文件改名事件?
同上,不重要。但是如何得知文件改名以及改成什么名确实个值得好好思考的问题!(暂不展开)
公平性我们关心的是文件之间的读取平衡,不要造成文件读取饥饿(长时间得不到读取而造成数据延迟)。业界这块的做法有两种:
每个文件对应一个读取线程,有os调度文件读取保证公平性。
优点:能够保证公平性。
缺点:同时采集的文件数量多的时候cpu消耗太大。
匹配到的文件按照更新事件倒序,按照顺序挨个读取文件。
优点:实现简单。
缺点:无法保证公平性,更新时间早的文件必然会饥饿。
因此loggie实现了基于“时间片”的读取方式:
成果:仅仅用一个线程(goroutine)就处理了loggie所有的日志读取任务,且最大可能的保证了公平性。
loggie保证了数据的不丢失,实现了at least once保证。对于文件读取来说,可靠性的实现有一定特殊性:需要保序ack,即我们对于采集点位记录的持久化前提是当前ack之前的ack全部done。因此为了提高保序ack的性能,我们的这块的设计进行了一些优化:
机器ip是确定的,但是如何唯一标识日志文件呢? 文件名可能重复,因此需要文件名+文件inode(文件标识)。但是inode只在磁盘分区中唯一,因此需要修改为文件名+文件inode(文件标识)+dev(磁盘标识)。但是inode存在复用的情况,如果文件被采集完后被删除了,inode被复用给一个同名的文件,这样就变相的造成重复,因此我们需要增加文件内容的前n个字符编码。最终的计算维度为:机器ip+文件名称+inode+dev+{fistNBytes}。
之所以用小计批任务计算,主要有两个原因:
日志的完整性计算不需要太实时,因为采集的日志可能因为种种原因而迟到,实时计算的话很可能会存在太多的数据丢失的情况。而且计算的量级非常大,不适合实时计算。
另一面,不使用更大的时间间隔(例如T+1)计算的原因是,通常日志都会配置轮转和清理。如果间隔过大,计算出有丢失的日志可能因为轮转和清理被删除了,那就失去了补数据的机会。
计算逻辑:日志行首offset+日志size=下一行日志行首offset
计算需要的所有metric都附带在loggie采集的的日志元数据中。
由于日志采集后,可能被后续的业务监控报警以及大数据数仓处理分析计算应用,因此日志的质量变得愈发重要。那如何衡量日志质量呢?本质上,日志从非结构化数据被采集后经过一系列处理计算变成了结构化数据,因此我们在日志结构化的过程中定义了日志质量分的计算:
效果:
日志质量治理的意义:
量化日志质量,持续推动服务进化。
为下游日志的处理极大提高效率。
提高了关键日志的准确数。
基于采集的日志数据我们做2个重量级的应用,使得日志的重要程度上升了一个维度,让日志真正拥有强烈的业务含义。
通常实现这些需求需要不小的开发周期,但是基于业务实时监控,只需要花5-10分钟的时间在平台上配置即可展示与报警:
核心原理:
打印对应的业务日志
在平台配置采集对应的日志
在平台配置对应日志的数据模型以及对应指标的计算逻辑(支持明细、聚合等丰富计算)
配置报警规则
当前微服务盛行,用户的一个操作可能涉及底下多个微服务调用,考虑以下问题:
如何从业务全局视角观察对应服务的运行情况?
如何从业务链路视角发现上下游占用比例和依赖?
业务全链路监控应运而生:
以交易链路为例,从首页->搜索&推荐->商详->加购->下单->支付这个主链路以及辐射出来的几条支链路,整体的流量是怎么样的?调用qps是怎么样的?平均rt是什么样的?错误情况如何?通过业务全链路监控一目了然。
核心实现原理:
严选所有服务默认开启访问日志,默认采集所有服务的访问日志
在平台配置业务链路流程对应的服务以及接口
配置关键链路节点的监控报警规则
平台一键生成全链路实时监控报警
业务全链路实时监控的意义非凡,使得我们能够站在更高的维度,以全局视角审视整个业务流程下的服务调用情况,及时发现链路中的薄弱环节以及异常情况,帮助我们优化服务依赖,提升服务稳定性。
严选基于loggie的日志平台化建设,我们一方面在满足基于日志的问题分析诊断这一基础需求之余,进一步了提升日志质量、问题排查效率、全链路可观测可运维能力。另一方面,我们扩展能力与丰富应用场景,只需要简单配置就使得日志拥有强烈的业务含义与监控语义,使得我们能够站在更高的维度审视&监控业务链路中的异常,提前发现链路服务与资源问题。
本文由作者授权严选技术团队发布