clojure实战——基于logstash搭建日志数据获取与整理平台(1)

clojure实战——基于logstash搭建日志数据获取与整理平台(1)

1. 需求背景介绍

比如：

在一个游戏平台中，所有的游戏都将结果直接写入到一个数据库，但现在我们想根据游戏结果来搞一些活动（活动可能只依赖某一个游戏结果数据，或多个游戏数据结果），此时我们可能想到以下几个方案：

在所有游戏和数据库中间建立一个“游戏结果消息中心”，修改各个游戏代码，将游戏结果通知到“中心”，“中心”可将结果写入数据库，也可传给该活动服务，供活动使用。

该方案需要修改平台上所有的游戏代码，在整个平台系统设计初期这样设计是很好的。但是现在系统已
定形，如此修改工作量大，影响范围太广，不妥。

在数据库层建立一个trigger（触发器），当有游戏结果数据写入数据库时触发，在触发其中写入活动相关的数据处理逻辑，收集活动所需数据，并存入到该数据库新建的表中。

该方案有三个非常不好的地方：一是安全隐患大，数据库是非常核心的东西，在数据库层写一些逻辑是
不安全的。二是触发器只能用于数据库层，不能上层逻辑。三是只能作用于该数据库，不能扩展到其他
数据库，灵活度限制太大。不妥。

考虑到每个游戏都会将游戏结果写入到日志文件中，可以将日志文件作为数据来源。监控日志文件，每次有数据写入时，监控程序将新增加的数据通过网络发送给数据需求服务。比如，可像方案1一样建立一个“结果消息中心”，负责转发结果消息给需求方(需求方可像消息中心注册其想要的数据)。

该方案很好的解决了方案1和方案2的不足。它是完全独立于以前的所有系统的，不会改变以前系统的
结构和数据，因为也不会给以前的系统带来任何安全风险。另外，当数据传到“中心”之后，自由得到
了完全的释放。目前觉得是个很不错的选择。

综上，我们可以选择第三种方案。但这一方案关键点有三：一是如何实现监控日志文件；二是如何将日志数据整理成一定各式（因为很多日志记录的格式比较自由）；三是如何将新增日志信息发送给“中心”。当然，我们可以完全自己实现一个监控器（java和c#等都自带了相应的库），但现在有logstash，就可以节省这一部分成本了，因为logstash能够很好地解决上述三个关键点。

因此我们这一平台可以设计如下：

| ----------|        |--------------|    rpc   |-------------|
|  logstash | http   | 结果消息中心   | <------- | 消息需求者    |
| -获取和整理 |------> |-消息注册接口   | -------> |- 注册所需消息 |
| - 日志数据 |        |-分发消息给注册者|     rpc  |- 接收并使用消息|
|-----------|        |--------------|          |-------------|

下一节将讲解logstash如何获取和整理日志数据，并将其发送给“结果消息中心”的。

2. 碎碎念

对于程序日志，可能很多人只是将它当做一个程序运行日志，即将其当做一个查看程序状态，跟踪运行轨迹，定位故障点的工具；也可能有很多人能够从宏观的角度看待它：日志是进行数据分析的重要数据来源之一，它记录的是一系列“事实”，不管是运行状态还是业务数据。

可能有的人和我一样，忽略了日志作为可靠数据来源这一重要角色，而过总盯着数据库、文件或第三方穿过来的数据。这在某些情况下可能就限制住了我们实现某些需求的可选方案。