近期，笔者完成了【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自动拉取
上图是我们配置中心的截图，这部分实现起来不难，后期我们也会考虑将这部分建设向开源的方向推进。
网友评论