监控运维那点事-客户体验监控2

上一篇主要概述了监控运维流程与工具的事情，这篇将侧重监控系统工具，监控层次比较多，从基础到上层业务，可分为基础设施、软件中间件、应用系统、客户体验4个层次。 如何入手？思路+方法.
思路：

1. 以终为始，关注客户体验相关服务监控。 
2. 持续迭代，罗马非一日建成。
3. 站在巨人肩膀上，借力云服务。

客户体验监控--短平快:传统的“网管”是从底下物理设备上开始的，侧重网络；而以终为始则是反过来，在强调用户体验的今天，网站和app的客户感知是非常重要的，网站都宕了，网络服务再好有毛用？

1. 网站类和APP服务可用性监控，通过http、tcp监测方式，实时监控网站80/8080端口等通断情况。基本上主流的公有云都提供该服务，例如阿里云和腾讯云，云监控服务基本都是免费的。马哥的便宜不赚白不赚。
2. 基础设施服务器监控，也可以用ping方式搞定。

3. 软件中间件，基本上通过tcp\udp侦听服务的端口即可，如mysql数据库的3306端口。部分服务部署在内网不对外（公网），需要内网部署探针方式。

基本上协议级（http、tcp、udp、ping）监控可以解决掉公网服务的应用/业务可用性监控，至少可以做到客户体验中可用（可达）保障。

优点是见效快，几分钟-个把小时基本完成。

缺点是内网方面，部分服务部署在内网不对外（公网），需要内网部署探针方式，如监控宝。

客户体验监控--端到端：端到端（end-to-end）即用户端到服务器端，见下图（110云监控仅内测，未发布。110云告警已公测），由于链路复杂，特别是使用云服务后，虽然使用简单，但实际的IT复杂度增大，任何一个环节出现问题都会影响最终用户的体验。



端到端关注的指标包括：

1. 通断（可用性），服务是否能用，客户是否正常打开页面，打开APP。
2. 质量性能，访问速度。网站页面的首次响应时间，首页展现时间，全页面加载时间，用户可操作时间等；移动APP页面异常、不同版本OS的兼容性，与服务器端的API接口响应耗时。另外还涉及到不同区域、不同运营商线路等。
3. 准确性，至是否准确的响应内容，如是否可以登录，是否正常显示内容，与实际业务操作场景有关。

具体实现技术基本上是从两个方向：主动探测和全量被动检测方式。

1. 主动探测，指主动模拟真实用户的操作动作：

网站类的，通过嵌入式浏览器实现网站页面的访问操作，实际记录页面的可用性、页面响应、加载、完成耗时，实际的每个请求页面元素耗时和状态等；可以说基本上是与实际用户操作基本类似。

移动APP类的，主要是安卓，通过在不同品牌和不同版本的安卓机器上，通过脚本实际操作具体的测试APP操作，从移动网络、真实屏幕页面操作上最大可能模拟真实用户。

探测点分布问题：主动探测一般尽可能的在全国各地、各运营商网络链路进行模拟，从而获知最真实的客户体验。

目前主动探测方面，以基调、博睿为代表的网络起家监控厂商为代表，侧重于网站类探测，但是仅是可用性和首次响应，真实的页面加载方面欠缺。移动APP探测以testin云测为典型代表。

2. 全量被动式检测，有两种模式，嵌码式和网络流量流向全局监控方式。优点是全量，而不是零散式，同时也是缺点，存储量和实现难度更大。

嵌码式是指通过嵌入代码实现监控，但是目前国内很少见，百度网站统计主要是用户分析，不做质量性能监控。而移动APP的嵌入式，一般是sdk方式，对网络质量、API请求调用、屏幕页面异常、操作系统版本、运营商和区域分布进行全量的监控，目前国内靠谱的服务提供商暂没有，国外优秀SaaS云监控服务商newrelic和appdynamics支持。

网络流量流向监控，一般是交换机端口旁路复制，或者是DPI模式。国外厂家，如IBM\HP\Oracle\BMC\CA等传统公司给土豪级国企使用。基本来说是费力不讨好类型，这也是这些传统企业的市场被新兴SaaS云监控服务商吞噬原因。

说了半天，端到端 监控很重要，但是理想很丰满，现实很骨感。大多是通过分析应用日志和负载均衡设备（nginx等）手段实现。

 很期待国内有靠谱的厂家出来，可惜目前无论是传统转型的基调、博睿，还是新兴的监控宝、oneapm以及阿里云、腾讯云等，都没有完全到位。

透露点信息，原先110云监控做的客户体验监控功能上有点意思了，由于在用户体验和性能高并发上达不到BOSS的“5分钟理论”要求，被停掉，攻城狮们还需努力呀。

向New Relic和App Dynamics致敬！