异常监控项目架构

目录

内容

1. 简介

前端监控 是一套用于 监测 前端项目运行时情况,及时上报错、统计错误、性能和用户行为的系统。它能我们及时地发现线上客户端产品的错误、了解客户端产品的性能 等;

目前提供了如下功能:

  • 用户行为
    • 用户在线时长
    • 菜单点击量
    • 用户增长
  • 异常监控
    • 页面性能
    • 错误看板
  • 报警
    • 报警配置
    • 报警日志

2. 项目成员

整个前端监控项目由以下几部分组成

  • 上报SDK:负责收集前端异常的 SDK;此 SDK 运行于需要被监测的前端项目中,会在需要时将相关数据上报到 日志任务;
  • 日志任务:日志任务的作用是记录 SDK 上报的数据,并定期处理数据,然后将处理后的数据存入 数据库;
  • 管理系统:用来展示被监控项目的异常情况,是整个组织中的展示层,数据从 Web服务 获取;
  • Web服务:管理系统 的 后端服务,用来给后台管理web项目提供 数据;
项目关系图

此图是由 dot 和 plantUML 语言绘成,如需修改,请看 [项目关系图.dot][]、[项目关系图.puml][]

各部分的仓库地址如下:

  • 监控后台仓库:包含 日志任务Web服务;各服务的代码入口代码文件如下:
    • 日志任务: 源代码入口:src/fee,构建包入口:dist/fee
    • Web服务:源代码入口:src/app,构建包入口:dist/fee
  • 监控前端仓库:包含 管理系统
  • 上报SDK:包含 SDK

3. 整体架构

整个监控项目的整体架构如下:


整体架构

各个模块的详细的介绍如下

3.1. 上报SDK

上报SDK 运行于被监控的前端项目中,用于收集相关数据 并将收集的数据上报给 后端服务。

上报的数据分为两类:

  • 自动上报的数据:
    • 错误类型数据:主要是常见的JavaScript语法错误、运行错误、咨询加载错误;通过监听全局错误事件、全局异常事件来获取。
    • 性能相关数据:如:文档开始获取、开始解析、解析完成 等等;
    • 环境相关数据:主要是获取 userAgent 相关的环境数据
  • 手动上报的数据:
    • 用户行为数据:主要是用户平均在线时长、用户菜单点击量等;
    • 业务错误数据:主要是业务上的逻辑错误,这类错误在 语言层面不算是错误,所以不能自动收集,需要开发人员自定义格式进行手动上报;

3.2. 日志任务

日志任务是用来 消费、清洗 SDK 上报的数据的,这个过程中,每一个环境都有相应的定时任务来处理,所以的定时任务统一由 Task:Manager 命令来统一调度,所以,我们需要通过 Task:Manager 命令来启动日志任务。

3.2.1. 日志任务数据处理流程

从 SDK 上报数据 到 存入数据库,这个数据的处理过程如下:

日志任务数据处理流程
  1. 数据收集:上报SDK 收集数据,然后将数据发送给后端;
  2. 生成日志:Nginx 将上报的数据记录成日志文件;
  3. 结构化数据:通过 SaveLog 命令将上一步生成的日志转成 JSON 格式 并保存成 以分钟为单位分隔的文件;
  4. 解析并存入原始表:通过 Parse 命令解析上一步的 JSON 数据,然后将数据存入到数据库相应的原始数据表中;
  5. 统计:通过 Summary 命令对上一步解析后的数据进行统计,并将统计结果存入 数据库的 结果数据表 和 Redis 中;

3.2.2. 命令的语法及作用

日志任务应用的入口文件是 dist/fee.js,所以,我们需要通过 node dist/fee.js 命令 参数 的方式来执行下面描述的命令,比如:执行 Utils:GenerateSQL命令的的方式为 node dist/fee.js Utils:GenerateSQL '1,2,3' 2020-12 2021-04

由于 package.json 配置了 fee.js 的脚本,所以你也可以用 npm run fee 命令 参数 来执行相应的命令。

结构化

  • SaveLog:Kafka:解析kafka日志, 按日志创建时间将原日志和解析后合法的json日志落在log文件中, 每运行30s自动退出
    • 语法:SaveLog:Kafka
  • SaveLog:Nginx:每一分钟读取Nginx日志文件,并解析
    • 语法:SaveLog:Nginx

