微信监控技术（怎么监控微信）本文分享微信运维监控系统的具体设计实践。分享前请先看看下图微信后台系统的现状面对巨大的通话量和复杂的通话环节，单靠人力很难维持，只能靠一个全方位的监控、稳定、快速的运维监控系统。
我们的运维监控系统主要有三个功能:
第一个是故障报警;
第二个是故障分析和定位;
第三个是自动化策略。
今天的分享主题主要包括以下三个部分：
首先是轻量级监控数据收集;
二是微信数据监测的发展过程;
第三次群体监测分析中数据存储的设计思路。
一、监控数据收集轻量化
让我们看一下常见的数据收集过程一般来说，常用的收集过程是从日志中收集数据，然后在本地收集打包，再发送到全局服务器进行收集。
但是对于微信，200w/产生的min通话量是2000亿/Min监测数据报告，这可能还是一个保守的估计。
早期我们使用的是自定义文本类型的日志报告，但是由于大量的业务和后台服务，日志格式增长非常快，很难持续维护，而且不管是CPU还是CPU、网络、存储、统计压力大，很难保证监测系统本身的稳定性。
为了实现稳定的分钟级、即使是秒级的数据监测，我们也进行了一系列的改造。
我们的内部监测数据处理分为两步：
第一个是数据分类
第二个是定制处理策略
我们对数据进行分类，在内部，有三种数据:
第一是实时故障监控分析；
二是非实时数据统计，比如业务报表；
第三种是单用户异常分析，比如一个用户报告故障，他要单独分析用户故障。
下面简单介绍一下非实时数据统计和单用户异常分析，然后重点介绍实时监控数据的处理。
1.1、非实时数据
对于非实时数据，我们有一个配置管理页面。
申报时，用户会先申请logid自定义数据字段报告将使用共享内存队列，而不是写入日志文件、批量发送减少了磁盘IO、日志服务器的调用压力。使用分布式统计现在是一种常见的做法。
1.2、单用户异常分析
对于单用户异常分析，我们侧重于异常，因此报告路径类似于刚才的非实时路径。
采用固定的格式：固定数据字段（服务器IP+返回码等），数据报表比刚才的非实时日志大很多，所以我们采用抽样的方式进行报表除了将数据存储在Tdw分布式存储中，我们还会将其转发到另一个缓存中作为查询缓存。
1.3、实时监控数据
实时监控数据是共享的关键部分，这部分数据也有2000亿/绝大多数min日志报告。
为了实现方向监测，我们的实时监测数据有很多种类型及其格式、来源、统计方法有差异为了实现快速稳定的数据监控，我们对数据进行分类，然后对各类数据进行简化、统一数据格式，然后对简化后的数据采取最优的数据处理策略。
对于我们的数据，我们认为有以下几种:
后台数据监控用于监控微信后台服务的数据；
终端数据监控，除了后台，还需要关注终端的具体性能、异常监控及网络异常；
外部监控服务，我们现在有商家小程序等外部开发者提供的服务我们和外部服务开发者需要知道这个服务和我们的微信之间存在什么样的异常，所以我们也提供外部监控服务。
1.3.1、后台数据监控
对于我们的后台数据监控，我们认为按照级别可以分为四类，每一类都有不同的格式和上报方式：
1、硬件级监控，如服务器负载、CPU、内存、IO、网络流量等。
2、进程的运行状态，如消耗的内存、CPU、IO等。
3、模块间调用链，各个模块、机器之间的呼叫信息是故障定位的关键数据之一。
4、业务指标，整体业务层面的数据监控。
不同类型的数据被简化为以下格式，以便于数据处理。
下面两层是IP Key的格式，然后容器出现后使用ContainerID、IP、Key的格式。
模块调用信息依次提取要传输的模块的一般信息，并与业务指示符共享ID、Key的数据格式。