整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
集web日志的目的
Web日志挖掘是指采用数据挖掘技术，对站点用户访问Web服务器过程中产生的日志数据进行分析处理，从而发现Web用户的访问模式和兴趣爱好等，这些信息对站点建设潜在有用的可理解的未知信息和知识，用于分析站点的被访问情况，辅助站点管理和决策支持等。
1、以改进web站点设计为目标，通过挖掘用户聚类和用户的频繁访问路径，修改站点的页面之间的链接关系，以适应用户的访问习惯，并且同时为用户提供有针对性的电子商务活动和个性化的信息服务，应用信息推拉技术构建智能化Web站点。
2、以分析Web站点性能为目标，主要从统计学的角度，对日志数据项进行粗略的统计分析，得到用户频繁访问页、单位时间的访问数、访问数量随时间分布图等。现有的绝大多数的Web日志分析工具都属于此类。
3、以理解用户意图为目标，主要是通过与用户交互的过程收集用户的信息，Web服务器根据这些信息对用户请求的页面进行裁剪，为用户返回定制的页面，其目的就是提高用户的满意度和提供个性化的服务。
收集方式
网站分析数据主要有三种收集方式：Web日志、JavaScript标记和包嗅探器。
1. Web日志
web日志处理流程：
从上图可以看出网站分析数据的收集从网站访问者输入URL向网站服务器发出http请求就开始了。网站服务器接收到请求后会在自己的Log文件中追加一条记录，记录内容包括：远程主机名(或者是IP地址)、登录名、登录全名、发请求的日期、发请求的时间、请求的详细(包括请求的方法、地址、协议)、请求返回的状态、请求文档的大小。随后网站服务器将页面返回到访问者的浏览器内得以展现。
2. JavaScript标记
JavaScript标记处理流程：
上图所示JavaScript标记同Web日志收集数据一样，从网站访问者发出http请求开始。不同的是，JavaScript标记返回给访问者的网页代码中会包含一段特殊的JavaScript代码，当页面展示的同时这段代码也得以执行。这段代码会从访问者的Cookie中取得详细信息(访问时间、浏览器信息、工具厂商赋予当前访问者的userID等)并发送到工具商的数据收集服务器。数据收集服务器对收集到的数据处理后存入数据库中。网站经营人员通过访问分析报表系统查看这些数据。
3. 包嗅探器
通过包嗅探器收集分析的流程：
上图可以看出网站访问者发出的请求到达网站服务器之前，会先经过包嗅探器，然后包嗅探器才会将请求发送到网站服务器。包嗅探器收集到的数据经过工具厂商的处理服务器后存入数据库。随后网站经营人员就可以通过分析报表系统看到这些数据。
web日志挖掘过程
整体流程参考下图：
1、数据预处理阶段根据挖掘的目的，对原始Web日志文件中的数据进行提取、分解、合并、最后转换为用户会话文件。该阶段是Web访问信息挖掘最关键的阶段，数据预处理包括:关于用户访问信息的预处理、关于内容和结构的预处理。
2、会话识别阶段该阶段本是属于数据预处理阶段中的一部分，这里将其划分成单独的一个阶段，是因为把用户会话文件划分成的一组组用户会话序列将直接用于挖掘算法，它的精准度直接决定了挖掘结果的好坏，是挖掘过程中最重要的阶段。
3、模式发现阶段模式发现是运用各种方法和技术从Web日志数据中挖掘和发现用户使用Web的各种潜在的规律和模式。模式发现使用的算法和方法不仅仅来自数据挖掘领域，还包括机器学习、统计学和模式识别等其他专业领域。
模式发现的主要技术有：统计分析（statistical analysis）、关联规则（association rules）、聚类（clustering）、归类（classification）、序列模式（sequential patterns）、依赖关系（dependency）。
（1）统计分析（statistical analysis）：常用的统计技术有：贝叶斯定理、预测回归、对数回归、对数-线性回归等。可用来分析网页的访问频率，网页的访问时间、访问路径。可用于系统性能分析、发现安全漏洞、为网站修改、市场决策提供支持。
（2）关联规则（association rules）：关联规则是最基本的挖掘技术，同时也是WUM最常用的方法。在WUM中常常用在被访问的网页中，这有利于优化网站组织、网站设计者、网站内容管理者和市场分析，通过市场分析可以知道哪些商品被频繁购买，哪些顾客是潜在顾客。
（3）聚类（clustering）：聚类技术是在海量数据中寻找彼此相似对象组，这些数据基于距离函数求出对象组之间的相似度。在WUM中可以把具有相似模式的用户分成组，可以用于电子商务中市场分片和为用户提供个性化服务。
（4）归类（classification）：归类技术主要用途是将用户资料归入某一特定类中，它与机器学习关系很紧密。可以用的技术有：决策树（decision tree）、K-最近邻居、Na?ve Bayesian classifiers、支持向量机（support vector machines）。
（5）序列模式（sequential patterns）：给定一个由不同序列组成的集合，其中，每个序列由不同的元素按顺序有序排列，每个元素由不同项目组成，同时给定一个用户指定的最小支持度阈值，序列模式挖掘就是找出所有的频繁子序列，即子序列在序列集中的出现频率不低于用户指定的最小支持度阈值。
（6）依赖关系（dependency）：一个依赖关系存在于两个元素之间，如果一个元素A的值可以推出另一个元素B的值，则B依赖于A。
4、模式分析阶段模式分析是Web使用挖掘最后一步，主要目的是过滤模式发现阶段产生的规则和模式，去除那些无用的模式，并把发现的模式通过一定的方法直观的表现出来。由于Web使用挖掘在大多数情况下属于无偏向学习，有可能挖掘出所有的模式和规则，所以不能排除其中有些模式是常识性的，普通的或最终用户不感兴趣的，故必须采用模式分析的方法使得挖掘出来的规则和知识具有可读性和最终可理解性。常见的模式分析方法有图形和可视化技术、数据库查询机制、数理统计和可用性分析等。
收集数据包括
收集的数据主要包括：
全局UUID、访问日期、访问时间、生成日志项的服务器的IP地址、客户端试图执行的操作、客户端访问的服务器资源、客户端尝试执行的查询、客户端连接到的端口号、访问服务器的已验证用户名称、发送服务器资源请求的客户端IP地址、客户端使用的操作系统、浏览器等信息、操作的状态码（200等）、子状态、用Windows@使用的术语表示的操作的状态、点击次数。
用户识别
对于网站的运营者来说，如何能够高效精确的识别用户非常关键，这会对网站运营带来极大的帮助，如定向推荐等。
用户识别方法如下：
使用HDFS存储
数据收集到服务器之后，根据数据量可以考虑将数据存储在hadoop的HDFS中。
在现在的企业中，一般情况下都是多台服务器生成日志，日志包括nginx生成的，也包括在程序中使用log4j生成的自定义格式的。
通常的架构如下图：
使用mapreduce分析nginx日志
nginx默认的日志格式如下：
222.68.172.190--[18/Sep/2013:06:49:57+0000]"GET/images/my.jpgHTTP/1.1"20019939
remote_addr: 记录客户端的ip地址, 222.68.172.190
remote_user: 记录客户端用户名称, –
time_local: 记录访问时间与时区, [18/Sep/2013:06:49:57 +0000]
request: 记录请求的url与http协议, “GET /images/my.jpg HTTP/1.1″
status: 记录请求状态,成功是200, 200
body_bytes_sent: 记录发送给客户端文件主体内容大小, 19939
http_referer: 用来记录从那个页面链接访问过来的, “http://www.angularjs.cn/A00n”
http_user_agent: 记录客户浏览器的相关信息, “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36″
可以直接使用mapreduce来进行日志分析：
在hadoop中计算后定时导入到关系型数据库中进行展现。
也可以使用hive来代替mapreduce进行分析。
总结
web日志收集是每个互联网企业必须要处理的过程，当收集上来数据，并且通过适当的数据挖掘之后，会对整体网站的运营能力及网站的优化带来质的提升，真正的做到数据化分析和数据化运营。
via：cloudsky
End.
对于一个系统来说，监控、链路追踪、日志的这三者需求都是必然存在的，而有的时候我们会搞不清楚这三者相互之间是什么关系。我之前在做系统设计的时候也考虑过，是不是有必要引入那么多组件，毕竟如果这三者完全分开每一个一项的话，就有三个组件了（事实上就是：Prometheus+Grafana、Jaeger、ELK）。
因此想做个笔记尝试举例来梳理下。
外部链接：
Monitoring（监控）举例来说就是：定期体检。使用监控系统把需要关注的指标采集起来，形成报告，并对需要关注的异常数据进行分析形成告警。
特点是：
这也是Prometheus的架构做得非常简单的原因，Monitoring的需求并没有包含非常高的并发量和通讯量。反过来说：高并发、大数据量的需求并不适用于Monitoring这个点。
Tracing（链路追踪）举例来说就是：对某一项工作的定期汇报。某个工作开始做了A，制作A事件的报告，收集起来，然后这个工作还有B、C、D等条目，一个个处理，然后都汇总进报告，最终的结果就是一个Tracing。
特点是：
因为Tracing是针对某一个事件（一般来说就是一个API），而这个API可能会和很多组件进行沟通，后续的所有的组件沟通无论是内部还是外部的IO，都算作这个API调用的Tracing的一部分。可以想见在一个业务繁忙的系统中，API调用的数量已经是天文数字，而其衍生出来的Tracing记录更是不得了的量。其特点就是高频、巨量，一个API会衍生出大量的子调用。
也因此适合用来做Monitoring的系统就不一定适合做Tracing了，用Prometheus这样的系统来做Tracing肯定完蛋（Prometheus只有拉模式，全部都是HTTP请求，高并发直接挂掉）。一般来说Tracing系统都会在本地磁盘IO上做日志（最高效、也是最低的Cost），然后再通过本地Agent慢慢把文本日志数据发送到聚合服务器上，甚至可能在聚合服务器和本地的Agent之间还需要做消息队列，让聚合服务器慢慢消化巨量的消息。
Tracing在现在的业界是有标准的：OpenTracing，因此它不是很随意的日志/事件聚合，而是有格式要求的日志/事件聚合，这就是Tracing和Logging最大的不同。
Logging（日志）举例来说就是：废品回收站。各种各样的物品都会汇总进入到配品回收站里，然后经过分门别类归纳整理，成为各种可回收资源分别回收到商家那里。一般来说我们在大型系统中提到Logging说的都不是简单的日志，而是日志聚合系统。
从本质上来说，Monitoring和Tracing都是Logging，Logging是这三者中覆盖面最大的超集，而前两者则是其一部分的子集。Logging最麻烦的是，开发者也不会完全知道最后记录进入到日志系统里的一共会有哪些东西，只有在使用（检索）的时候才可能需要汇总查询总量中的一部分。
要在一般的Loggin系统中进行Monitoring也是可以的，直接把聚合进来的日志数据提取出来，定期形成数据报告，就是监控了。Tracing也是一样，只要聚合进了Logging系统，有了原始数据，后面要做都是可以做的。因此Logging系统最为通用，其特点和Tracing基本一致，也是需要处理高频并发和巨大的数据量。
这样一看就很清楚了，每个组件都有其存在的必要性：
日志是我们运维用来分析问题和处理问题的重要维护依据，但是Nginx的日志文件是非常庞大的，而且以文本格式显示导致Nginx的日志直接分析非常困难。有时候为了初步处理或紧急处理问题，我们也对直接打开Nginx的日志文件进行分析，这里我们就介绍如何对Nginx的默认日志格式进行分析和含义的解读。
在安装好Nginx后系统会默认给你开通access.log访问日志功能，这个配置文件在etc/nginx的文件夹下，打开配置文件后如下面是按行进行的默认格式配置。
log_format main ' $remote_addr - $remote_user [$time_local] "$request" '' $status $body_bytes_sent " $http_referer" '' "$http_user_agent" "$http_x_forwarded_for" ';
Nginx日志的配置项目：access_log /var/log/nginx/access.log main;
日志写入文本文件是一行行的，这里我们把一行日志，按3个字段进行分行进行分析。
61.135.165.19 - 这里是访问者的IP地址
- 这里是客户名称，但一般获取不到。
[17/Nov/2018:03:39:32 +0800] 这里是访问的时间
"GET /ask/0901/images/a13.jpg HTTP/1.0" 这个是这次记录的访问对象
200 返回的状态码
19916 这条记录访问对象的大小
"http://xx.xx.xx/ask/0901/index.htm?jh=haerbinlvyou-YD&gjc=7riyoudongbei&e_keywordid=%7Bkeywordid%7D" 这个是从什么入口访问的也就是来源。
"Mozilla/5.0 (Linux; U; Android 4.1; en-us; GT-N7100 Build/JRO03C;Baiduspider-ads)AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30" 这个是客户端浏览器的一些参数
"10.205.160.32" 这里是代理的地址，一般是没有的。
remote_addr 远程请求IP地址
remote_user 客户端用户的名称,没有时用-符合代替
time_local 本地时间戳
request 请求具体URI文件，例如网页中的JPG图片。
status http请求状态
body_bytes_sent 请求文件大小
http_refer 网页url跳转来源，源地址，可以伪造。例如一个HTML网页然后调用图片URI资源。
http_user_agent 用户终端浏览器UserAgent的相关信息
http_x_forwarded_for是HTTP的请求端真实的IP,只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项
其他非默认的选项
host 请求host地址
request_time 整个请求的总时间
upstream_addr 后台提供服务的地址(即转发处理的目标地址)
upstream_reponse_time请求时，upstream的响应时间
upstream_status upstream状态
通过如下方式达到日志切割：
# vi logcron.sh
log_dir="/data/logs/nginx"
date_dir=`date +%Y%m%d`
/bin/mkdir -p ${log_dir}/${date_dir} > /dev/null 2>&1
/bin/mv ${log_dir}/access.log ${log_dir}/${date_dir}/access.log
这里只需要定义一个cron，在每天晚上23:59:50执行这个脚本就可以了。
篇幅有限，关于nginx的access.log访问日志方面就介绍到这了，后面会分享更多关于devops和DBA方面内容，感兴趣的朋友可以关注下！
*请认真填写需求信息，我们会在24小时内与您取得联系。
