Ohbug 前端监控系统开源第二弹

这里是 Ohbug 开源计划第二弹。第一弹的 Ohbug SDK 我们已经可以收集到数据，这一弹聊一聊数据的处理。

依据数据的流向，我大概绘制了一个架构图：

Ohbug 前端监控系统开源第二弹

这里解释一下几个核心模块的功能：

SDK：数据采集 SDK
Transfer: 数据接收、预处理
Manager：任务管理，包括 Event 聚合、存取 _Event_、存取 _Issue_、通知任务的生成
Notifier：通知任务的执行，包括 email、webpush、webhook
Dashboard：控制台 API 的实现

可能图片解释的不够清楚，这里还是系统介绍一下：

Transfer

首先看一眼 Event 的数据结构：

interface OhbugEvent<D> {
  apiKey: string
  appVersion?: string
  appType?: string
  releaseStage?: OhbugReleaseStage
  timestamp: string
  category?: OhbugCategory
  type: string
  sdk: OhbugSDK

  detail: D
  device: OhbugDevice
  user?: OhbugUser
  actions?: OhbugAction[]
  metaData?: any
}

Event 通过 SDK 收集上来以后，通过 Nginx 转发给 _Transfer_。

为了方便存储，Transfer 需要对不确定数据类型的字段预处理为字符串，这里转化 detail actions metaData 三个字段。具体转化的细节可见源码 formatter。

之后将预处理后的 Event 给到 _Manager_。

Manager

Manager 收到 Transfer 传来的 Event 后，首先对 Event 进行聚合，聚合的目的是将相同的 Event 合并，毕竟数据展示时不希望看到一堆相同的问题占据视野。

聚合的思路是根据数据结构对 Event 进行解构，例如 Fetch 的异常就取出 url, method, data 这些数据，通过 md5 加密后得到聚合的依据 intro。

case FETCH_ERROR:
  return {
    agg: [detail.req.url, detail.req.method, detail.req.data],
    metadata: {
      type,
      message: detail.req.url,
      others: detail.req.method,
    },
  };

得到了 intro 就可以将相同 intro 的 Event 合并到一个数据集里，我们称每一个数据集为 _Issue_，然后就可以将数据持久化存储了。

Event 的存储通过 kafka 通知到 logstash*，logstash* 存入 _elasticsearch_。

Issue 的存储则直接使用 _postgresql_，另外 Ohbug 使用 typeorm 来操作 _postgresql_，好处是方便做数据库之间的迁移。