刚来新公司做运维开发。我想我会继续做我的开源软件开发。结果，领导布置了一个我以前从来没有考虑过的任务，监控用户访问我们网站的速度，没错，就是监控所有用户访问我们网站的速度。就像语气一样。因为Keynote不能满足我们一些特殊的定制需求，所以公司准备我们自己开发一个。虽然以前没做过，但是有挑战很有意思，所以我开始走路了。首先，确定如何监控页面速度？要监控哪些指标？如何分析？领导的基本需求如下：实现全国用户访问速度的区域分析实现从浏览器请求开始到页面加载完成的每一步指标统计实现任务如何下发到指定区域？我首先想到的是，是否可以通过分析网站日志来实现？尼玛，当然不可能这么简单，因为日志只能记录服务器从收到请求到开始响应的时间。当用户完全加载您的页面时，将无法找到它。现在是什么？先学习基调监控法，发现他们在全国各个机房埋下了数以万计的客户端，让这些客户端定时自动访问你的网站，然后总结分析每个客户端的加载速度。很显然，我们不可能在全国每个机房都放一台机器作为client，这样的费用必须把公司卖了。本着花小钱办大事的想法，灵光一现，为什么不让用户直接帮我们测试呢？我们的网站每天都有上亿的PV，这么好的资源不用就浪费了。为什么要让用户帮我们测试？呵呵，很简单。在页面中嵌入代码。当用户访问我们的页面时，浏览器会自动运行一个JS脚本，该脚本会记录从浏览器请求开始到整个页面加载完成的过程。然后我的脚本把这些记录的值做成一个字典，以GET的形式发送给后台分析接口。后台tap程序收到数据后，根据对应的分析维度进行分析，问题得到解决。出色地。GOOD，既然你觉得逻辑能行，那我们就开始测试吧，干货不说了，下面是实现过程：请求到服务器的加载时间响应时间DomReady时间首次渲染时间（白屏时间）DNS查找时间从服务器下载第一个字节的时间导航类型请求的url浏览器类型浏览器版本解析以上指标只是第一阶段的功能，还有以后可能会加入很多新的指标，完全自己写JS还是挺麻烦的。尼玛，我是运维开发人员，不是前端开发人员。这么多东西怎么弄，果断找了个开源的方案，找了找也找到了。yahoo开源的一个收集页面速度指标的小插件boomerang。下载使用后发现功能非常强大，支持自研插件。所以我在它的基础上做了一些改动，增加了一些自定义的指标集合。为了帮助大家理解，我给大家说说上面的指标是怎么采集的？一个HTML页面实际上从服务器开始请求到整个页面显示在用户面前要经过很多步骤。擦，说累不累，我们先过上图。如上图所示，页面的整个加载过程大致如下：输入网址回车导航开始DNS解析获取网站IP地址domainLookupStart向服务器IP发起请求，TCP/IP3次握手，并建立连接ConnectStart服务器开始处理用户请求的页面URL发送第一个字节FristByteDOM加载domCompleteOnload事件启动LoadEventtart页面加载LoadEventEnd亲，现在基本上所有主流浏览器都会在页面加载时记录这些指标，可以直接在JS脚本中调用，调用方法等指标详细解释请参考https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html，因为不支持IE9以下的浏览器，去他妈的IE，坚决放弃老版本的IE，直接设置成IE9下不执行，简单粗暴。浏览器版本本测试代码完成后，上线测试，打开网站，你会看到我的脚本华丽丽的运行起来了。由于每天的采集量在几千万左右，然后需要实时分析用户访问速度，所以使用了storm实时日志流分析。对数据进行基本处理后，统计各区域的访问情况。过了一会儿，写到redis。由于数据量大，实时数据只保存1天左右。一天后，数据按小时平均和优化。#p#分析方法由于数据量大，如果简单的直接对数据进行平均，肯定会出现很多极值，导致平均值不代表整组数据的实际平均值。比如两组数，[1,999],[499,501]两组数的平均值等于500，直接取平均值太糟糕了。这时候终于要用到高中数学了。取标准差，中位数，然后TP90，TP99，再往下走，数据基本准确。当然，很多细节都实现了。有兴趣的同学可以找我讨论。只看最后的实现：下面是实时监控部分：好了，就这些了，回过头来试试开源吧。今天就这样吧。博客地址：http://3060674.blog.51cto.com/3050674/1439129
