加入收藏 | 设为首页 | 会员中心 | 我要投稿 云计算网_泰州站长网 (http://www.0523zz.com/)- 视觉智能、AI应用、CDN、行业物联网、智能数字人!
当前位置: 首页 > 综合聚焦 > 移动互联 > 评测 > 正文

前端异常监控解决方案研究

发布时间:2018-09-20 06:03:43 所属栏目:评测 来源:佚名
导读:副标题#e# 9月15日技术沙龙 | 与东华软件、AWS、京东金融、饿了么四位大咖探讨精准运维! 前端监控包括行为监控、异常监控、性能监控等,本文主要讨论异常监控。对于前端而言,和后端处于同一个监控系统中,前端有自己的监控方案,后端也有自己等监控方案,

存储日志是一个脏活累活,但是不得不做。对于小应用,单库单表加优化就可以应付。一个成规模的应用,如果要提供更标准高效的日志监控服务,常常需要在日志存储架构上下一些功夫。目前业界已经有比较完备的日志存储方案,主要有:Hbase系,Dremel系,Lucene系等。总体而言,日志存储系统主要面对的问题是数据量大,数据结构不规律,写入并发高,查询需求大等。一般一套日志存储系统,要解决上面这些问题,就要解决写入的缓冲,存储介质按日志时间选择,为方便快速读取而设计合理的索引系统等等。

由于日志存储系统方案比较成熟,这里就不再做更多讨论。

4.3 搜索

日志的最终目的是要使用,由于一般日志的体量都非常大,因此,要在庞大的数据中找到需要的日志记录,需要依赖比较好的搜索引擎。Splunk是一套成熟的日志存储系统,但它是付费使用的。按照Splunk的框架,Elk是Splunk的开源实现,Elk是ElasticSearch、Logstash、Kibana的结合,ES基于Lucene的存储、索引的搜索引擎;logstash是提供输入输出及转化处理插件的日志标准化管道;Kibana提供可视化和查询统计的用户界面。

5 日志统计与分析

一个完善的日志统计分析工具需要提供各方面方便的面板,以可视化的方式给日志管理员和开发者反馈信息。

5.1 用户纬度

同一个用户的不同请求实际上会形成不同的story线,因此,针对用户的一系列操作设计唯一的request id是有必要的。同一个用户在不同终端进行操作时,也能进行区分。用户在进行某个操作时的状态、权限等信息,也需要在日志系统中予以反应。

5.2 时间维度

一个异常是怎么发生的,需要将异常操作的前后story线串联起来观察。它不单单涉及一个用户的一次操作,甚至不限于某一个页面,而是一连串事件的最终结果。

5.3 性能维度

应用运行过程中的性能情况,例如,界面加载时间,api请求时长统计,单元计算的消耗,用户呆滞时间。

5.4 运行环境维度

应用及服务所运行的环境情况,例如应用所在的网络环境,操作系统,设备硬件信息等,服务器cpu、内存状况,网络、宽带使用情况等。

5.4 细粒度代码追踪

异常的代码stack信息,定位到发生异常的代码位置和异常堆栈。

5.6 场景回溯

通过将异常相关的用户日志连接起来,以动态的效果输出发生异常的过程。

6 监控与通知

对异常进行统计和分析只是基础,而在发现异常时可以推送和告警,甚至做到自动处理,才是一个异常监控系统应该具备的能力。

6.1 自定义触发条件的告警

a. 监控实现

当日志信息进入接入层时,就可以触发监控逻辑。当日志信息中存在较为高级别的异常时,也可以立即出发告警。告警消息队列和日志入库队列可以分开来管理,实现并行。

对入库日志信息进行统计,对异常信息进行告警。对监控异常进行响应。所谓监控异常,是指:有规律的异常一般而言都比较让人放心,比较麻烦的是突然之间的异常。例如在某一时段突然频繁接收到D级异常,虽然D级异常是不紧急一般重要,但是当监控本身发生异常时,就要提高警惕。

b. 自定义触发条件

除了系统开发时配置的默认告警条件,还应该提供给日志管理员可配置的自定义触发条件。

  • 日志内含有什么内容时
  • 日志统计达到什么度、量时
  • 向符合什么条件的用户告警

6.2 推送渠道

可选择的途径有很多,例如邮件、短信、微信、电话。

6.3 推送频率

针对不同级别的告警,推送的频率也可以进行设定。低风险告警可以以报告的形式一天推送一次,高风险告警10分钟循环推送,直到处理人手动关闭告警开关。

6.4 自动报表

对于日志统计信息的推送,可以做到自动生成日报、周报、月报、年报并邮件发送给相关群组。

6.5 自动产生bug工单

当异常发生时,系统可以调用工单系统API实现自动生成bug单,工单关闭后反馈给监控系统,形成对异常处理的追踪信息进行记录,在报告中予以展示。

7 修复异常

7.1 sourcemap

前端代码大部分情况都是经过压缩后发布的,上报的stack信息需要还原为源码信息,才能快速定位源码进行修改。

发布时,只部署js脚本到服务器上,将sourcemap文件上传到监控系统,在监控系统中展示stack信息时,利用sourcemap文件对stack信息进行解码,得到源码中的具体信息。

但是这里有一个问题,就是sourcemap必须和正式环境的版本对应,还必须和git中的某个commit节点对应,这样才能保证在查异常的时候可以正确利用stack信息,找到出问题所在版本的代码。这些可以通过建立CI任务,在集成化部署中增加一个部署流程,以实现这一环节。

7.2 从告警到预警

预警的本质是,预设可能出现异常的条件,当触发该条件时异常并没有真实发生,因此,可以赶在异常发生之前对用户行为进行检查,及时修复,避免异常或异常扩大。

怎么做呢?其实就是一个统计聚类的过程。将历史中发生异常的情况进行统计,从时间、地域、用户等不同维度加以统计,找出规律,并将这些规律通过算法自动加入到预警条件中,当下次触发时,及时预警。

7.3 智能修复

自动修复错误。例如,前端要求接口返回数值,但接口返回了数值型的字符串,那么可以有一种机制,监控系统发送正确数据类型模型给后端,后端在返回数据时,根据该模型控制每个字段的类型。

8 异常测试

8.1 主动异常测试

撰写异常用例,在自动化测试系统中,加入异常测试用户。在测试或运行过程中,每发现一个异常,就将它加入到原有的异常用例列表中。

8.2 随机异常测试

模拟真实环境,在模拟器中模拟真实用户的随机操作,利用自动化脚本产生随机操作动作代码,并执行。

定义异常,例如弹出某个弹出框,包含特定内容时,就是异常。将这些测试结果记录下来,再聚类统计分析,对防御异常也很有帮助。

9 部署

9.1 多客户端

(编辑:云计算网_泰州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读