html显示日志_[转摘] 大厂WEB日志采集规范（一）

一、背景

网站页面是互联网服务的基本载体，即使在如今传统互联网形态逐渐让位于移动互联网的背景下，HTML页面依旧是最普遍的业务形态，对于以网页为基本展现形式的互联网产品和服务，衡量其业务水平的基本指标是网页浏览量（PV）和访客数（UV）。为此，需要采集页面被浏览器加载展现的记录，这是最原始的互联网日志采集需求，也是一切互联网数据分析得以展开的基础和前提。

二、浏览器的页面日志采集

浏览器的页面型产品/服务的日志采集可分为如下两大类。

（1）页面浏览（展现）日志采集。顾名思义，页面浏览日志是指当一个页面被浏览器加载呈现时采集的日志。此类日志是最基础的互联网日志，也是目前所有互联网产品的两大基本指标：页面浏览量（Page View，PV）和访客数（Unique Visitors，UV）的统计基础。页面浏览日志是目前成熟度和完备度最高，同时也是最具挑战性的日志采集任务，我们将重点讲述此类日志的采集。

（2）页面交互日志采集。当页面加载和渲染完成之后，用户可以在页面上执行各类操作。随着互联网前端技术的不断发展，用户可在浏览器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据，以便通过量化获知用户的兴趣点或者体验优化点。交互日志采集就是为此类业务场景而生的。

除此之外，还有一些专门针对某些特定统计场合的日志采集需求，如专门采集特定媒体在页面被曝光状态的曝光日志、用户在线状态的实时监测等，但在基本原理上都脱胎于上述两大类。

2.1、页面浏览日志采集流程

目前典型的网页访问过程是以浏览器请求、服务器响应并返回所请求的内容（大多以HTML文档的形式）这种模式进行的，浏览器和服务器之间的通信普遍遵守HTTP协议（超文本传输协议，目前以HTTP 1.1为主，逐渐向最新的HTTP 2.0过渡）。浏览器发起的请求被称为HTTP请求（HTTP Request），服务器的返回则被称为HTTP响应（HTTP Response）。

我们以用户访问某页面（http://www.xxx.com）为例

（1）用户在浏览器内点击页面链接（或在地址栏中输入www.xxx.com并回车）。

（2）浏览器向业务服务器发起HTTP请求。在本例子中，用户可以看见的内容只是显示于浏览器地址栏内的http://www.xxx.com，而浏览器在执行时，会解析用户请求并按照HTTP协议中约定的格式将其转化为一个HTTP请求发送出去。

按照HTTP协议，一个标准的HTTP请求由如下三部分构成。

请求行（HTTP Request Line）。请求行内有三个要素，分别是请求方法、所请求资源的URL以及HTTP协议版本号。在本例子中，这三个要素分别是GET、http://www.xxx.com/以及HTTP 1.1，对于我们所讨论的话题，记住请求行内最重要的信息是这个URL就可以了。

请求报头（HTTP Message Header）。请求报头是浏览器在请求时向服务器提交的附加信息，请求报头一般会附加很多内容项（每项内容被称为一个头域（Header Field），在不引起混淆的情况下，往往将Header Field简称为Header）。需要注意的是，如果用户在本次页面访问之前已经到访过网站或者已经登录，则一般都会在请求头中附加一个或多个被称为Cookie的数据项，其中记录了用户上一次访问时的状态或者身份信息，我们只需理解浏览器在发起请求时会带上一个标明用户身份的Cookie即可。

请求正文（HTTP Message Body）。这一部分是可选的，一般而言，HTTP请求的正文都是空的，可以忽略。

（3）服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照HTTP协议规定的格式，将处理结果以HTTP响应形式发回浏览器。

与HTTP请求相对应，一个标准的HTTP响应也由三部分构成。

状态行。状态行标识了服务器对于此次HTTP请求的处理结果。状态行内的主要内容是一个由三位数字构成的状态码，我们最熟知的两个状态码分别是代表成功响应的200（OK）和代表所请求的资源在服务器端没有被找到的404（Not Found）。

响应报头。服务器在执行响应时，同样可以附加一些数据项，这些数据项将在浏览器端被读取和使用。事实上，在大多数页面和应用中，响应报头内的内容在确保页面正确显示和业务正常进行方面都发挥着至关重要的作用。其中最重要的一类Header即上面所提到的Cookie，浏览器所记录的Cookie，其实是由服务器在响应报头内指令浏览器记录的。举个例子，如果用户在页面登录，则服务器会在登录请求的响应报头内指示浏览器新增一个名为userid的Cookie项，其中记录了登录用户的id。如此一来，当用户随后再次访问该网站时，浏览器将自动在请求报头内附加这个Cookie，服务器由此即可得知本次请求对应的用户到底是谁；如果服务器发现浏览器在请求时传递过来的Cookie有缺失、错误或者需要更新，则会在响应报头内指令浏览器增加或更新对应的Cookie。

响应正文。和请求正文一样，这一部分在协议中也被定义为可选部分，但对于大多数HTTP响应而言，这一部分都是非空的，浏览器请求的文档、图片、脚本等，其实就是被包装在正文内返回浏览器的。在本例子中，服务器会将对应的HTML文档封装在正文内。

（4）浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，从而完成一次请求。在本例子中，浏览器请求页面，服务器返回对应的HTML文档，浏览器即按照HTML文档规范解析文档并将整个页面渲染在屏幕上。

上面描述了一次典型的网页浏览过程，如果需要记录这次浏览行为，则采集日志的动作必然是附加在上述四个步骤中的某一环节内完成的。在第一步和第二步，用户的请求尚未抵达服务器；而直到第三步完成，我们也只能认为服务器处理了请求，不能保证浏览器能够正确地解析和渲染页面，尚不能确保用户已确实打开页面，因此在前三步是无法采集用户的浏览日志的。那么采集日志的动作，需要在第四步，也就是浏览器开始解析文档时才能进行。根据前文所述，可以很自然地得出在这一模式下最直接的日志采集思路：在HTML文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。这就是目前几乎所有互联网网站页面浏览日志采集的基本原理，而业界的各类网页日志采集的解决方案只是在实施的细节、自动采集内容的广度以及部署的便利性上有所不同。

2.2、页面交互日志采集

PV日志的采集解决了页面流量和流量来源统计的问题，但随着互联网业务的发展，仅了解用户到访过的页面和访问路径，已经远远不能满足用户细分研究的需求。在很多场合下，需要了解用户在访问某个页面时具体的互动行为特征，比如鼠标或输入焦点的移动变化（代表用户关注内容的变化）、对某些页面交互的反应（可借此判断用户是否对某些页面元素发生认知困难）等。因为这些行为往往并不触发浏览器加载新页面，所以无法通过常规的PV日志采集方法来收集。

因为终端类型、页面内容、交互方式和用户实际行为的千变万化不可预估，交互日志的采集和PV日志的采集不同，无法规定统一的采集内容（例如，活动页面的游戏交互和购物车页面的功能交互两者相比，所需记录的行为类型、行为数据以及数据的结构化程度都截然不同），呈现出高度自定义的业务特征。

需要采集交互日志的业务，经过如下步骤即可将自助采集的交互日志发送到日志服务器。

（1）交互日志采集代码模板。

（2）将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。

（3）当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。

（4）采集代码在采集动作完成后将对应的日志通过HTTP协议发送到日志服务器，日志服务器接收到日志后，对于保存在HTTP请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。

经过上述步骤采集到日志服务器的业务随后可被

按需自行解析处理，并可与正常的PV日志做关联运算。

转摘自：《大数据之路》