- 浏览: 73117 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
简介
很多个人站长在搭建网站时使用nginx作为服务器,为了了解网站的访问情况,一般有两种手段:
使用CNZZ之类的方式,在前端页面插入js,用户访问的时候触发js,记录访问请求。
利用流计算、或离线统计分析nginx的access log,从日志中挖掘有用信息。
两种方式各有优缺点:
CNZZ使用起来比较简单,各种指标定义清楚。但这种方式只能记录页面的访问请求,像ajax之类的请求是无法记录的,还有爬虫信息也不会记录。
利用流计算、离线计算引擎可以支持个性化需求,但需要搭建一套环境,并且在实时性以及分析灵活性上比较难平衡。
两种手段相互补充,才能对网站的状况有更加深入的了解。
日志服务在查询基础上新推出来SQL支持实时日志分析功能,极大的降低了站长们分析access log的门槛,本文将详细介绍如何使用日志服务分析access log中的各种指标。
Nginx访问日志格式
一个典型的nginx访问日志配置:
log_format main '$remote_addr - $remote_user [$time_local] "$request" $http_host '
'$status $request_length $body_bytes_sent "$http_referer" '
'"$http_user_agent" $request_time';
access_log access.log main;
字段解释:
remote_addr : 客户端地址
remote_user : 客户端用户名
time_local : 服务器时间
request : 请求内容,包括方法名,地址,和http协议
http_host : 用户请求是使用的http地址
status : 返回的http 状态码
request_length : 请求大小
body_bytes_sent : 返回的大小
http_referer : 来源页
http_user_agent : 客户端名称
request_time : 整体请求延时
收集访问日志到日志服务
首先把日志收集到日志服务
请参考文档5分钟快速文档
把日志收集到日志服务后,设置每一列的类型:
index_attribute
注:其中request拆分城method 和uri两列
日志样例:
sample_log
分析访问日志
通常,对access log的访问需求有,查看网站的pv,uv,热点页面,热点方法,错误请求,客户端类型,来源页面等等。下文将逐个介绍各个指标的计算方法。
PV统计不仅可以一段时间总的PV,还可以按照小的时间段,查看每段时间的,比如每5分钟pv
统计代码
*|select from_unixtime( __time__- __time__% 300) as t,
count(1) as pv
group by __time__- __time__% 300
order by t limit 60
统计结果
pv
统计一小时内每5分钟的UV
统计代码:
*|select from_unixtime( __time__- __time__% 300) as t,
approx_distinct(remote_addr) as uv
group by __time__- __time__% 300
order by t limit 60
uv_5min
统计一小时内总的UV
统计代码:
*|select approx_distinct(remote_addr)
统计结果:
uv
最近一小时访问最多的10个页面
*|select url,count(1) as pv group by url order by pv desc limit 10
top10page
最近一小时各种请求方法的占比
*| select method, count(1) as pv group by method
method
最近一小时各种http状态码的占比
*| select status, count(1) as pv group by status
status
最近一小时各种浏览器的占比
*| select user_agent, count(1) as pv group by user_agent
user_agent
最近一小时referer来源于不同域名的占比
*|select url_extract_host(http_referer) ,count(1) group by url_extract_host(http_referer)
注:url_extract_host为从url中提取域名
referer
最近一小时用户访问不同域名的占比
*|select http_host ,count(1) group by http_host
host
一些高级功能
除了一些访问指标外,站长常常还需要对一些访问请求进行诊断,查看一下处理请求的延时如何,有哪些比较大的延时,哪些页面的延时比较大。
通过每5分钟的平均延时和最大延时, 对延时的情况有个总体的把握
*|select from_unixtime(__time__ -__time__% 300) as time,
avg(request_time) as avg_latency ,
max(request_time) as max_latency
group by __time__ -__time__% 300
limit 60
avg_max_latency
知道了最大延时之后,我们需要知道最大延时对应的请求页面是哪个,方便进一步优化页面响应。
*|select from_unixtime(__time__ - __time__% 60) ,
max_by(url,request_time)
group by __time__ - __time__%60
top_latency_req
从总体把握,我们需要知道网站的所有请求的延时的分布, 把延时分布在十个桶里边,看每个延时区间的请求个数
*|select numeric_histogram(10,request_time)
latency_histogram1
除了最大的延时,我们还需要知道最大的十个延时,对应的值是多少
*|select max(request_time,10)
top_10_latency
当我们知道了/0这个页面的访问延时最大,为了对/0页面进行调优,接下来需要统计/0这个页面的访问PV,UV,各种method次数,各种status次数,各种浏览器次数,平均延时,最大延时
url:"/0"|select count(1) as pv, approx_distinct(remote_addr) as uv, histogram(method) as method_pv,histogram(status) as status_pv, histogram(user_agent) as user_agent_pv, avg(request_time) as avg_latency, max(request_time) as max_latency
url0
url0method
url0useragent
url0status
同时,我们也可以限定只查看request_time 大于1000的请求的pv,uv,以及各个url的请求次数
request_time > 1000 |select count(1) as pv, approx_distinct(remote_addr) as uv, histogram(url) as url_pv
url_pv
很多个人站长在搭建网站时使用nginx作为服务器,为了了解网站的访问情况,一般有两种手段:
使用CNZZ之类的方式,在前端页面插入js,用户访问的时候触发js,记录访问请求。
利用流计算、或离线统计分析nginx的access log,从日志中挖掘有用信息。
两种方式各有优缺点:
CNZZ使用起来比较简单,各种指标定义清楚。但这种方式只能记录页面的访问请求,像ajax之类的请求是无法记录的,还有爬虫信息也不会记录。
利用流计算、离线计算引擎可以支持个性化需求,但需要搭建一套环境,并且在实时性以及分析灵活性上比较难平衡。
两种手段相互补充,才能对网站的状况有更加深入的了解。
日志服务在查询基础上新推出来SQL支持实时日志分析功能,极大的降低了站长们分析access log的门槛,本文将详细介绍如何使用日志服务分析access log中的各种指标。
Nginx访问日志格式
一个典型的nginx访问日志配置:
log_format main '$remote_addr - $remote_user [$time_local] "$request" $http_host '
'$status $request_length $body_bytes_sent "$http_referer" '
'"$http_user_agent" $request_time';
access_log access.log main;
字段解释:
remote_addr : 客户端地址
remote_user : 客户端用户名
time_local : 服务器时间
request : 请求内容,包括方法名,地址,和http协议
http_host : 用户请求是使用的http地址
status : 返回的http 状态码
request_length : 请求大小
body_bytes_sent : 返回的大小
http_referer : 来源页
http_user_agent : 客户端名称
request_time : 整体请求延时
收集访问日志到日志服务
首先把日志收集到日志服务
请参考文档5分钟快速文档
把日志收集到日志服务后,设置每一列的类型:
index_attribute
注:其中request拆分城method 和uri两列
日志样例:
sample_log
分析访问日志
通常,对access log的访问需求有,查看网站的pv,uv,热点页面,热点方法,错误请求,客户端类型,来源页面等等。下文将逐个介绍各个指标的计算方法。
PV统计不仅可以一段时间总的PV,还可以按照小的时间段,查看每段时间的,比如每5分钟pv
统计代码
*|select from_unixtime( __time__- __time__% 300) as t,
count(1) as pv
group by __time__- __time__% 300
order by t limit 60
统计结果
pv
统计一小时内每5分钟的UV
统计代码:
*|select from_unixtime( __time__- __time__% 300) as t,
approx_distinct(remote_addr) as uv
group by __time__- __time__% 300
order by t limit 60
uv_5min
统计一小时内总的UV
统计代码:
*|select approx_distinct(remote_addr)
统计结果:
uv
最近一小时访问最多的10个页面
*|select url,count(1) as pv group by url order by pv desc limit 10
top10page
最近一小时各种请求方法的占比
*| select method, count(1) as pv group by method
method
最近一小时各种http状态码的占比
*| select status, count(1) as pv group by status
status
最近一小时各种浏览器的占比
*| select user_agent, count(1) as pv group by user_agent
user_agent
最近一小时referer来源于不同域名的占比
*|select url_extract_host(http_referer) ,count(1) group by url_extract_host(http_referer)
注:url_extract_host为从url中提取域名
referer
最近一小时用户访问不同域名的占比
*|select http_host ,count(1) group by http_host
host
一些高级功能
除了一些访问指标外,站长常常还需要对一些访问请求进行诊断,查看一下处理请求的延时如何,有哪些比较大的延时,哪些页面的延时比较大。
通过每5分钟的平均延时和最大延时, 对延时的情况有个总体的把握
*|select from_unixtime(__time__ -__time__% 300) as time,
avg(request_time) as avg_latency ,
max(request_time) as max_latency
group by __time__ -__time__% 300
limit 60
avg_max_latency
知道了最大延时之后,我们需要知道最大延时对应的请求页面是哪个,方便进一步优化页面响应。
*|select from_unixtime(__time__ - __time__% 60) ,
max_by(url,request_time)
group by __time__ - __time__%60
top_latency_req
从总体把握,我们需要知道网站的所有请求的延时的分布, 把延时分布在十个桶里边,看每个延时区间的请求个数
*|select numeric_histogram(10,request_time)
latency_histogram1
除了最大的延时,我们还需要知道最大的十个延时,对应的值是多少
*|select max(request_time,10)
top_10_latency
当我们知道了/0这个页面的访问延时最大,为了对/0页面进行调优,接下来需要统计/0这个页面的访问PV,UV,各种method次数,各种status次数,各种浏览器次数,平均延时,最大延时
url:"/0"|select count(1) as pv, approx_distinct(remote_addr) as uv, histogram(method) as method_pv,histogram(status) as status_pv, histogram(user_agent) as user_agent_pv, avg(request_time) as avg_latency, max(request_time) as max_latency
url0
url0method
url0useragent
url0status
同时,我们也可以限定只查看request_time 大于1000的请求的pv,uv,以及各个url的请求次数
request_time > 1000 |select count(1) as pv, approx_distinct(remote_addr) as uv, histogram(url) as url_pv
url_pv
发表评论
-
Python基础语法-常量与变量
2017-11-23 16:44 0摘要: Python是一门强类型的动态语言。 字面常量,变 ... -
【2017DTC精彩重现】Oracle和MySQL DBA的进阶之路
2017-11-23 16:41 806摘要: 分享的初衷 这 ... -
积攒了这么多技术干货_总有一款适合你
2017-11-23 16:39 542摘要: 每天来云栖社区,总会有精彩的技术干货等着你。我们会不 ... -
小蓝退出舞台_谁能挺过O2O的第一个寒冬?
2017-11-23 16:29 620小蓝单车素来以“体验 ... -
展望云计算新时代数据库计算力的进化
2017-11-17 15:38 757从1970年关系数据库理 ... -
11月16日云栖精选夜读:阿里云 oss JavaScript客户端签名文件上传 vue2.0
2017-11-17 15:35 1092热点热议 阿里云 oss JavaScript客户端签名文 ... -
王坚:云计算之后_我为什么要做城市大脑?| 干货
2017-11-17 15:25 569近两年,由于人工智能 ... -
大数据等最核心的关键技术:32个算法
2017-07-27 16:27 555原文链接:http://click.ali ... -
玩转大数据_你需要了解这8种项目类型!
2017-07-27 16:20 487原文链接:http://click.aliyun.com/m/ ... -
大神带你分分钟超越最好结果——基于分布式CPU计算的Deeplearning4j迁移学习应用实例
2017-07-27 16:18 1160原文链接:http://click.ali ... -
5个步骤 & 7个提示 | 一份开启Kaggle竞赛征途的初学者指南
2017-07-27 16:13 1283原文链接:http://click.aliyun.com/m/ ... -
哇塞!原来404还能这么玩!
2017-07-17 11:29 471看起来很眼熟对吧!每个人上网浏览时,一般都是利用网址来找寻你需 ... -
阿里云PAI将神经机器翻译训练效率提升5倍
2017-07-13 17:35 657摘要: 近两年,神经机器翻译(NMT: Neural Mach ...
相关推荐
同时,Nginx的日志功能强大,可以定制日志格式,进行访问统计和分析。 6. **邮件代理服务**:Nginx不仅限于HTTP服务,通过SMTP模块也能实现邮件代理,用于发送和接收邮件。 7. **动态内容处理**:虽然Nginx主要...
他还使用MongoDB处理大规模终端Id信息更新,ElasticSearch+Kafka实现链路追踪和日志统计,TCC事务保障支付一致性,以及基于Redis的分布式锁方案。 这位Java架构师的综合能力和专业技能覆盖了系统设计、开发、优化、...
4. 基于分布式搜索系统ElasticSearch+Kafka自研的Trace进行链路追踪和日志统计 5. 分布式事务主要应用于交易中心的支付功能采用TCC事务,保障支付,风控,优惠券处理的一致性;支付网关回调采用可靠消息最终一致性...
4. **链路追踪与日志统计**:采用ElasticSearch+Kafka自研Trace系统。 5. **分布式事务处理**:在支付场景中应用TCC事务,确保支付、风控和优惠券处理一致性;使用可靠消息实现支付反馈的最终一致性;设计最大努力...
- **分布式搜索系统**:结合ElasticSearch和Kafka实现链路追踪和日志统计。 - **分布式事务**:在支付功能中采用TCC事务确保一致性,在支付网关回调中使用可靠消息最终一致性设计,确保扣款、积分、抽奖等操作的...
4. 评论与附件:用户可以在Bug报告下添加评论,提供额外信息,也可上传日志、截图等附件辅助问题分析。 5. 关联Bug:如果一个问题与其他问题有关联,可以建立关联关系,方便统一解决。 6. 查询与过滤:Bugzilla提供...