离线实战-网络日志监控分析(二):数据采集之Flume采集与数据的预处理

离线实战-网络日志监控分析(二):数据采集之Flume采集与数据的预处理

Taildir Source 组件

Flume 采集系统的搭建相对简单:

  • 在服务器上部署 agent 节点,修改配置文件
  • 启动 agent 节点,将采集到的数据汇聚到指定的 HDFS 目录中

针对 nginx 日志生成场景,如果通过 flume(1.6)收集,无论是 Spooling Directory Source 和 Exec Source 均不能满足动态实时收集的需求,在 flume1.7 版本之后,提供了一 个非常好用的 TaildirSource,使用这个 source,可以监控一个目录,并且使用正则表达式 匹配该目录中的文件名进行实时收集。

a1.sources = r1 
a1.sources.r1.type = TAILDIR 
a1.sources.r1.channels = c1 
a1.sources.r1.positionFile = /var/log/flume/taildir_position.json 
a1.sources.r1.filegroups = f1 f2 
a1.sources.r1.filegroups.f1 = /var/log/test1/example.log 
a1.sources.r1.filegroups.f2 = /var/log/test2/.*log.*

filegroups:指定 filegroups,可以有多个,以空格分隔;(TailSource 可以同时监控tail 多个目录中的文件)

positionFile:配置检查点文件的路径,检查点文件会以 json 格式保存已经 tail 文件的位置,解决了断点不能续传的缺陷。

filegroups.<filegroupName>:配置每个 filegroup 的文件绝对路径,文件名可以用正则表达式匹配

通过以上配置,就可以监控文件内容的增加和文件的增加。产生和所配置的文件名正则 表达式不匹配的文件,则不会被 tail。

执行脚本

bin/flume-ng agent -c conf -f conf/tailDir_agent_HDFS_sink -n a1 -Dflume.root.logger=INFO,console

HDFS sink 文件滚动属性

基于文件闲置时间策略

配置项:hdfs.idleTimeout
默认值:0
说明:默认启动这个功能

这种策略很简单,如果文件在 hdfs.idleTimeout 秒的时间里都是闲置的,没有任何数据写入,那么当前文件关闭,滚动到下一个文件。这个配置在配置中可以设定成10分钟或者20分钟,在没有数据写入的时候自动让其滚动写入。

基于 hdfs 文件副本数

配置项:hdfs.minBlockReplicas
默认值:和 hdfs 的副本数一致
原理:hdfs.minBlockReplicas 是为了让 flume 感知不到 hdfs 的块复制,这样滚动方式配置(比如时间间隔、文件大小、events 数量等)才不会受影响。

假如 hdfs 的副本为 3.那么配置的滚动时间为 10 秒,那么在第二秒的时候,flume检测到 hdfs 在复制块,那么这时候 flume 就会滚动,这样导致 flume 的滚动方式受到影响。所以通常hdfs.minBlockReplicas 配置为 1,就检测不到副本的复制了。但是hdfs 的副本还是 3。

项目中数据的分析

58.215.204.118 - - [18/Sep/2018:06:51:35 +0000] "GET /wp-includes/js/jquery/jquery.js?ver=1.10.2 HTTP/1.1"304 0 "http://blog.fens.me/nodejs-socketio-chat/" "Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0"

字段解析:

  1. 访客 ip 地址: 58.215.204.118
  2. 访客用户信息: – – (cookies)
  3. 请求时间:[18/Sep/2018:06:51:35 +0000]
  4. 请求方式:GET
  5. 请求的 url:/wp-includes/js/jquery/jquery.js?ver=1.10.2
  6. 请求所用协议:HTTP/1.1
  7. 响应码:304
  8. 返回的数据流量:0
  9. 访客的来源 url:http://blog.fens.me/nodejs-socketio-chat/
  10. 访 客所用 浏览 器: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Firefox/23.0

数据预处理

1、主要目的:

过滤“不合规”数据,清洗无意义的数据 格式转换和规整 根据后续的统计需求,过滤分离出各种不同主题(不同栏目 path)的基础数据。

image

2、实现方式

使用 MapReduce 程序对数据进行预处理。

image

预处理过程中有些编程小技巧需要注意:

  • 如果涉及多属性值数据传递 通常可建立与之对应的 javabean 携带数据传递 注意要实现 Hadoop 序列化机制—writable 接口。
  • 有意识的把 javabean 中 toString 方法重写,以\001 进行分割,方便后续数据 入 hive 映射方便。
  • 如涉及不符合本次分析的脏数据,往往采用逻辑删除,也就是自定义标记位, 比如使用 1 或者 0 来表示数据是否有效,而不是直接物理删除。

点击流模型数据

点击流概念

点击流(Click Stream)是指用户在网站上持续访问的轨迹。注重用户浏览 网站的整个流程。用户对网站的每次访问包含了一系列的点击动作行为,这些点 击行为数据就构成了点击流数据(Click Stream Data),它代表了用户浏览网站 的整个流程。

点击流和网站日志是两个不同的概念,点击流是从用户的角度出发,注重用 户浏览网站的整个流程;而网站日志是面向整个站点,它包含了用户行为数据、服务器响应数据等众多日志信息击流数据。

image

点击流模型完全是业务模型,相关概念由业务指定而来。由于大量的指标统 计从点击流模型中更容易得出,所以在预处理阶段,可以使用 MapReduce 程序来 生成点击流模型的数据。 在点击流模型中,

存在着两种模型数据:PageViewsVisits。

点击流模型 pageviews

Pageviews 模型数据 专注于用户每次 会话( session ) session 内访问了几步和每一步的停留时间。

在网站分析中,通常把前后两条访问记录时间差在 30 分钟以内算成一次会话。如果超过 30 分钟,则把下次访问算成新的会话开始。

大致步骤如下:

  • 在所有访问日志中找出该用户的所有访问记录
  • 把该用户所有访问记录按照时间正序排序
  • 计算前后两条记录时间差是否为 30 分钟
  • 如果小于 30 分钟,则是同一会话 session 的延续
  • 如果大于 30 分钟,则是下一会话 session 的开始
  • 用前后两条记录时间差算出上一步停留时间
  • 最后一步和只有一步的 业务默认指定页面停留时间 60s

相关新闻