本章主要介绍了代理缓存和服务器日志记录的一些情况,以及怎么解决代理缓存问题造成日志记录出现遗漏的问题!
为什么需要日志记录
几乎所有的服务器和代理都会记录下它们所处理的HTTP事务摘要。这么做出于一系列的原因:跟踪使用情况、安全性、计费、错误检验,等等。
哪些内容该记录
如果把访问的点点滴滴都一五一十的记录下来,是一个很没有意义的过程,暂且不说有的网站的事务量超大到难以计数的问题,把全部信息记录下来,这个日志文件可想而知得有多大。就日志记录对我们统计需求的作用而言,因为有的数据对我们来说意义不大,甚至可能看都不会看一眼,所以有选择性的记录一些内容变得很重要。通常,只记录事务的基本信息就行了。通常会记录下来的几个字段示例为:
- HTTP方法:主要记录事务用了什么方法
- 客户端和服务器的HTTP版本:给出客户端和服务器有关的提示,比如兼容性提示什么的
- 所请求资源的URL:记录Web站点某个资源的访问频率和受欢迎程度
- 响应的HTTP状态码:主要说明请求的执行情况成功与否
- 请求和响应报文的尺寸(包含所有的实体主体部分):记录大小
- 事务开始时的时间戳:记录发生时间
- Referer首部和User-Agent首部的值:主要记录从那个页面跳过来以及用户代理
日志格式
大部分http程序都支持管理者配置日志格式,以便于更好地利用已有工具对日志进行处理,从而方便汇总。
常用日志格式
字段 | 说明 |
---|---|
remotehost | 请求端机器的主机名或IP地址(如果没有配置服务器去执行反向DNS或无法查找请求段的主机名,就使用IP地址) |
username | 如果执行了ident查找,就是请求端已认证的用户名 |
auth-username | 如果进行了认证,就是请求端已认证的用户名 |
timestamp | 请求的日期和时间 |
request-line | 精确的HTTP请求行文本,GET /index.html HTTP/1.1 |
response-code | 响应中返回的HTTP状态码 |
response-size | 响应主体中的Content-Length,如果响应中没有返回主体,就记录0 |
组合日志格式
组合日志格式与常用日志格式很类似。实际上,它就是常用日志格式的精确镜像,只是添加了两个字段。User-Agent字段用于说明是哪个HTTP客户端应用程序在发起已被记录的请求,而Referer字段则提供了更多与请求端在何处找到这个URL的有关信息。以下为新加的组合日志格式字段:
字段 | 描述 |
---|---|
Referer | Referer首部的内容 |
User-Agent | User-Agent首部的内容 |
网景扩展日志格式
网景的格式是基于NCSA的常用日志格式的,但它扩展了该格式,以支持与代理和Web缓存这样的HTTP应用程序相关的字段。网景扩展日志格式的前7个字段与常用日志格式中的那些字段完全相同。以下为网景扩展日志格式新加的字段:
字段 | 描述 |
---|---|
proxy-response-code | 如果事务处理经历了某个代理,就是从服务器传往代理的HTTP响应码 |
proxy-response-size | 如果事务处理经历过了某个代理,就是发送给代理的服务器响应实体的Content-Length |
proxy-request-size | 如果事务处理经历过了某个代理,就是代理发往服务器的请求的所有主体或者实体的Content-Length |
client-request-hdr-size | 以字节为单位的客户端请求首部的长度 |
proxy-response-hdr-size | 如果事务处理经过了某个代理,就是以字节为单位的,发送给请求端的代理响应首部的长度 |
proxy-request-hdr-size | 如果事务处理经历过了某个代理,就是以字节为单位的,发送给服务器的代理请求首部的长度 |
server-response-hdr-size | 以字节为单位的,服务器响应首部的长度 |
proxy-timetamp | 如果事务处理经历过了某个代理,就是请求和响应经过代理传输所经过的时间(单位为秒) |
网景扩展2日志格式
另一种网景日志格式,网景扩展2日志格式采用了扩展日志格式,并添加了一些与HTTP代理和Web缓存应用程序有关的附加信息。这些附加字段有助于更好地描绘HTTP客户端和HTTP代理应用程序间的交互图景。以下为附加的网景扩展2日志格式字段:
字段 | 描述 |
---|---|
route | 代理用来向客户端发送请求的路径 |
client-finish-status-code | 客户端完成状态码。说明了发送给代理的客户端请求是成功完成(FIN)了,还是被打断了(INTR) |
proxy-finish-status-code | 代理完成状态码,说明代理发送给服务器的请求是成功完成(FIN)了,还是被打断了(INTR) |
cache-result-code | 缓存结果代码;说明缓存是如何响应请求的 |
Squid代理日志格式
字段 | 描述 |
---|---|
timestamp | 请求到达时的时间戳,是从格林尼治标准时间1970年1月1日开始的秒数 |
time-elapsed | 请求和响应通过代理传输所经历的时间(以毫秒为单位) |
host-ip | 客户端(请求端)主机的IP地址 |
result-code/status | result字段是Squid类型的,用来说明在此请求过程中代理采取了什么动作,code字段是代理发送客户端的HTTP响应代码 |
size | 代理响应客户端的字节长度,包括HTTP响应首部和主体 |
method | 客户端请求的HTTP方法 |
url | 客户端请求中的URL |
rfc931-ident | 客户端经过认证的用户名 |
hierarchy/from | 与网景格式中的route字段一样,hierarchy字段说明了代理向客户端发送请求时经由的路径。from字段说明了代理发起请求时的服务器名称 |
content-type | 代理响应实体的Content-Type |
命中率测量
缓存服务器位于客户端和服务器之间,用于防止服务器同时处理大量访问请求(这正是缓存的目的)。缓存要处理很多HTTP请求,并在不访问原始服务器的情况下满足它们的请求,服务器中没有客户端访问其内容的记录,导致日志文件中出现遗漏。由于日志数据会遗失,所以,内容提供者会对其最重要的页面进行缓存清除(cachebust)。缓存清除是指内容提供者有意将某些内容设置为无法缓存,这样,所有对此内容的请求都会被导向原始服务器。于是,原始服务器就可以记录下访问情况了。不使用缓存可能会生成更好的日志,但会减缓原始服务器和网络的请求速度,并增其负荷。
命中率测量协议是对HTTP的一种扩展,它为这个问题提供了一种解决方案。命中率测量协议要求缓存周期性地向原始服务器汇报缓存访问的统计数据。