整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
据分析能够帮助我们更好地进行运营决策，数据分析能够很好的为转化用户提供参考与数据支撑。
商业领域的数据分析，就是为了给商业行为提供良好的数据预测以及效果评估，在互联网界也是如此。我们在目前商业环境所做的每一项活动都直接或者间接与用户有着联系，其目的本质都是一样，为了让用户成为你的消费者，更进一步的持久消费者。因此数据分析，也应该为转化用户提供参考与数据支撑。毕竟没有用户转化为消费者这个过程，所有的分析都是天方夜谭。数据的结论与行为的预测彼此就是一个循环论证的过程。
首先澄清一下数据分析其实并不是什么高深的学问，在现实的职场实战中，涉及涵盖的数据分析的方法以及复杂性是远低于在学校里习得的专业知识。什么卡方检验，方差分析，回归分析显著性检验等等在非用研以及非专业统计分析领域是很少涉及的。（当然那些学过数理统计学的专业人士也不屑于本文提到的内容，如果大家对这些看起来比较高深的分析方法有兴趣可以自行脑补）。本文只给运营以及一些涉及产品方向的岗位提供分析思路并结合实际案例对我所涉及的领域，抽丝剥茧，给大家一个更加直观的用户转化方面涉及数据分析的知识覆盖。
互联网的大用户概念我们可以直接简单粗暴认定为流量，这里的流量并不是指的简单的IP,UV,PV也可以指来电数，访客人数，人流量等概念既然是流量也就有其自身的数量。我们在对流量转化的数据分析时都会基于一种逻辑方案———流量漏斗转化模型进行分析。
原理很简单，我们可以形象的认为自身的互联网产品其本身就是一个虚拟的漏斗，用户在进行浏览到最终完成下单行为（或者其他我们认定的转化行为比如注册，关注，转发等）有多少被直接阻挡在了“滤网”之上，有多少顺利的达到了我们预设的“转化行为区域”。当然，我们所有的活动都并不是一锤子买卖，因此也要从横向（时间）维度来分析问题。持续的转化用户，保持老用户的消费活力也是分析工作的重中之重。当然，我们在转化流量不仅仅是指的转化的数量而且还指转化的质量，说的比较简单点，就是要提高单个用户的消费价值。在横纵两个维度方面，在这些层层“滤网”中，我们是如何透过这些数据分析问题的呢。
以大型电商网站下单流程为例，我将从流量来源-中间页面访问-详情页-加入购物车-提交订单-复购这几个阶段展开说明。
流量进入主站的第一道障碍通过不同渠道进入的主站（或者该渠道引入流量的承接页），主站页面即是第一层“滤网”我们用穿过第一层滤网进入二级页面的通过率来衡量渠道的流量的质量。通常我们用来衡量页面的流量质量的指标包含如下：页面UV点击率，页面停留时间，跳失率。
想要通过第一层“滤网”，需要必要的动作就是产生点击行为，而点击行为会产生两个数据：页面UV点击率=页面点击总次数/页面UV数；跳失率=通过一个入口进入就离开的次数/通过该入口访问的总次数。点击率越高，说明页面呈现的内容有吸引力能够有效的吸引用户的关注；跳失率越高，说明页面呈现内容具备欺骗性，所呈现的链接内容和文案不具备吸引力。因此在进行第一层滤网的优化方面尽量提高页面的点击率，降低页面的跳失率。尽量让用户下沉到二级页面（或者目标页面）。同时通过这个数据也可以判断流量来源的质量是否过关。
一般而言，页面低质量的流量判断往往符合以下几个特点：在排除页面问题的情况下产生的：1，低点击率；2，高跳失率；3低页面停留时间。
这些低质量流量产生的原因主要有几个方面：1，渠道引流上呈现的文案内容与承接落地页面不符。2，投放渠道上，与目标用户活跃范围不符的渠道，也就是说投放的渠道不精准。3，承接页出错等以及其他原因（包含但不限于404错误网页过期，跳转出错等）。
既然说到这，顺便也给大家看看外部渠道的各种引流的优劣：
以上表格内容，并不一定十分准确，大家可以抱着批判的态度研究论证一下。
在页面访问阶段，流量成功通过第一道“滤网”进入到中间页阶段，中间页包含：搜索列表页，专题活动页面，频道页面等。不同的中间页也有不同的数据指标反映着页面内容的好坏以及流量的走向。中间页的好坏考量最终是有多少访客进入到了商品详情页，因此有一个指标非常重要：UV到达详情页转化率=详情页UV/中间页UV
搜索列表页在大型电商网站中有着不可代替的重要作用，也是站内流量的主要来源，承接着站内商品检索，品类布局的重任，区分搜索页面与列表页面主要是看链接字符，搜索页面的链接往往包含search字符，列表页（或者可以叫类目页）链接包含list字符。搜索页为依据用户输入的关键词来进行整体检索后呈现给用户商品陈列页面。而列表页则是与网站商品类目后台直接关联，呈现品类最全的页面。两者的功能都是为了给予用户更好和更快的定位到想要查看的商品（或者内容）。以下为分别为几个B2C电商的的搜索和类目页链接的开头：
其他就不一一列举了，搜索列表页的数据指标的考核目的就是为了能让用户更加精确快速的找到自己的想要的产品，因此在这一级的页面中数据指标包含如下：
搜索点击率=点击次数/搜索次数；这个指标衡量搜索页面的呈现质量，理论上而言搜索点击率要在200%及以上才是比较健康。（不绝对）
UV到详情页转化率=详情页UV/搜索或者列表页UV；该指标在搜索和列表中同样适用，用来平衡点击率的作弊可能，也是反映三级页面呈现质量的指标之一。
搜索无结果次数：用以反映关键词涉及的品牌品类缺失或者未关联指标。当然搜索无结果词的次数是越低越好。对于搜索词呈现结果为空的品类，需要综合评估后决定是否对相关类目开启招商，引进产品线；对于未关联的品类需要着重优化页面重新关联。
搜索结果页首屏点击率=搜索首屏点击次数/搜索次数；该指标用以衡量搜索结果首屏的商品排序质量与呈现质量。该数据指标的好坏可以间接的反映出搜索词呈现的页面排序是否合理，是否符合用户的需求。同理列表页的首屏指标也与此一样只是名称不同而已即列表页首屏点击率=列表页首屏点击次数/列表页PV.
搜索次数：搜索词产生的搜索次数。（可以理解为搜索PV）一个搜索词的搜索次数高表示该词所涉及的类目需求量高，反之亦然；如果是在列表页则为访问PV
搜索人数：搜索词被多少人搜索的数量（可以理解为搜索UV）；一个搜索词的搜索人数高表示该词所涉及的类目需求量高-主要是为了防止出现搜索次数作弊的情况，反之亦然如果是在列表页则为访问UV
高级筛选项点击次数：在搜索列表页中，页面顶部的高级筛选项是为提供快速定位而设立的，高级筛选项的点击次数和使用率也可以为运营人员提供商品热度参考。举个例子：在客人搜索“单肩包”或者访问单肩包的列表页，在这些页面中都会出现比如材质，价格款式等参数项来给用户选择筛选，通过监控页面的筛选参数的点击次数，可以得到相关“单肩包”哪些款式哪些材质多少价位是消费者主要关注的，并以此来进行主推产品的规划。
在理出了这些指标之后，如何分析这些指标数据呢？
总结归纳：针对搜索列表页的数据分析归为3点：高搜索词重点优化提高点击转化；无结果词分析反馈；页面点击注重高筛适用率方便用户快速定位。
分析逻辑：以让用户下沉到详情页为目的逐一分析，各个击破。
频道页和活动页是常规三级页面，在B2C电商中起着常规类目集合体和活动流量承接页的作用，在频道页和活动专题页上也有着数据的计算和分析逻辑，其主要的数据指标也是让用户下沉至详情页。（基于这样一种假设，用户只有在详情页才有可能产生转化，这种假设已经被证明-至少绝大部分情况是这样。）频道页和活动页虽然具体的数据指标与搜素列表页有所不同，但是他们的最终目的都是相同的。频道页活动页的数据指标包含：
低点击率的区域可能存在以下几种原因，一，是图片以及图片里的文案不能吸引消费者点击，需要调整。二，产品头图展示样式不合理需要调整图片内容或者调换商品。三，展示区域位于首屏以下，关注度不高-需要调整展示位置。
分析逻辑：还是以用户下沉为目的，分析涉及的元素逐个排查。
详情页作为流量转化的关键页面，是前台承载商品信息的最基本单位。也是用户是否决定下单购买的最最重要的一环。因此在分析详情页的时候，数据指标更多的是详情页的质量和它的转化率。当然这两者是相互联系的，从现有的数据来看，详情页的质量高低与其转化率确实是存在正相关的关系。而详情页质量的高低从数据的量化反映来看有两个数据指标：一，平均页面停留时间；二，加入购物车数。
平均页面停留时间=页面停留总时间/访问UV数该指标与页面的呈现布局有着明显关联，包含商品参数介绍，详情图片描述，客服在线情况，好评率等。
加入购物车数：用以反映该商品有多少有意向购买者，为即将转化的关键步骤。加入购物车的数量多少由基本以下几个因素决定：
从数据的角度讲，详情页反映出的问题仅仅通过一个平均访问时长是很难概括的，没办法分解到具体某一个细节来层层分解问题。不过这个时候“经验”的加入就能很好的平衡这一点。这里的经验表示已经经过了长期的实践且数据论证的结论。（这里给大家安利一下数据观点：数据不是万能的，有时主观的判断更具代表性，这也是为什么这个世界上有着那么多的出人意料产品和逆风而上的创意）
购物车是一个特别有趣的设置，对于快消品标准品的电商网站来说，设置购物车一方面是为了节省用户挑选多个商品的付款时间，更出现了一个更加意想不到的好处，就是提高了客单价。在配合满减用券等促销手段的帮助下购物车必然能够起到事半功倍的作用。
在购物车中如果大量积压了客户选购的商品，如果用户始终没有进行下单支付，即加入购物车数较大，这个时候则需要采用短信催付，邮件催付，以及apppush等手段来促进用户转化。
订单页面是纵向转化的最后一环，在这个界面最主要的目的就是尽量让用户尽快付款，达到最后的转化。考核的数据为：有效订单转化率=成交订单数/有效订单数，在这个阶段促成转化是较为简单的如果有效订单转化率较低就要分析是否支付页面存在问题，系统提交流程是否出错等。在排除系统问题后同样可以使用短信apppush邮件等手段进行催付。
最后作为总览全局的用户转化指标：UV成交转化率=成交订单数/页面UV数
作为考核整体用户转化的指标；平均UV价值=成交金额/页面UV数作为考核整体用户质量的指标，值越高，表示质量越高。
总结：层层下探，逐个击破直到完成付款
有句老话说的好，叫不做一锤子买卖，因此这里就涉及到一个新的指标：
复够率=一段时间内重复购买的客户数/一段时间内产生购买的客户数，该指标则要求我们从横向时间维度来分析数据，也很容易理解。有据可查，一个成熟期的购物网站其老用户贡献的销售额占据总数的60%-70%之多。因此我们在看到流量漏斗的转化模型的同时，更加要加深对会员的分层管理，用良好的服务于产品以及具有创意和力度的活动维系你的老用户。
复够率过低：1，表示没有对老会员进行足够的唤醒，可通过短信push线下广告等等活动进行推广激活；2，也有可能近期投入的拉新的资源较多，导致新客增多降低了复够率，需要核实拉新活动的数据；3，超低价或者超优惠活动引流也会导致大量新用户引入，也会对复够率产生影响。上面的两点并不是对复够率有坏的影响，针对的客群不同，数据也应有所取舍。
以上就是针对电商下单流程的整个过程，当然有很多模块并没有提及，比如智能交叉推荐等。大家只需要理解其中的数据分析的逻辑即可。不同的页面，不同的时间，转化用户的目的不同，根据各个阶段的目的，分析不同事件节点的数据，层层推理即用户数据的分析之道。有关会员管理的相关数据（唤醒激活留存）大家可以自行度娘脑补，不再赘述。
安利几个针对数据分析中的几点小tips：
以上观点，均属于个人见解，不代表权威性不代表绝对准确，谨慎采纳。
作者：王小命儿，微信号：wanghuan314400
本文由@王小命儿原创发布于人人都是产品经理。未经许可，禁止转载。
者 | 李刚
本文经授权转载自阿里巴巴中间件（ID:ilieyun）
饿了么监控系统 EMonitor ：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近 PB ，每日写入指标数据量百T，每日指标查询量几千万，配置图表个数上万，看板个数上千。
CAT：是基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。
本文通过对比分析下两者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段。
首先要强调的是这里我们只能拿到 GitHub 上开源版 CAT 的最新版 3.0.0 ，所以是基于此进行对比。接下来说说 CAT 做了哪些事情？
抽象出 Transaction、Event、Heartbeat、Metric 4 种监控模型。
Transaction：用来记录一段代码的执行时间和次数。
Event：用来记录一件事发生的次数。
Heartbeat：表示程序内定期产生的统计信息, 如CPU利用率。
Metric：用于记录业务指标，可以记录次数和总和。
针对 Transaction 和 Event 都固定了两个维度， type 和 name ，并且针对 type 和 name 进行分钟级聚合成报表并展示曲线。
针对上述 Transaction、Event 的 type 和 name 分别有对应的分钟级的采样链路。
目前支持 Counter 和 Timer 类型的打点，支持 tag ，单机内单个 Metric 的 tag 组合数限制 1000 。并且有简单的监控看板，如下图所示：
与其他组件集成
比如和 Mybatis 集成，在客户端开启相关的 sql 执行统计，并将该统计划分到 Transaction 统计看板中的 type=SQL 的一栏下。
可以针对上述的 Transaction、Event 等做一些简单的阈值告警。
饿了么 EMonitor 借鉴了 CAT 的相关思想，同时又进行了改进。
针对 Transaction 和 Event 都固定了两个维度， type 和 name ，不同地方在于聚合用户发过来的数据。
CAT 的架构图如下所示：
CAT 的消费机需要做如下两件事情：
对 Transaction、Event 等消息模型按照 type 和 name 进行当前小时的聚合，历史小时的聚合数据写入到 mysql 中；
将链路数据写入到本地文件或者远程 HDFS 上。
EMonitor 的架构图如下所示：
EMonitor 分两路对数据进行隔离处理：
Real-Time Streaming Compute：对用户发过来的链路中的 Transaction 、Event 等监控模型转变成指标数据并进行 10s 的预聚合，同时也对用户发过来的 Metric 数据进行 10s 预聚合。最后将 10s 预聚合的数据写入到 LinDB 时序数据库（已开源，有兴趣的可以关注 star 下）中，以及 kafka 中，让告警模块 watchdog 去消费 kafka 做实时告警；
Real-Time Data Writer：对用户发过来的链路数据构建链路索引、向 HDFS 和 HBase 写入索引和链路数据，同时会构建应用之间的依赖关系，将依赖关系写入到 Neo4j 中。
所以 EMonitor 和 CAT 的一个很大不同点就在于对指标的处理上， EMonitor 交给专业的时序数据库来做，而 CAT 自己做聚合就显得功能非常受限，如下所示：
CAT 只能整小时的查看 type 和 name 数据，不能跨小时，即不能查看任意两个时间之间的报表数据， EMonitor 没有此限制；
CAT 没法查看所有 type 汇总后的响应时间和 QPS ， EMonitor 可以灵活的自由组合 type 和 name 进行聚合；
CAT 的 type 和 name 报表是分钟级的， EMonitor 是 10s 级别的；
CAT 的 type 和 name 没能和历史报表曲线直接对比， EMonitor 可以对比历史报表曲线，更容易发现问题；
CAT 的 type 和 name 列表首页展示了一堆数字，无法立即获取一些直观信息，比如给出了响应时间 TP99 100ms 这个到底是好还是坏， EMonitor 有当前曲线和历史曲线，相对来说可以直接判断到底 ok 不 ok ；
CAT的TP99、TP999基于单机内某个小时内的报表是准确的，除此之外多机或者多个小时的聚合TP99、TP999是用加权平均来计算的，准确性有待提高。
但是CAT也有自己的优势：
CAT 含有 TP999、TP9999 线(但是准确性还有些问题)， EMonitor 只能细到 TP99 ；
CAT 的 type 和 name 可以按照机器维度进行过滤， EMonitor 没有做到这么细粒度。
目前 CAT 和 EMonitor 都可以通过 type 和 name 来过滤采样链路，不同点在于：
CAT 的采样链路是分钟级别的， EMonitor 是 10s 级别的；
针对某一个 type 和 name ，CAT 目前无法轻松找想要的链路， EMonitor 可以轻松的找到某个时刻或者说某段时间内响应时间想要的链路（目前已经申请专利）。
EMonitor 的链路如下所示：
这张图是某个10s 时刻、某个 type 和 name 过滤条件下的采样链路；
第一行是这 10s 内的采样链路，按照响应时间进行了排序；
可以随意点击某个响应时间来查看对应的链路详情。
EMonitor 支持 Counter、Timer、Histogram、Payload、Gauge 等等多种形式的打点方式，并且支持 tag ：
Counter：计数累加类型；
Timer：可以记录一段代码的耗时，包含执行次数、耗时最大值、最小值、平均值；
Histogram：包含 Timer 的所有东西，同时支持计算 TP99 线，以及其他任意 TP 线(从 0 到 100 )；
Payload：可以记录一个数据包的大小，包含数据包个数、包的最大值、最小值、平均值；
Gauge：测量值，一般用于衡量队列大小、连接数、CPU、内存等等。
也就是任意 Metric 打点都可以流经 EMonitor 进行处理了并输送到LinDB时序数据库中。至此， EMonitor 就可以将任何监控指标统一在一起了，比如机器监控都可以通过 EMonitor 来保存了，这为一站式监控系统奠定了基础。
自定义 Metric 看板
CAT只有一个简易的 Metric 看板 EMonitor 针对 Metric 开发了一套可以媲美Grafana 的指标看板，相比 Grafana 的优势：
有一套类似 SQL 的非常简单的配置指标的方式；
跟公司人员组织架构集成，更加优雅的权限控制，不同的部门可以建属于自己的看板；
指标和看板的收藏，当源指标或看板改动后，无需收藏人员再改动；
alpha、beta、prod 不同环境之间的一键同步指标和看板，无需配置多次；
PC端和移动端的同步查看指标和看板。
类 SQL 的配置查询指标方式如下所示：
可以配置图表的展现形式；
可以配置要查询的字段以及字段之间的加减乘除等丰富的表达式；
可以配置多个任意 tag 的过滤条件；
可以配置 group by 以及 order by。
看板整体如下所示：
移动端显示如下：
目前 EMonitor 已经打通了 IaaS 层、 PaaS 层、应用层的所有链路和指标的监控，再也不用在多个监控系统中切换来切换去了，如下所示：
IaaS层物理机、机房网络交换机等的监控指标；
PaaS 层中间件服务端的监控指标；
应用层 SOA、Exception、JVM、MQ 等客户端的相关指标；
应用层自定义的监控指标。
以打通饿了么分库分表中间件 DAL 为例：
可以根据机房、执行状态、表、操作类型（比如 Insert、Update、Select 等）进行过滤查看：
左边列表给出每条 SQL 的执行的平均耗时；
右边2个图表给出该条 SQL 在 DAL 中间件层面、 DB 层面的耗时以及调用 QPS；
可以给出该 SQL 打在后端 DAL 中间、 DB 上的分布情况，可以用于排查是否存在一些热点的情况；
还有一些 SQL 查询结果的数据包大小的曲线、 SQL 被 DAL 限流的情况等等；
可以查看任何时间点上该 SQL 的调用链路信息。
再以打通饿了么 SOA 服务为例：
可以根据机房和状态信息进行过滤；
左边一栏列出该应用提供的 SOA 服务接口，同时给出平均响应时间以及和昨天的对比情况；
右边的两个图表分别给出了对应服务接口的服务响应时间和 QPS 以及和昨天的对比情况，同时可以切换平均响应时间到 TP99 或者其他 TP 值，同时配有可以快速对相关曲线添加告警的跳转链接；
可以切换到单机维度来查看每台机器该 SOA 接口的响应时间和 QPS ，用来定位某台机器的问题；
可以给出该 SOA 接口调用在不同集群的分布占比；
可以给出该 SOA 接口的所有调用方以及他们的 QPS；
可以查看任何时间点上该 SOA 接口的调用链路信息。
可以针对所有的监控指标配置如下告警方式：
阈值：简单的阈值告警，适用于 CPU 、内存等；
同环比：与过去同期比较的告警；
趋势：适合于相对平滑连续的无需阈值的智能告警；
其他告警形式。
本阶段实现方式：程序打日志，使用ELK来存储和查询程序的运行日志， ELK 也能简单显示指标曲线。
排障过程：一旦有问题，则去 ELK 中搜索可能的异常日志来进行分析排障。
上一个阶段存在的问题：ELK 只是基于一行一行日志进行聚合或者搜索分析，日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段。
本阶段实现方式：CAT 横空出世，通过建模抽象出 Transaction、Metric 等监控模型，将链路分析和简单的报表带入了大家的视野。
告警方式：针对报表可以进行阈值监控排障过程：一旦有告警，可以通过点击报表来详细定位到是哪个 type 或 name 有一定问题，顺便找到对应的链路，查看详细的信息。
上一阶段存在的问题：CAT 对自定义指标支持的比较弱，也无法实现或者展现更加多样的查询聚合需求。
本阶段的实现方式：支持丰富的 Metric 指标，将链路上的一些报表数据也可以划分到指标中，交给专业的时序数据库来做指标的存储和查询，对接或者自研丰富的指标看板如 Grafana 。
告警方式：针对指标进行更加丰富的告警策略排障过程：一旦有告警，可能需要到各个系统上查看指标看板，粗略定位根因，再结合链路总和分析。
上一阶段存在的问题：系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程，各个系统处理数据格式、使用方式不统一。
本阶段的实现方式：打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控，统一数据的处理流程，同时整合发布、变更、告警与监控曲线结合，成为一站式监控平台。
告警方式：可以统一的针对各个层面的监控数据做统一化的告警排障过程：只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息。
目前我们 EMonitor 已完成这个阶段，将公司之前存在已久的 3 套独立的监控系统统一整合成现如今的一套监控系统。
上一阶段存在的问题：
用户虽然可以在一个系统中看到所有各个层面的监控数据了，但是每次排障时仍然要花很多的时间去查看各个层面是否有问题，一旦漏看一项可能就错过了问题所在的根因；
没有整个业务的全局监控视角，都停留在各自应用的角度。
总之：之前的阶段都是去做一个监控平台，用户查询什么指标就展示相应的数据，监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路，监控平台需要主动去帮用户分析里面所存储的数据内容。
本阶段的实现方式：所要做的就是把帮用户分析的过程抽象出来，为用户构建应用大盘和业务大盘，以及为大盘做相关的根因分析。
应用大盘：就是为当前应用构建上下游应用依赖的监控、当前应用所关联的机器监控、redis、MQ、database 等等监控，可以时刻为应用做体检，来主动暴露出问题，而不是等用户去一个个查指标而后发现问题；
业务大盘：就是根据业务来梳理或者利用链路来自动生产大盘，该大盘可以快速告诉用户是哪些业务环节出的问题。
根因分析：一个大盘有很多的环节，每个环节绑定有很多的指标，每次某个告警出来有可能需要详细的分析下每个环节的指标，比如消费 kafka 的延迟上升，有各种各样的原因都可能导致，每次告警排查都需要将分析流程再全部人为分析排查下，非常累，所以需要将定位根因的过程通过建模抽象下，来进行统一解决。
趋势报表分析：主动帮用户发现一些逐渐恶化的问题点，比如用户发布之后，接口耗时增加，很可能用户没有发现，虽然当前没有问题，但是很有可能在明天的高峰期就会暴露问题，这些都是已经实实在在发生的事故。
要想做主动分析，还深度依赖指标下钻分析，即某个指标调用量下降了，能主动分析出是哪些 tag 维度组合导致的下降，这是上述很多智能分析的基础，这一块也不简单。
告警方式：可以统一的针对各个层面的监控数据做统一化的告警排障过程：NOC 根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题，应用的 owner 通过应用大盘的体检得知相关的变动信息，比如是 redis 波动、database 波动、上下游应用的某个方法波动等等，来达到快速定位问题目的，或者通过对大盘执行根因分析来定位到根因。
三者关系如下图所示：
三者的确都不可或缺，相辅相成，但是我想说以下几点：
三者在监控排障中的所占比例却大不一样：Metrics 占据大头， Tracing 次之， Logging 最后；
Tracing 含有重要的应用之间的依赖信息， Metrics 有更多的可深度分析和挖掘的空间，所以未来必然是在 Metrics 上大做文章，再结合 Tracing 中的应用依赖来做更深度全局分析，即 Metrics 和 Tracing 两者结合发挥出更多的可能性。
参考链接：
CAT：https://github.com/dianping/cat
深度剖析开源分布式监控CAT：
https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html
作者简介：李刚，网名乒乓狂魔，饿了么监控组研发专家，饿了么内部时序数据库LinDB项目负责人，目前致力于监控的智能分析领域。
本文缩略图：icon by dmbcjl
【END】
说，到2020年，有500亿设备要连接网络，这是未来物联网的广阔前景。好消息，以后运营商也不用跪着发展客户了，坐等设备连接就好了！
不过，没那么乐观！支持物联网的无线技术太多，蜂窝网络也只是其中一小部分而已。
做个计算题，假设500亿连接设备中，减去100亿连接手机和PC，剩下400亿去连接物联网，按照目前的蜂窝网技术，估计只有2%（约8亿）的物联网设备可接入蜂窝网络。
才8亿？我泱泱中华的手机用户数都超过啦，何况物联网那点流量，呵呵！
为了解决这些问题，Cat.0就来了！
什么是Cat.0？
Cat.即UE-Category，根据3GPP的定义，UE-Category分为1~10共10个等级，其中Cat.1-5为R8定义，Cat.6-8为R10定义，Cat.9-10为R11定义。
如上图，UE-Category主要定义了UE终端能支持的上下行速率。
Cat.0是被写入3GPP Rel.12标准，支持更低速率、更低功耗版本的LTE终端等级。Cat.0和Cat.1都是指向广阔的物联网市场，实现更低功耗、更低成本物联网设备连接到LTE网络。支持更低Category，对可穿戴设备、智慧家庭和智慧电表等物联网应用非常关键。
不过，一直以来，无论是网络还是终端芯片，LTE与物联网之间总是存在一条难以跨越的鸿沟，不过，随着这些年一些通信设备公司和芯片公司的积极投入，可望改变市场局势，为LTE网络连接物联网提供更广阔的前景。比如，前不久，Sequans与Altair相继宣布近期将推出Cat.0和Cat.1芯片组。
为什么要定义Cat.0呢？
为了应对物联网，LTE-M（M2M）必须对LTE网络进行几个方面的优化：
1）设备成本
尽管大量设备接入带来巨大价值，但是，连接设备的成本却是一个大问题。连接蜂窝网络的设备需要芯片支持，为了支持高清视频、在线游戏，目前LTE芯片主要支持几十到几百Mpbs的高速高性能LTE网络。芯片支持的速率越高，硬件就越复杂，成本也就越高。物联网M2M应用并不需要这么高的速率，甚至有些设备间连接只需要几百bps就够了。因此，为了减小设备成本，就得简化芯片来满足物联网M2M应用需求。
2）电池寿命
我们可以每天给手机或平板充电，物联网设备不可能每天甚至每个月为其充电，不仅不方便，而且维护成本上升。一些设备需要长期保持运行状态，一旦电池耗尽，通信中断，可能会导致重大损失。比如，应用于火警联动的设备直接将信号传送至消防中心。超长的电池使用时间，就显得尤为重要。
3）增强覆盖
对于物联网M2M应用，覆盖同样非常重要。一个简单的例子，智能水表都安装在地下室或建筑物内隐蔽的地方。由于信号衰减，通常这些地方信号偏弱。所以，需要提升增强网络覆盖来应对物联网。
设备成本
为了减少设备成本，R12就制定了Cat.0终端等级，实际上，Cat.0指的就是低成本的M2M设备。为了降低设备复杂性和减小设备成本，Cat.0定义了一系列的简化方案，主要包括：
1.半双工FDD模式（Half duplex FDD)。
半双工FDD模式允许在FDD模式下时分复用。
2.减小设备接收带宽到1.4MHz，当然，也可以扩到20MHz。
3.单接收通路，取消RX分集双通路。
4.低速数据速率。不仅降低速率需求，处理器计算能力和存储能力也相对降低。
在R13版本还会有进一步的优化，比如取消发射分集，不再支持MIMO，支持小于1.4MHz更低的带宽，支持更低的数据速率。
关于Cat.0、Cat.1、Cat.4和R13版本的Cat.的特征比较如下图：
为了面向物联网，降低设备成本，除了定义Cat.0终端设备等级外，还需要对电池使用时长和覆盖进行优化。
电池使用寿命
为了省电，R12采用一种叫power saving mode (PSM，省电模式)的方案。如果设备支持PSM，在附着或TAU（Tracking Area Update）过程中，PSM向网络申请一个激活定时器值。当设备从连接状态转移到空闲状态后，该定时器开始运行。当定时器终止，设备进入省电模式。当设备进入省电模式，设备不再接收寻呼消息，看起来设备和网络失联，但设备仍然注册在网络中。设备将一直保持这种省电模式，直到设备需要主动向网络发送信息（比如周期性TAU，发送上行数据等）。
据说，采用这种方案，两节5号电池可以用10年以上。
如上图，如果DRX不连续接收循环为10分钟，设备每周上传一次数据，这样，两节5号电池可以用132月（11年）之久。
增强覆盖
在增强覆盖方面，LTE-M采用的技术包括：放大数据和参考信号发射功率、重传、和降低性能需求，比如，允许更长时延和更高的误码率。采用这些技术，覆盖性能可以提升20dB。
总之，当我们在要求4G网络更快、更强时，物联网M2M设备却不停在喊，低点，再低点，还能再低么？也许后面还有比Cat.0更低的等级，不过应该叫Cat.几呢？
*请认真填写需求信息，我们会在24小时内与您取得联系。
