Zhaohao Lu
Zhaohao Lu/
🤖
Bot Monitor System Frontend
Bot Monitor System Frontend
🤖

Bot Monitor System Frontend

Created by
ZhaohaoZhaohao
Tags
Frontend
Published
Published 2024-08-01 00:00
Last edited time
Last updated 2024-08-09 08:09

监控告警｜目标

  • 交互层面：Controller 按钮全都正常映射到目标页面的按钮
  • 视觉层面：Hack 过后的网页 UI 和设想一致
「实际上就是监控 DOM。」
 

监控告警｜涉及场景

  • 两个平台：1️⃣ Google Meet｜2️⃣ Teams
  • 三个阶段：1️⃣ Prejoin｜2️⃣ InMeeting｜3️⃣ EndMeeting
Copy javascript
"*://meet.google.com/*-*-*",
"*://meet.google.com/new",
"*://*.teams.live.com/*",
"*://*.teams.microsoft.com/*",
 

监控告警｜SDK

1. Bugsnag SDK

  • 监控｜
  • 告警｜

2. 自定义 SDK

  • 监控｜DOM 元素检测 SDK
    • 目的：专注于检测，不处理错误。用于监控 UI 元素的存在性和可交互性
    • 功能：
      • 使用 querySelectorAll 等方法，检查预定义的元素
      • 验证元素是否存在、能否点击
    • 风险：万一元素都存在，但是他们的映射关系变了，就无法监测到。
    • 期望的使用方式：在 click 的时候，先调用 DOM 元素检测 SDK，如果没问题就放行，有问题就进入错误处理阶段。
  • 监控｜操作验证 SDK
    • 目的：专注于验证每个操作的执行结果
    • 功能：
      • 确认操作后的状态变化（如麦克风开关状态）
      • 记录操作失败情况
  • 错误处理｜Fallback SDK
    • 目的：在核心功能失效时，提供备选方案，为了确保核心功能的可用性。
    • 功能：
      • 提供备选的操作方法（如使用快捷键、OS-level API）
      • 在需要时切换到原始网页视图（对于 Bot Alone 场景）
      • 管理不同功能的 fallback 策略（用 map 对关键操作列表定义备选方案，每个关键操作对应特定的备选方案。例如{ A 操作 : A Fallback, B 操作 : B Fallback} ）
    • 期望的使用方式：监控到一个按钮失效，如果是关键操作，立刻调用 Fallback SDK 的对应 Fallback。
 
这些 SDK 要怎么用比较好？
  1. n：全都分开，用的时候用哪个就调用哪个。（好处是不用改原来的代码结构，坏处是用起来麻烦，要多写几行代码，而且使用者要对这些 SDK 有比较深的理解）
  1. n+1：分散+整合。整合指的是把上面的所有 SDK 都做到一起，形成自动化的工具链 xxx()（例如： 传入要检测的 dom→dom 元素检测→根据情况触发不同fallback→根据情况调用不同的 bugsnag SDK），这样可以在使用时只用调用这一个方法 xxx()。如果调用整合的方法，就不需要在 SafeClick 等相关方法里再做 DOM 元素存在性检测了，因为 SDK 里自带了检测。那么 SafeClick 方法里就应该把相关检测代码直接删掉，然后在方法的第一行直接调用xxx()。
 

监控｜策略

1. 主动监控

  • 关键点：定义一个关键操作列表，在指定时间，根据 Meeting 平台和阶段，自动对所有关键操作进行检测。
  • 技术方案：无头浏览器（主要）+ bugsnag SDK（辅助）。
  • 生命周期：指定的某个时间段（例如每天的00:00-00:30）。
  • TIPS：
    • 这些关键操作列表需要定义在一个地方，方便管理和监控。不要把要监控的内容分散在代码的各个地方。(关键操作 e.g. 加入会议，麦克风控制，摄像头控制，屏幕共享，退出会议)
    • 不是在用户端进行的，而是在我们自己的服务器上进行。

2. 被动监控

  • 关键点：在可能出错的分支，预留错误处理的相关代码。
  • 技术方案：bugsnag SDK（主要）+ 自定义 SDK（辅助）。
  • 生命周期：和 bot-helper 一致。
  • TIPS：
    • 错误处理相关代码是指：错误上报 + Fallback
    • 在用户端进行，由用户触发。
 

告警｜策略

待定
 

开发计划

分为两个阶段，分别开发被动监控和主动监控。
这里最大的工作量可能是重构原始代码，因为要尽量把所有的 query 语句统一，不然监控系统实现不够优雅。

