海量Web日志分析系统

  • Web需要有智能性，能快速、准确地帮助用户找到其需要的信息；
  • Web站点的运营方对Web用户的行为也越来越有兴趣。

分析Web日志数据的目的

服务器产生的日志并不依赖于业务系统生成，而是借助于服务器针对客户的HTTP请求参数属性来保存必要的信息，从数据生成和捕获两个方面都较为简单且不对业务系统产生侵入性，而且大多Web服务器支持自定义的日志格式以匹配通用或自定义的日志分析工具，而且服务器的日志文件中能够简单直接获取网络爬虫数据，也能够收集底层数据供反复分析。

  • 了解Web用户的行为之后，可以为其提供更加精确的服务，如精确营销；
  • 可以根据用户的行为，调整Web的组织和结构，以吸引和留住更多的用户；
  • 可基于Web用户的行为，分析出Web站点的不足之处，为Web站点的安全提供参考。

重要的Web日志信息如下

  1. 请求（request）：HTTP请求中包含的请求类型比较少被用于统计，只有少数的统计表单提交情况时会被用到，而版本号对统计来说基本是无用的。
  2. 状态码（status）：状态码比较经常被用于一些请求响应状态的监控，如301页面重定向或者404错误，统计这些信息可以有效地改进页面的设计，提高用户体验。
  3. 传输字节数（bytes）：可以判断页面是否被完全打开、文件是否已被读取、操作是否被中断，但在动态页面无法判断。
  4. 来源页面（referrer）：referrer涉及的统计较为常见，一般是统计访问的来源类型、搜索引擎、搜索关键字等。同时，也是单击流中串连用户访问足迹的依据。
  5. 用户代理（agent）：识别网络爬虫，统计用户的系统、浏览器类型、版本等信息，为网站开发提供建议，分析各类浏览器的使用情况和出错概率等。
  6. session和cookie ：session被用于标识一个连续的访问，cookie主要用于用户识别，也是统计唯一访问的依据。

特殊的网站日志

记录服务器的提示、警告及错误信息，这类日志可以被用于分析用户的错误。

通过对日志文件的分析，可以获得如下信息：

（1）分析网站用户的访问时间，总结出网站在哪段时间的访问量最大。

（2）判断IP地址的地域性，总结出网站经常被来自哪个地区的人群访问。

（3）检查被访问的资源名称，分析出网站的具体哪个内容最受欢迎。

（4）检查用户访问的返回代码，分析出网站是否存在错误。

Web日志分析的典型应用场景

例如，某电子商务网站存在在线团购业务，通过日志分析后可以得到如下数据统计：

  • 每日PV(page view)，即页面浏览量450万，独立IP数25万。
  • 用户通常在工作日10:0012:00和15:0018:00访问量最大。
  • 日间主要是通过PC端浏览器访问，休息日及夜间通过移动设备访问较多。
  • 网站搜索流量占整个网站的80%，PC用户不足1%的用户会消费，移动用户有5%会消费。

通过简短的描述，可以粗略地看出电子商务网站的经营状况、愿意消费的用户从哪里来、有哪些潜在的用户可以挖掘、网站是否存在倒闭风险等。

网站说日均IP/ PV 访问量约为600 / 2400的意思是，今天访问首页次数为2400次，访问IP为600个。也就是说这600个IP一共访问首页2400次。

日志的不确定性

Web日志中哪些项目可能造成数据的不准确、造成这些缺陷的原因，以及后续对案例项目进行优化改进

  1. 客户端的控制和限制

由于一些浏览网站的用户信息是由客户端发送的，所以用户的IP、Agent（代理）都是可以人为设置的。另外，cookie可以被清理，浏览器出于安全的设置，用户可以在访问过程中限制cookie、referrer的发送。这些都会导致用户访问数据的丢失或者数据的不准确，而这类问题目前很难得到解决。

  1. 缓存
    浏览器缓存、服务器缓存、后退按钮操作等都会导致页面单击日志的丢失及referrer的丢失，目前主要的处理方法是保持页面信息的不断更新，可以在页面中添加随机数。
    如果使用JavaScript自行记录日志的方法，那么就不需要担心缓存的问题。
  2. 跳转

一些跳转导致referrer信息的丢失，致使用户的访问足迹中断而无法跟踪。