监控

  • WatchDog:Alarm:根据报警配置,监测每一条报警配置对应的项目错误
    • 语法:WatchDog:Alarm
  • WatchDog:Saas:[按分钟] 检查最近5分钟内错误数是否超出阈值, 自动报警
    • 语法:WatchDog:Saas
      解析
  • Parse:Monitor:[按分钟] 解析kafka日志, 分析Monitor
    • 语法:Parse:Monitor <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限,格式为 YYYY-MM-DD HH:mm>
  • Parse:UV:[按小时] 解析kafka日志, 分析记录指定时间范围内的uv
    • 语法:Parse:UV <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限 YYYY-MM-DD HH:mm>
  • Parse:TimeOnSiteByHour:[按小时] 解析kafka日志, 分析记录指定时间范围内用户停留时长
    • Parse:TimeOnSiteByHour <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限,格式为YYYY-MM-DD HH:mm>
  • Parse:Device:[按天] 解析kafka日志, 分析指定时间范围Device
    • Parse:Device <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限 YYYY-MM-DD HH:mm>
  • Parse:MenuClick:[按天] 解析kafka日志, 用户点击情况
    • Parse:MenuClick <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限 YYYY-MM-DD HH:mm>
  • Parse:Performance:[按小时] 解析kafka日志, 分析分钟级别的指定时间范围内的性能指标
    • Parse:Performance <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限 YYYY-MM-DD HH:mm>
  • Parse:UserFirstLoginAt:[按天] 解析kafka日志, 记录用户首次登陆时间
    • Parse:UserFirstLoginAt <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm> <日志扫描范围下限 YYYY-MM-DD HH:mm>

统计

  • Summary:Error:[按分钟/按小时/按天] 根据历史数据, 汇总分析错误数

    • 语法:Summary:Error <所统计时间,格式为:分 YYYY-MM-DD HH:mm | 小时 YYYY-MM-DD HH | 天 YYYY-MM-DD> <统计类型: minute | hour | day >
  • Summary:HttpError:[按天/按月] 基于数据表做统计, 统计http error分布情况

    • 语法:Summary:HttpError <按月/按天统计错误情况,格式为 YYYY-MM-DD | YYYY-MM> <日志统计格式:day | month >
  • Summary:NewUser:[按小时/按天/按月] 根据历史数据, 汇总分析记录指定时间范围内的新增用户数

    • 语法:Summary:NewUser <所统计时间,格式为: 小时 YYYY-MM-DD HH | 天 YYYY-MM-DD | 月 YYYY-MM> <统计类型:hour | day | month >
  • Summary:Performance:[按小时/按天/按月] 根据历史数据, 汇总分析记录指定时间范围内的性能指标数据

    • 语法:Summary:Performance <所统计时间,格式为: 小时 YYYY-MM-DD HH | 天 YYYY-MM-DD | 月 YYYY-MM> <统计类型 : hour | day | month >
  • Summary:SystemBrowser:[按月] 基于数据库统计浏览器占比

    • 语法:Summary:SystemBrowser <按月统计浏览器分布情况,格式为 YYYY-MM> <日志统计格式: month>
  • Summary:SystemDevice:[按月] 基于数据库统计设备占比

    • 语法:Summary:SystemDevice <按月统计设备分布情况,格式为 YYYY-MM> <日志统计格式:month>
  • Summary:SystemOS:[按月]基于数据库统计操作系统占比

    • 语法:Summary:SystemOS <按月统计系统分布情况,格式为 YYYY-MM> <日志统计格式:month>
  • Summary:SystemRuntimeVersion:[按月]基于数据库统计版本占比

    • 语法:Summary:SystemRuntimeVersion <按月统计系统版本情况,格式为 YYYY-MM> <日志统计格式:month>
  • Summary:TimeOnSite:[按天/按月] 根据历史数据, 汇总分析记录指定时间范围内用户停留时长

    • 语法:Summary:TimeOnSite <所统计时间,格式为 YYYY-MM-DD | YYYY-MM > <日志统计格式: day | month >
  • Summary:UV:[按小时/按天/按月] 根据历史数据, 汇总分析记录指定时间范围内的uv

    • 语法:Summary:UV <所统计时间,格式为: 小时 YYYY-MM-DD HH | 天 YYYY-MM-DD | 月 YYYY-MM> <统计类型: hour | day | month >

