干货 | 日均TB级数据，携程支付统一日志框架

作者简介

 

英明，携程数据研发专家，负责支付离线数据仓库建设及BI业务需求，对并行计算、大数据处理及建模等有浓厚兴趣。

一、背景

支付中心作为携程集团公共部门，主要负责的业务包括交易、实名绑卡、账户、收单等，由于涉及到交易相关的资金流转以及用户实名认证，部分用户操作环节的中间数据应内控/审计要求需要长时间保存。当前研发应用多，日志量大、格式各异，对于日志的存储和使用产生较大的挑战，故支付数据与研发团队群策群力，共同开发了一套统一日志框架。

二、总体架构图

核心模块包括：日志生产、日志采集、日志解析，其中调用流程如下：

1）研发应用/服务接入基于log4j2扩展的统一日志组件，将日志抛送至kafka。

2）周期性启动消费kafka topic的camus job将日志写入hdfs。

3）T+1启动MR job读取camus写入的hdfs内容并load到hive表。

三、日志生产-统一日志组件

支付研发基于log4j2自定义了多个Appender，将应用日志以服务调用形式抛送至kafka，并被log_process_service 服务统一处理并提交至携程常用基础日志框架如：CLOG、CAT、ES，各应用无需关心公司日志框架，统一由日志平台处理。

其优点：

• 不同日志框架对应着不同的Appender，方便进行日志框架接入的扩展。

• 采用AOP编程，对于接入的业务侵入性小，接入简单。

• 定义了丰富的java注解，便于日志配置化输出，其中可打印日志包括但不限于：类名、方法名、方法入参、返回值、异常等，支持敏感字段脱敏。

存在的问题：

• 日志格式不规范：研发应用数百个，研发人员较多，日志格式差异大，给数据分析和使用带来巨大挑战。

• 存储时长短：当前公司在线CLOG存储系统只能查询最近几天数据、ES保存稍长一段时间数据且不支持批量查询，基础离线CLOG hive表由于数据量巨大，仅能做到T+2，无法满足T+1的报表需求。

故支付数据团队在研发团队统一日志组件的基础上，结合数据分析和数据存储生命周期开发了统一日志框架。

3.1 统一日志-埋点设计

支付研发团队负责数百个服务或应用，支持的业务包括：路由、鉴权、免密、卡服务、订单、钱包实名、电子支付等，不同的业务又可拆分app、h5、online、offline等项目，整合这些数据是个极大的挑战。如果各系统研发埋点任意指定，会给BI数据分析带来极大的困难，数据分析准确性难以得到保障，故支付数据基于业务特点定义了一套统一日志埋点规范。

字段定义主要是基于日常分析需求，致力于简化数据的使用，故总体原则为json形式，当前原始日志有两部分组成：tag/message，其中tag数据结构为Map，关键数据一般是通过tag内的数据进行检索，明细数据通过message进行检索，tag与message的组成格式为：[[$tag]]$message，目前标准字段包括两类：规范性字段和通用性字段。

3.1.1 规范性字段格式

规范性字段需要应用研发一定程度的参与，提供符合字段命名的类和方法。部分字段名称及定义如下：

<

字段名称	字段类型	描述
serviceName	string	调用服务名称
tag	Map	keyvalue信息
message	string	原始日志
request