Stage 1 被动监控

  1. Week 1：
    1. 系统地定义操作列表
        2. 🔍
        主要操作列表
    2. 定义关键操作列表
    3. 集成并尝试 bugsnag
    4. 实现基本的 DOM 监控函数
      1. checkElement 函数，用于检查 DOM 元素是否存在
      2. checkElementState 函数，用于检查 DOM 元素的状态
      3. reportError 函数，用于统一的错误报告格式
  1. Week 2：
    1. 实现 content.js 中的监控逻辑
    2. 实现 background.js 中的消息处理 & 错误报告
  1. Week 3：
    1. 正式集成 bugsnag，修改 background.js 中的错误报告逻辑，使用 bugsnag 发送错误
    2. 确定更多需要监控的 UI 元素和用户操作。改造 constant 以适应监控系统

    Stage 2 主动监控

    1. 主动监控
     

    零碎的东西

    1. bot-helper 和 bot-vc-controller 是两个 app，理论上是分开监控的，而分开监控需要用到两个 api-key。考虑到他们俩紧密相连，因此用一个 api-key 同时监控。把初始化代码写到 bot-lib 里，让两个 app 共同使用一个。？是否可行
    1. 我到底要监控什么？
        2. 实际上都是 DOM 元素
    1. 到底应该在哪个地方初始化 bugsnag？
        2. bot-helper。bot-vc-controller 里并没有什么要监控的，要监控的 UI 实际上就是两个 vc 平台 ⇒ 而两个 vc 平台是被 bot-helper 操控的 ⇒ bot-helper 里实际操控的是 background.js 和 content.js
    1. 三种监控逻辑：
      1. 完全被动：用户点击 controller ⇒ 打开一个 meeting ⇒ bot-helper 开始工作 ⇒ 用户点击 toggle camera ⇒ content.js 监控有无这个元素(假设没有) ⇒ 传消息给 background.js ⇒ background.js 调用 bugsnag 发消息
      2. 部分被动+部分主动：用户点击 controller ⇒ 打开一个 meeting ⇒ bot-helper 开始工作，然后对关键操作进行监控(假设有 x 个元素不存在) ⇒ 调用 bugsnag 发消息
      3. 完全主动：用无头浏览器。
    Prev
    SCOPE：

    终极目标

    • 交互层面：1️⃣ Controller 按钮全都正常映射到目标页面的按钮
    • 视觉层面：1️⃣ Hack 过后的网页 UI 和设想一致｜2️⃣ Controller 点击后，目标页面产生的效果和设想一致
    • 其他层面：1️⃣ Bot 的 controller 和 TV 正常加载｜2️⃣ 功能一切正常，例如 LocalRecording（这种可能超出 scope 了，属于 bug？）
     

    监控场景

    • 两个平台：1️⃣ Google Meet｜2️⃣ Teams
    • 三个阶段：1️⃣ Prejoin｜2️⃣ InMeeting｜3️⃣ EndMeeting

    埋点策略

    • 集中式埋点：定义关键操作列表，在某个时刻自动对所有关键操作进行检测
    • 分布式埋点：定义一个方法，在需要的地方调用这个方法。

    监控策略

    • 主动
      • 集中，周期性监控功能的可用性。
      • 和 bot-helper 生命周期一致。根据 Meeting 平台和阶段，监控指定内容。
    • 被动
      • 分布，只有在用户主动点击后，才开始监控。

    监控到错误后怎么办

    • 用户层面：
      • Fallback：1️⃣ 禁用相关按钮｜2️⃣ 使用快捷键替代
    • 开发层面
      • 生成错误信息
          • Copy javascript
          {
  "type": "ERROR",
  "message": "Element Not Found",
  "query": [
    "div[role=\"button\"][aria-label^=\"Turn off camera\"]",
    "div[role=\"button\"][aria-label^=\"Turn on camera\"]",
    "div[role=\"button\"][aria-label^=\"Camera problem.\"]"
  ],
  "details": {
    "key": "pre-camera",
    "platform": "GGMEET_QUERIES_MAP",
    "definedQuery": [
      "div[role=\"button\"][aria-label^=\"Turn off camera\"]",
      "div[role=\"button\"][aria-label^=\"Turn on camera\"]",
      "div[role=\"button\"][aria-label^=\"Camera problem.\"]"
    ],
    "suggestion": "Please check if the selector in constant.ts is correct and ensure the element exists in the DOM."
  }
}
      • 通知开发人员

    监控通知 = 告警

    例如：根据等级，x 分钟内超过 y 次，转发至 Slack
    • P0
    • P1
    • P2
    • P3

    监控告警整体架构

    几个重要模块

    1. DOM 元素检测模块
        • 目的：专注于检测。用于监控关键 UI 元素的存在性和可交互性
        • 功能：
          • 使用 querySelectorAll 等方法，检查预定义的元素
          • 验证元素是否存在、能否点击
    1. 操作验证模块
        • 目的：专注于验证每个操作的执行结果
        • 功能：
          • 确认操作后的状态变化（如麦克风开关状态）
          • 记录操作失败情况
    1. Fallback 模块
        • 目的：在主要功能失效时提供备选方案，确保核心功能的可用性。
        • 功能：
          • 提供备选的操作方法（如使用快捷键、OS-level API）
          • 在需要时切换到原始网页视图（对于 Bot Alone 场景）
          • 管理不同功能的 fallback 策略
    1. Bugsnag 告警模块
        • 目的：为其他模块提供一个统一的告警触发接口，并集中管理所有告警。
        • 功能：
          • 接收来自其他模块的告警触发请求
          • 根据预定义规则评估告警严重性
          • 通过 Bugsnag 记录和管理告警
        • 可能的工作流程：
            1. 其他模块在检测到异常情况时，调用告警模块
            1. 根据预定义规则评估告警的严重性
            1. 将告警信息发送到 Bugsnag
            1. 根据告警严重性，可能触发其他操作（如发送邮件、Slack 通知）

    核心功能监控（具体实现）

    • 目的：检测 Controller UI 上的核心操作是否可用
    • 工作流程：1️⃣ 判断平台 2️⃣ 判断会议阶段 3️⃣ 调用上述的几个模块。
    • 监控项目：
      • 加入会议
      • 麦克风控制
      • 摄像头控制
      • 屏幕共享
      • 退出会议
      • 聊天功能

    非核心功能监控

    • 监控项目：
     
     
     

    Comments