通用服务平台之日志子系统

日志系统在服务体系中较为常见,其基本功能就是及时抓取服务最新的运行日志然后进行上报或持久化。通用平台日志子系统功能也是如此的,因为功能较为基础普遍,先给出结构示意图,然后再简介子系统。

通用服务平台之日志子系统
日志子系统架构示意图

 

1. 日志子系统构成

日志子系统构成较为简单,由数据发布服务、捕捉节点、数据写入三部分组成。

(一)数据发布服务。负责将日志系统配置DB中的初始数据和后续的变化数据发布至数据子系统,该部分较为简单不做赘述。

(二)捕捉节点。捕捉节点负责整个服务器上N个运行服务日志的捕捉工作,根据子系统配置数据将有效日志实时捕捉,然后定时打包通过通信子系统发送至数据写入服务。

(三)数据写入。数据写入负责将接收到的日志数据写入日志DB中。

2. 日志子系统特点

(一)非侵入模式。通用平台从便利使用角度出发,采用非侵入模式,既日志捕捉根据配置中的关键字进行捕捉,无固定日志格式减少对使用方约束,该方法随时添加、删除捕捉关键字,可扩展性较好。

(二)配置灵活。日志子系统从实用角度出发,关键字既可以针对整个系统,也可以针对某类服务,还支持某指定单个服务配置灵活机动。

(三)配置生效快。日志子系统设置数据发布服务进行变化数据的发布,捕捉节点会和数据子系统进行变化数据同步,可以在配置变化后,及时更新数据,采用最新关键字进行捕捉日志。

(四)捕捉对象可配置化。考虑到每台服务器情况不同,日志子系统将捕捉对象也设计为可配置化,和关键字配置一致,捕捉文件路径、文件名可以针对整个系统,某类服务和单个服务进行设置,可以在各种情况下正常工作。

3. 日志类型

所谓日志类型是从数据存储角度出发来进行数据区分。我个人理解数据存储分为长效存储和临时存储,考虑单表承载数据量大小,长效存储数据以天为单位进行切割存储,适合存储服务需要长期保持的日志,如服务性能类日志,长效存储后,可以通过类比来找到问题点。临时存储为单表架构,不进行数据切割,可以设置数据量达到上限时自动清理过期部分来达到控制容量问题,该类数据适合无需长期保持数据,如服务临时调试产生的日志,或其他类型数据。

4. 日志DB本地化

考虑到日志数据量可能会较大,可以采用数据本地化措施来降低带宽流量问题,同时也能提高日志系统处理性能。既将日志DB沉降到每个机房,本机房产生的日志直接在本机房日志DB中存储,避免了跨机房传输,提升了日志系统处理性能。

5. 日志子系统的意义

日志子系统除了基础的提供整个系统服务运行日志抓取意义以外,在通用平台中还承担着其他重要意义。

(一)数据的纵向类比。由日志子系统长效数据存储带来一个非常显著的好处,这些长效日志能进行纵向类比。如某服务运行性能日志,可以日、周、月、等时间单位进行类比,可以从该类比数据分析中发现线索。

(二)为应急仲裁提供分析数据。应急仲裁是系统应急预案,实时监测系统是否正常和健康达到预警和处理目的,使得系统向智能化演绎。日志子系统通过采集平台服务运行日志可以为应急仲裁提供分析源数据,使得系统在危险到来之前能捕捉到线索为预警和处理打下基础,赢得先手。

本篇简介通用平台日志子系统,由于其结构较为简单,功能也较为普遍,无需过多介绍,本篇不做赘述,如各位同行有问题欢迎留言发起讨论。

 

通用服务平台之总体架构设计