解决方法是将referrer通过URL重写，作为URL参数带入下一页面，不过这样会使页面的URL显得混乱。

  1. 代理IP、动态IP、局域网（家庭）公用IP
    IP其实准确性并不高，现在不只存在伪IP，而且局域网共享同一公网IP、代理的使用及动态IP分配方式，都可能使IP地址并不是与某个用户绑定的，所以如果有更好的方法，就尽量不要使用IP来识别用户。
  2. session的定义与多个cookie
    不同的网站对session的定义和获取方法可能存在差异，比如非活动状态session的失效时间、多进程同时浏览时session id的共享等，所以同一个网站中session的定义标准必须统一才能保证统计数据的准确。
    cookie的不准确，一方面是由于某些情况下cookie无法获取，另一方面是由于一个客户端可以有多个cookie，诸如Chrome、Firefox等浏览器的cookie存放路径都会与IE的cookie存放路径分开，所以如果是用不同的浏览器浏览同一网站，很有可能cookie就是不同的。
  3. 停留时间
    停留时间并不是直接获取的，而是通过底层日志中的数据计算得到的，因为所有日志中的时间都是时刻的概念，即单击的时间点。
    另外，也无法获知用户在浏览一个页面的时候到底做了什么，是不是一直在阅读博客上的文章或者浏览网站上展示的商品，用户也有可能在此期间上了次厕所、接了通电话或者放空了片刻，所以计算得到的停留时间并不能说明用户一直处于有效交互浏览的状态。

日志分析的KPI

  1. PV(PageView)
    PV是最重要的统计指标之一，它用于统计单一的Web资源被访问的次数。为了能够使该指标更为准确地反映用户对Web站点中特定资源的爱好度并以此为依据进行Web的内容优化，在统计时往往需要对待统计的资源进行过滤，去除对结果无意义的某些静态资源，如仅作为布局背景存在的图片、CSS文件、JS代码等。
  2. IP
    页面独立IP的访问量统计，从逻辑上反映某个页面有多少用户访问过，实际情况下需要使用某些特定手段来判定IP与用户之间的对应关系（由于共享IP或代理IP的问题，不能保证一个IP对应一个用户）。
  3. Time
    一个时间段（如1小时）的PV的统计，用于分析网站用户群体的时间分布，可以提供系统维护的优化时间（系统维护的原则应该是不影响绝大部分用户的正常访问请求）。
  4. Source
    用户来源域名的统计，可以从逻辑上分析得到网站推广活动的合理性。
  5. Browser
    用户的访问设备统计，其结果可以帮助分析实际活跃用户（真实用户和网络爬虫有参数差异），并分析用户的行为习惯，优化产品版本迭代策略。

案例系统结构

日志是由业务系统产生的，可以设置Web服务器每天产生一个新的目录，目录下面会产生多个日志文件，每个日志文件128MB（Hadoop 2之后的HDFS默认分块大小），设置系统定时器如CRON，每日0时后向HDFS导入头一天的日志文件。

完成导入后，设置系统定时器，启动调度MapReduce程序，提取并计算统计指标。完成计算后，设置系统定时器，从HDFS导出统计指标数据到数据库，方便以后的实时查询。

系统结构

海量Web日志分析系统 - 图1

系统执行流程

海量Web日志分析系统 - 图2

详细解释了一个实际环境中日志分析功能组件的执行逻辑

日志分析方法

在Web日志中，每条日志通常代表用户的一次访问行为。

一条典型的Nginx日志

  1. 112.195.209.90 - - [20/Feb/2018:12:12:14 +0800] "GET / HTTP/1.1" 200 190 "-" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36" "-"

这条日志可以通过分隔符（空格）拆解为8个变量数据供分析时使用。

  • remote_addr：记录客户端的IP地址，112.195.209.90。
  • remote_user：记录客户端用户名称。
  • time_local：记录访问时间与时区，[20/Feb/2018:12:12:14 +0800]。
  • request：记录请求的URL与HTTP，”GET / HTTP/1.1”。
  • status：记录请求状态，成功是200。
  • body_bytes_sent：记录发送给客户端文件主体内容大小，190。
  • http_referer：记录是从哪个页面链接访问过来的，”-“。
  • http_user_agent：记录客户浏览器的相关信息，”Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Mobile Safari/537.36”。