关于javascript:Ohbug-前端监控系统开源第二弹

35次阅读

共计 1627 个字符，预计需要花费 5 分钟才能阅读完成。

这里是 Ohbug 开源打算第二弹。第一弹的 Ohbug SDK 咱们曾经能够收集到数据，这一弹聊一聊数据的解决。
根据数据的流向，我大略绘制了一个架构图：

这里解释一下几个外围模块的性能：

SDK：数据采集 SDK
Transfer: 数据接管、预处理
Manager：工作治理，包含 Event 聚合、存取 Event、存取 Issue、告诉工作的生成
Notifier：告诉工作的执行，包含 email、webpush、webhook
Dashboard：控制台 API 的实现

可能图片解释的不够分明，这里还是零碎介绍一下：

首先看一眼 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 收到 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，益处是不便做数据库之间的迁徙。

Manager 在实现 Issue 的存储后，会判断以后条件是否合乎告诉规定，再将 Issue 与告诉内容一起传给 Notifier。
Notifier 的工作就是就收到工作后触发指定告诉，包含 email、webpush、webhook 的发送 / 触发。

Dashboard 为控制台整体流程的提供反对。次要工作是为控制台前端提供数据，例如下图

另外 Issue 对应的 Event 数据通过 elasticsearch 获取：

除此之外 Dashboard 还实现了用户零碎、团队、我的项目、告诉、SourceMap 的增删改查。
对于 Dashboard 的实现其实还有很多货色能够聊，当前能够独自拿出一篇单聊。

目前的实现还是属于比拟根底的数据采集剖析产品，当前还有许多可拓展的方向，如果你出于平台数据安全的思考，Ohbug 也反对本地部署。
一个人的力量无限，咱们拥抱开源一方面也是为了集中力量办事，心愿有更多开发者退出进来，欠缺 Ohbug。
上述所提及的内容均以开源 Ohbug Server，如果你想领先体验能够试用 Ohbug 官网服务。
更多内容可见 Ohbug Docs。

正文完