缓存

  • CreateCache:UpdatePerOneMinute:[每10分钟执行一次] 主动调用方法, 更新Redis缓存, 每10分钟更新一次
    • 语法:CreateCache:UpdatePerOneMinute

工具

  • Utils:CleanOldLog:只保留当前月内数据, 每月20号之后自动删除上个月数据

    • 语法:Utils:CleanOldLog
  • Utils:ReProcessLog:只保留当前月内数据, 每月20号之后自动删除上个月数据

    • 语法:Utils:ReProcessLog <日志扫描范围上限,格式为 YYYY-MM-DD HH:mm > <日志扫描范围下限,格式为 YYYY-MM-DD HH:mm>
  • Utils:TestUC:测试UC接口

    • 语法:Utils:TestUC
  • Utils:Test:专业粘贴调试代码

    • 语法:Utils:Test
  • Utils:GenerateSQL:生成项目在指定日期范围内的建表SQL

    • 语法:Utils:GenerateSQL <项目id列表,逗号分割> <建表日期开始时间(包括该时间),格式为 YYYY-MM> <建表日期结束时间(包括该时间), 格式为 YYYY-MM>
  • Utils:TemplateSQL:生成项目在指定日期范围内的建表SQL

    • 语法:Utils:TemplateSQL>

其它

  • Task:Manager:任务调度主进程, 只能启动一次
    • 语法:Task:Manager
  • Command:Demo:任务调度主进程, 只能启动一次
    • 语法:Command:Demo <必传,用户名> [可选,称谓] < --onlyFlag:必传,flag,只有true/false两个值 > < --logName=@value:必传,日志文件名> [--isTest?=@value:可选,是否处于测试环境]

3.2.3. 执行周期

一次性命令: 整个应用生命周期只需要执行一次

  • Task:Manager

每分钟执行一次:

  • SaveLog:Kafka:[按分钟] 每分钟启动一次SaveLog
  • SaveLog:Nginx:[按分钟] 每分钟启动一次SaveLog
  • WatchDog:Alarm:[按分钟] 每分钟启动一次WatchDog:Alarm, 监控平台运行情况
  • Parse:Monitor:[按分钟] 解析kafka日志, 分析错误详情
  • Summary:Error:[按分钟] 每分钟运行Summary:Error, 分别统计前2,3,4,5,10分钟内的数据

每10分钟执行一次的任务:

  • CreateCache:UpdatePerOneMinute: 主动调用方法, 更新Redis缓存,
  • Parse:UVParse:TimeOnSiteByHourParse:PerformanceParse:Monitor:解析最近15分钟内的数据
  • Summary:UVSummary:NewUserSummary:PerformanceSummary:Error:分别解析当前小时 和 一小时前

每1小时执行一次的任务: 每小时15分30秒启动

  • Parse:DeviceParse:MenuClickParse:UserFirstLoginAt:解析昨天到今天的数据
  • Summary:UVSummary:NewUserSummary:PerformanceSummary:ErrorSummary:TimeOnSite:处理当日数据

每6小时执行一次的任务: 每过6小时在35分45秒启动

  • Summary:UVSummary:NewUserSummary:PerformanceSummary:ErrorSummary:TimeOnSite:处理当日数据
  • Summary:UVSummary:NewUserSummary:PerformanceSummary:TimeOnSiteSummary:SystemBrowserSummary:SystemDeviceSummary:SystemOS:分别处理 当月 和 上月 的数据
  • Utils:CleanOldLog:清理历史log

3.3. 管理系统

管理系统 是一个 Web应用,是用来以图形化的方式展示 上报SDK 收集的各种数据,并提供了一些 用户、权限、项目管理的功能,详情请看 监控前端仓库

3.4. Web服务

Web服务 是 管理系统 的后端服务,应用程序的入口文件是 dist/app

3.5. 公司基础设施

监控项目接入了公司的基础服务,如:PMS、MySQL、Redis、Kafka、Zookeeper 等等。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,839评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,543评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,116评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,371评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,384评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,111评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,416评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,053评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,558评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,756评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,324评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2 345

推荐阅读更多精彩内容