Open-Falcon日志采集组件的设计与实践

近期，笔者完成了【Open-Falcon日志采集组件】的开源工作。
原本这是公司内部的一个日志采集的agent，在开源的时候，笔者跟Open-Falcon结合起来了，这样同学们二次开发的成本更少些。
本文我们就来聊一聊监控系统 实时日志采集 的那些事。

前言

稳定性是当今互联网产品整个生命周期里，非常重要的一环。
而监控系统，可以说是稳定性工作里的重中之重；监控系统可以说是运维的眼睛。事前及时预警发现故障，事后提供翔实的数据用于追查定位问题，都是监控系统的使命所在。
而监控系统的强大，对业务适配的程度，强依赖于数据的完整程度及采集方式的多样性。
而我们要聊的日志采集组件，就是采集方式多样性中的一环，解决其他采集方式成本较高时的采集问题。

关于监控系统的采集，我们在【运维监控系统专题（一）：浅谈数据采集】 来进行深入探讨。

产品设计原则

在做一个项目之前，首先要调研清楚业务的需求，确认自己要做的东西是业务所要的。
首先，我们的日志采集，是用做其他采集方式比如埋点成本较高场景的补充的。那我们的首要原则就必须是轻量、易接入。
其次，不同的场景，对于采集数据的计算方式不同，要提供灵活的配置项。
最后，外挂式的采集，虽然对服务进程没有侵入性，但仍然要在服务器上安装agent，因此做好资源隔离也是需求之一。

归纳如下：

• 准确、实时、高效
• 轻量，外挂式，最小的配置成本
• 灵活的计算方式（avg、sum、cnt、min、max等）
• 采集周期支持自定义
• 资源占用可控

进程架构

Falcon-Log-Agent进程架构图

从用户视角来看，Falcon-Log-Agent做的事情是：一行行读取用户的日志，然后对日志进行分析，用正则抓取出需要的信息，统计好之后按周期上报至监控系统。
整个进程大致分为三部分：日志读取、计算、统计&上报。
接下来我们就详细介绍下这个Agent内部的设计和解耦方式。

内部模块间的解耦

内部模块间的解耦，主要是通过分模块的设计和两个队列实现的。
日志的读取与计算之间，有一个队列，用来缓存读取出来的数据，同时由计算模块来消费，填满则丢。意味着此时计算能力跟不上读取能力。在复杂正则的场景，容易出现这种问题。
计算和计数都是单独的模块，计算完成后，去更新计数器。此时计数模块只需要一把互斥锁即可很好的应对。我们只要专心解决计算部分的并发难点即可。
数据的统计与发送之间，有一个队列，是用来批量发送数据的。防止分散发送给系统资源带来较大压力。

日志读取模块

日志的读取，说来简单，只要读就好了。
这里我们支持了一个动态的日志路径，支持日志末尾自带时间格式，例如：/path/access.log.${%Y%m%d%H}。
这样程序会实时生成当前的日志文件名，然后进行读取。

日志计算模块

计算模块，会根据配置，每个文件初始化N个worker。同一组worker同时消费同一队列，并发计算，最终去更新计数模块。
为了应对worker的并发更新，计数模块数据结构初始化的时候，强依赖于设定的采集周期，不同周期使用不同的计数器。
关于worker状态的管理，数据上报时间的判定，大家可以在代码中参详:)。

自监控 & 资源隔离

一个监控系统，如果自监控做不好，是一件很打脸的事情。
Falcon-Log-Agent有详尽的对于自身状态的统计，定时的通过HandleMetrics方法处理。
如果要取这部分数据上报，可以直接push到发送队列。
如果另作他用，修改HandleMetrics方法即可。

Future

笔者公司的日志采集配置中心

这部分叫Future，其实在我司已经建设完成了。

• 配置信息打通服务树
• 中心化的配置模块，由agent自动拉取

上图是我们配置中心的截图，这部分实现起来不难，后期我们也会考虑将这部分建设向开源的方向推进。