微信监控技术 怎么监控微信


微信监控技术 怎么监控微信

文章插图
微信监控技术(怎么监控微信)本文分享的是微信运维监控系统的具体设计实践 。在分享开始之前先看如下图中微信后台系统的现状,面对庞大的调用量及复杂的调用链路,单靠人力难以维护,只能依赖一个全方位监控、稳定、快速的运维监控系统 。
我们的运维监控系统主要有三个功能:
  • 第一个是故障报警;
  • 第二个是故障分析和定位;
  • 第三个是自动化策略 。
今天我们的分享主题,主要有以下三部分:
第一个就是监控数据收集轻量化;
第二个是微信数据监控的发展过程;
第三个海量监控分析下的数据存储设计思路 。
一、监控数据收集轻量化 先看一下常见数据收集流程,一般常见的采集流程来说从日志里面采集,然后本地汇总打包,再发到全局服务器里面汇总 。
但是对于微信来说,200w/min调用量产生的是2000亿/min的监控数据上报,这个可能还是比较保守的估计 。
早期我们使用过自定义文本类型日志上报,但由于业务及后台服务非常多,日志格式增长非常快,难以持续进行维护,而且不管是CPU、网络、存储、统计都出现非常大的压力,难以保证监控系统本身的稳定 。
为了实现稳定的分钟级、甚至秒级的数据监控,我们进行了一系列改造 。
对于我们内部监控数据处理分为两个步骤:
  • 第一个是数据分类
  • 第二个是定制处理策略
我们对数据进行分类,在我们内部来说有三种数据:
第一是实时故障监控分析;
第二种是非实时数据统计,比如说业务报表等;
第三种是单用户异常分析,比如说用户一个报障过来还要单独对用户故障进行分析 。
下面先简单介绍一下非实时数据统计及单用户异常分析,再重点介绍实时监控数据的处理 。
1.1、非实时数据 对于非实时数据来说,我们有一个配置管理页面 。
用户在上报的时候会先申请 logid + 自定义数据字段,上报并非使用写日志文件的方式,而是采用共享内存队列、批量打包发送的方式减少磁盘IO、日志服务器的调用压力 。统计使用分布式统计,目前已经是常规做法 。
1.2、单用户异常分析 对于单个用户异常分析来说,我们关注的是异常,所以上报路径跟刚才非实时的路径比较相近 。
采用固定的格式: logid + 固定数据字段(服务器IP+返回码等),数据上报量比刚才的非实时日志还要大很多,所以我们是抽样上报的,除了把数据存入到Tdw分布式存储里面,还会把它转发到另外一个缓存里面进行一个查询缓存 。
1.3、实时监控数据 实时监控数据是重点分享的部分,这部分数据也是2000亿/min日志上报中的绝大多数 。
为了实现分方位的监控,我们的实时监控数据也有很多种类型,其格式、来源、统计方式都有差异,为了实现快速稳定的数据监控,我们对数据进行了分类,然后针对性的对各类数据进行简化、统一数据格式,再对简化后的数据采取最优的数据处理策略 。
对我们数据来说,我们觉得有下面几种: