总览

    审计对账以日志上报时间为统一的口径，参与审计的各个服务将按照相同的日志时间进行实时对账。通过审计对账，我们可以清晰的了解InLong 各个模块的传输情况，以及数据流是否有丢失或者重复

    1. 审计SDK嵌套在需要审计的服务，对服务进行审计，将审计结果发送到审计接入层。
    2. 审计接入层将审计数据写到MQ(Pulsar或者TubeMQ)。
    3. 分发服务消费MQ的审计数据，将审计数据写到MySQL、Elasticsearch。
    4. 应用场景主要包括报表展示、审计对账等等。

    审计维度

    审计项ID

    每个模块的接收与发送分别为一个独立的审计项ID

    sdk、接入层、分发层之间的传输协议为Protocol Buffers

    审计SDK实现细节

    1.支持本地容灾
    2.数据唯一性
    3.减少异常重启导致的数据丢失

    主要逻辑图

    总览 - 图2
    1.sdk对外提供add接口，参数为:audit_id, inlong_group_id，inlong_stream_id，条数，大小 2.sdk以日志时间+audit_id+inlong_group_id+inlong_stream_id为key，进行实时统计
    3.满足发送周期或者业务程序主动触发，SDK将统计结果进行PB协议组包，发送审计接入层
    4.如果(4)发送失败，则放入失败队列，下个周期继续发送
    5.当失败队列大于阈值时，通过本地文件进行容灾

    服务发现

    审计sdk与接入层之间的名字发现，支持插件化，包括域名、vip等

    容灾逻辑

    接入层实现细节

    目标

    1.高可靠 2.at least once

    主要逻辑

    1.接入层收到sdk发送的包之后，写消息队列
    2.写消息队列成功之后，则对sdk返回成功
    3.消息队列的数据协议为PB协议
    4.写消息队列的ack设置成-1或者all

    1.高实时性(分钟级)
    2.可运营每天百亿级别的审计数据
    3.可去重

    主要逻辑图

    总览 - 图5 1.分发服务AuditDds实时消费消息
    2.根据审计数据中的审计ID，将数据路由到对应的Elasticsearch集群
    3.每个审计ID对应一个Elasticsearch索引

    索引设计

    索引名

    索引名由日期+审计项ID组成，如20211019_1,20211019_2

    索引字段格式

    索引的存储周期

    按天存储，存储周期动态可配置

    Elasticsearch写入设计

    inlong_group_id、inlong_stream_id、审计ID与Elasticsearch索引的关系

    系统设计与服务实现上inlong_group_id、inlong_stream_id、审计ID与Elasticsearch索引为1:N的关系

    写入路由策略

    可选按doc_id去重

    Elasticsearch实时去重比较耗资源，此功能通过配置可选。

    使用bulk写入，每批5000条，提高Elasticsearch集群的写入性能

    MySQL分发实现

    目标

    1.高实时性(分钟级)
    2.部署简单
    3.可去重

    主要逻辑图

    总览 - 图8 MySQL分发支持根据审计ID分发到不同的MySQL实例，支持水平扩展。

    使用介绍

    1.当业务的审计规模比较小，小于千万级/天时，就可以考虑采用MySQL作为审计的存储。因为MySQL的部署相对Elasticsearch要简单的多， 资源成本也会少很多。
    2.如果审计数据规模很大，MySQL支撑不了时，就可以考虑采用Elasticsearch作为存储，毕竟单个Elasticsearch集群能够支持百亿级别的审计数据，也支持水平扩容。

    主要逻辑图

    审计接口层通过SQL查MySQL或者restful查Elasticsearch。接口具体怎么查哪一种存储，取决使用了哪一种存储

    UI 界面展示

    总览 - 图10 前端页面通过接口层，拉取各个模块的审计数据，进行展示