商业源码 如何查看Web服务器日志
利用Windows 2003服务器的远程维护功能，并通过IE浏览界面，就能对服务器的日志文件进行远程查看了，不过默认状态下，Windows 2003服务器的远程维护功能并没有开通，需要手工启动。
查看服务器日志文件的作用
网站服务器日志记录了web服务器接收处理请求以及运行时错误等各种原始信息。通 过对日志进行统计、分析、综合，就能有效地掌握服务器的运行状况，发现和排除错误原 因、了解客户访问分布等，更好的加强系统的维护和管理。
对于自己有服务器的朋友或是有条件可以看到服务器日志文件的朋友来说，无疑是了 解搜索引擎工作原理和搜索引擎对网页抓取频率的最佳途径。
通过这个文件，您可以了解什么搜索引擎、什么时间、抓取了哪些页面，以及可以知 道是主搜索蜘蛛还是从搜索蜘蛛抓取了您的网站等的信息。
访问原理
1、客户端（浏览器）和Web服务器建立TCP连接，连接建立以后，向Web服务器发出 访问请求（如：Get），根据HTTP协议该请求中包含了客户端的IP地址、浏览器类型、 请求的URL等一系列信息。
2、Web服务器收到请求后，将客户端要求的页面内容返回到客户端。如果出现错误，那么返回错误代码。
3、服务器端将访问信息和错误信息纪录到日志文件里。
下面我们就对本公司自己服务器其中的一个日志文件进行分析。由于文件比较长，所以我们只拿出典型的几种情况来说明。
#Software: Microsoft Internet Information Services 60
#Version: 10
#Date: 2006-05-12 03:56:30
#Fields:
date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port
cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2006-05-12
03:56:30 三圆三圆三圆 2182592169 GET / - 80 - 2201811898
Baiduspider+(+http://wwwbaiducom/search/spiderhtm) 403 14 5
/ 说明 /
上面定义了在2006年5月12日的3点56分30秒的时候，IP为2201811898的百度蜘蛛通过80端口（HTTP）访问了IP为2182592169的服务器的根目录，但被拒绝。
#Software: Microsoft Internet Information Services 60
#Version: 10
#Date: 2006-05-12 10:18:39
#Fields:
date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port
cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2006-05-12
10:33:36 三圆三圆三圆 2182592169 GET //indexhtm - 80 - 102576
Mozilla/40+(compatible;+MSIE+60;+Windows+NT+51;+SV1) 200 0 0
2006-05-12
10:33:36 三圆三圆三圆 2182592169 GET ///gif - 80 - 102576
Mozilla/40+(compatible;+MSIE+60;+Windows+NT+51;+SV1) 200 0 0
/ 说明 /
上面定义了在2006年5月12日的10点33分36秒的时候，IP为102576的用户正常访问了网站三圆三圆三圆中目录下的indexhtm页和/下的。gif。
#Software: Microsoft Internet Information Services 60
#Version: 10
#Date: 2006-05-12 13:17:46
#Fields:
date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port
cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2006-05-12
13:17:46 三圆三圆三圆 2182592169 GET /robotstxt - 80 - 662496672
Mozilla/50+(compatible;+Googlebot/21;++http://wwwgooglecom/bothtml)
404 0 2
2006-05-12 13:17:46 三圆三圆三圆 2182592169 GET / - 80 -
662496672
Mozilla/50+(compatible;+Googlebot/21;++http://wwwgooglecom/bothtml)
403 14 5
/ 说明 /
上面定义了在2006年5月12日的13点17分46秒的时候，IP为662496672的Google蜘蛛访问了robotstxt文件，但没有找到此文件，有访问了此网站的根目 录，但被拒绝。
现在也有很多日志分析工具，如果您的服务器流量很大的话，作者推荐使用分析工具来分析服务器日志。
场景描述：一个Web应用，前端设置了8个具有相同配置的Tomcat服务器，跑在Nginx反向代理后。每个Tomcat服务器运行在一个虚拟机上，要求能对Tomcat服务器的访问日志汇总存储并提供一定的分析能力。
需要的开源软件：Logstash和Elasticsearch。通过在各个虚拟机上安装Logstash收集Tomcat的日志数据，并存储在Elasticsearch中达到日志集中收集和分析的目的。
过程有两个步骤：
一、配置Tomcat的日志存储格式。编辑Tomcat目录下serverxml，填写如下内容
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- Access log processes all example
Documentation at: /docs/config/valvehtml
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="orgapachecatalinavalvesAccessLogValve" directory="logs" prefix="localhost_access_log" suffix="txt" pattern="%h %l %u %t "%r" %s %b %D "%{Referer}i" "%{User-Agent}i"" />
</Host>
directory表示访问日志存储在Tomcat的logs目录中。
prefix表示日志文件名以localhost_access_log开头。
suffix表示日志文件名以txt截尾。
pattern="%h %l %u %t "%r" %s %b %D "%{Referer}i" "%{User-Agent}i""
pattern这一句非常重要，用于表示日志的存储格式，一般为了方便会使用common或者combined，这两种自定义格式已经可以记录足够详细的信息，我这里使用了自定义方式。在这个pattern描述里：
%h表示访问来源的主机名或者IP地址；
%l表示客户端的标示，通常是 -；
%u表示得到了授权的访问者标示，通常都是 -；
%t表示日志事件的发生时间戳，用 [ 和 ] 括起来的；
"%r"表示用双引号"括起来的访问命令和链接，比如“GET /resource/logopng”；
%s表示HTTP状态码，如200和404等；
%b是服务器返回的数据量，以字节为单位；
%D表示服务器的响应时间，可以用于分析页面的执行效率；
"%{Referer}i"表示用两个双引号括起来的网址，用于告诉服务器这个访问请求是从哪个页面链接过来的；
"%{User-Agent}i"表示用双引号括起来的浏览器的HTTP代理信息，可以得到客户端使用了什么浏览器内核。
二、配置Logstash
1、在每个虚拟机上传logstash安装文件，安装logstash，以222版本为例
rpm -ivh logstash-222-1noarchrpm
2、创建Logstash的工作目录
mkdir /root/logstash_work_dir;mkdir /root/logstash_work_dir/config;mkdir /root/logstash_work_dir/logs;mkdir /root/logstash_work_dir/pid
其中/root/logstash_work_dir是工作目录，config目录用于存储Logstash的配置文件，logs目录用于存储Logstash的日志数据，pid目录用于存储Logstash的pid文件。
3、设置Logstash的运行脚本，修改/etc/initd/logstash中，替换其中的代码如下
LS_WORK_DIR=/root/logstash_work_dir
name=logstash
LS_USER=root
LS_GROUP=root
LS_HOME=/var/lib/logstash
LS_HEAP_SIZE="1g"
pidfile=${LS_WORK_DIR}/pid/$namepid
LS_LOG_DIR=${LS_WORK_DIR}/logs
LS_LOG_FILE=${LS_WORK_DIR}/logs/$namelog
LS_CONF_DIR=${LS_WORK_DIR}/config/root_tomcatconf
LS_OPEN_FILES=16384
LS_NICE=19
LS_OPTS=""
LS_USER和LS_GROUP指定了Logstash进程运行时的用户名和组，我这里使用了root，也可以使用其他权限更低的一般用户和组。
LS_CONF_DIR=${LS_WORK_DIR}/config/root_tomcatconf这一句最重要，指定了Logstash服务运行时的配置文件路径。
4、在/root/logstash_work_dir/config/目录中编写Logstash的配置文件root_tomcatconf，这是本系统最重要的文件。
input {
file {
path => "/root/tomcat/logs/localhost_access_logtxt"
sincedb_path => "/root/logstash_work_dir/config/sincedb_apache_access_logtxt"
type => "apache_access_log"
add_field => {"tomcatip" => "101281861"}
}
}
filter{
if [type] == "apache_access_log" {
grok{
match => { "message" => "%{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] \"(:%{WORD:verb} %{URIPATHPARAM:request}(: HTTP/%{NUMBER:httpversion})|-)\" %{NUMBER:response} (:%{NUMBER:bytes}|-) %{NUMBER:responsetime} \"(:%{URI:referrer}|-)\" %{QS:agent}" }
}
date{
match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
target => ["writetime"]
}
mutate {
convert => {
"response" => "integer"
"bytes" => "integer"
"responsetime" => "integer"
}
}
}
}
output {
if [type] == "apache_access_log" {
elasticsearch {
hosts => ["101281874:9200","101281875:9200","101281877:9200"]
index => "logstash-apacheaccesslog-%{+YYYYMMdd}"
}
}
}
Logstash的配置文件包括input、filter和output三部分。
input部分，使用了file插件。path指定了Logstash扫描的文件，每当有文件变化时，Logstash会读取文件尾部新增的数据；sincedb_path用于存储上一次文件读取的位置信息，如果这个文件不存在，则会从日志文件首部获取所有数据；type用于对这个配置插件做标识，当一个配置文件中有多个数据收集任务时尤其有用；add_field用于标识本机的ip地址，当数据存储在Elasticsearch后，用于区分来自哪一个Tomcat服务器。
filter插件，使用了grok、date和mutate三个插件。
grok插件用于解析Tomcat的访问日志，logstash自带了COMBINEDAPACHELOG等多个配置模式，但由于我使用了自定义的Tomcat日志配置，这里也自己编写；
date部分用于从日志中提取时间戳信息；
mutate中用convert将response、byte和responsetime三个解析得到的字符串转化为整数integer类型，这个步骤对于后续的分析比较重要，因为这样可以在Elasticsearch中做数值比较运算。
output插件，使用了elasticsearch插件，其中hosts指定了Elasticsearch集群的地址，本例子中指定了三个实例；index指定了数据存储在Elasticsearch中的索引名字，以logstash作为开头是因为Logstash自带的针对ELasticsearch的mapping映射中，对于所有的字符串类型都附带设置了一个raw不做解析的设置，这样便于在Elasticsearch中做底层的文本检索。
5、设置chkconfig的启动命令
chkconfig --add logstash
6、启动Logstash服务
service logstash start
一个合格的站长或者seoer必须要能看懂网站的服务器日志文件，这个日志记录了网站被搜索引擎爬取的痕迹，给站长提供了蜘蛛是否来访的有力佐证，站长朋友可以通过网站日志来分析搜索引擎蜘蛛的抓取情况，分析网站的是否存在收录异常问题。并且我们可以根据这个日志文件判断蜘蛛来访频率以及抓取规律，这将非常有利于我们做优化。另外，学习分析网站日志文件也是站长必须具备的能力，也是你从一个初级seo进阶到seo高手的必由之路。但是前提是要主机服务商开通日志统计功能，一般虚拟主机提供商都不会开通，你可以申请开通，或者自己到服务器管理后台开通这个日志统计功能，不过日志也会占用空间的，我们在看完日志文件后，可以隔段时间清理下日志文件。那么如何分析服务器日志文件呢听我娓娓道来。
搜索引擎抓取网站信息必会在服务器上留下信息，这个信息就在网站日志文件里。我们通过日志可以了解搜索引擎的访问情况，一般通过主机服务商开通日志功能，再通过FTP访问网站的根目录，在根目录下可以看到一个log或者weblog文件夹，这里面就是日志文件，我们把这个日志文件下载下来，用记事本(或浏览器)打开就可以看到网站日志的内容。那么到底这个日志里面隐藏了什么玄机呢其实日志文件就像飞机上的黑匣子。我们可以通过这个日志了解很多信息，那么到底这个日志给我们传递了什么内容呢
如果想要知道网站日志文件包含了什么内容，首先必须知道各搜索引擎的蜘蛛名称，比如百度的蜘蛛程序名称是baiduspider，Google的机器人程序名称是Google-Googlebot等等，我们在日志的内容里搜索上述的的蜘蛛名就可以知道哪个搜索引擎已经爬取过网站了，这里就留下了他们的蛛丝马迹。再者，必须能看懂常见的http状态码，最常见的HTTP状态码有200(页面抓取成功)、304(上次抓取的和这次抓取的没变化)，404(未找到页面，错误链接)500(服务器未响应，一般由服务器维护和出故障，网站打不开时出现的)，这些状态码是我们站长朋友必须能看懂的，服务器状态码的值是我们和蜘蛛交流的信号。知道了这些基本信息以后我们就可以根据网站日志进行分析了，一般来说我们只看百度和谷歌蜘蛛的爬行和抓取情况，当然有特殊需要的也可以对其他几个蜘蛛的爬行情况进行分析。网站日志中出现大量的谷歌蜘蛛和百度蜘蛛，说明搜索引擎蜘蛛时常来光顾你的网站。
说到分析日志文件，我们就不得不说分析日志文件的时机了，那么在什么情况下我们要去分析日志文件呢首先，新网站刚建立的时候，这个时候也是站长朋友最急切的时候，我们一般都会焦急的等待搜索引擎收录网站内容，经常会做的事情就是去百度或者Google用命令site:下网站域名看看是否被收录，这个时候，其实我们没必要频繁的查询网站是否被收录，要想知道搜索引擎是否关顾我们的网站。我们就可以借助网站日志文件来查看，怎么看看网站日志是否有搜索引擎的蜘蛛来网站抓取过，看返回的状态码是200还是其他，如果返回200说明抓取成功，如果返回404说明页面错误，或者页面不存在，就需要做301永久重定向或者302暂时重定向。一般抓取成功后被搜索引擎放出来的时间也会晚点，一般谷歌机器人放出来的比较快，最快可秒杀，但是百度反应就慢了，最快也要一周左右，不过11月份百度算法调整后，放出来的速度还是很快的。其次，当网站收录异常时我们要把正常收录的日志和异常的日志进行对比分析，找出问题所在，这样可以解决网站收录问题，也是对完整优化大有裨益的。第三，网站被搜索引擎K掉后，我们必须要观察网站日志文件来亡羊补牢，一般这种情况下，日志文件里只有很少的几个蜘蛛爬行了首页和robots，我们要找出被K的原因并改正，再提交给搜索引擎，接下来就可以通过观察日志来看蜘蛛是否正常来临，慢慢过一段时间，如果蜘蛛数量增加或者经常来临并且返回200状态吗，那么恭喜你，你的网站又活了，如果半年都没反应，那么建议放弃该域名重新再战了。
很多站长朋友不懂得如何利用网站日志文件，遇到网站收录问题就去提问别人，而不好好自检，这是作为站长或者seoer的悲哀。而且网上的很多软文都提到要做好日志文件的分析，但是那只是软文而已，说不定写文章的作者都没有去看日志文件。说到底，还是希望站长朋友一定不要忽略了网站日志文件，合理的利用好网站日志文件是一个站长或seoer必备的技能。再者说，看懂网站日志文件并不需要你有多么高深的编码知识，其实只要看得懂html代码和几个返回的状态码就可以了，一定不能懒，或者抱着侥幸心理去对待你的网站，这种心理会导致你输得很惨。如果你是一个小站长，或者你是一个seoer，如果你以前没有意识到网站日志文件的重要性，那么从看到我写的这篇文章开始要好好对待你的网站日志了。
log4jrootLogger=INFO,A1,R
# ConsoleAppender out
log4jappenderA1= org apachelog4jConsoleAppender
log4jappenderA1layout= org apachelog4jPatternLayout
log4jappenderA1layoutConversionPattern=%d{ yyyy/MM/ ddHH:mm:ss}%-5p%-10C {1} %m%n
# File out
//日志Appender修改为flume提供的Log4jAppender
log4jappenderR= org apache flumeclientslog4jappenderLog4jAppender
log4jappenderRFile=${ catalinahome}/logs/ ultraIDCPServerlog
//日志需要发送到的端口号，该端口要有ARVO类型的source在监听
log4jappenderRPort =44444
//日志需要发送到的主机ip，该主机运行着ARVO类型的source
log4jappenderRHostname = localhost
log4jappenderRMaxFileSize=102400KB
# log4jappenderRMaxBackupIndex=5
log4jappenderRlayout= org apachelog4jPatternLayout
log4jappenderRlayoutConversionPattern=%d{ yyyy/MM/ ddHH\: mm\: ss}%-5p%-10C {1} %m%n
log4jappenderRencoding=UTF-8
log4jloggercomultrapowerultracollectorwebserviceMessageIntercommunionInterfaceImpl=INFO, webservice
log4jappenderwebservice= org apachelog4jFileAppender
log4jappenderwebserviceFile=${ catalinahome}/logs/logsMsgIntercommunionInterfacelog
log4jappenderwebservicelayout= org apachelog4jPatternLayout
log4jappenderwebservicelayoutConversionPattern=%d{ yyyy/MM/ ddHH\: mm\: ss}%-5p[%t]%l%X-%m%n
log4jappenderwebserviceencoding=UTF-8
注：Log4jAppender继承自AppenderSkeleton，没有日志文件达到特定大小，转换到新的文件的功能
113 flume agent配置
agent1sources = source1
agent1sinks = sink1
agent1channels = channel1
# Describe/configure source1
agent1sourcessource1type = avro
agent1sourcessource1bind = 1921680141
agent1sourcessource1port = 44444
# Describe sink1
agent1sinkssink1type = FILE_ROLL
agent1sinkssink1sinkdirectory = /home/yubojie/flume/apache-flume-120/flume-out
# Use a channel which buffers events in memory
agent1channelschannel1type = memory
agent1channelschannel1capacity = 1000
agent1channelschannel1transactionCapactiy = 100
# Bind the source and sink to the channel
agent1sourcessource1channels = channel1
agent1sinkssink1channel = channel1
注：生成的文件的规则为每隔固定时间间隔生成一个新的文件，文件里面保存该时间段agent接收到的信息
12 分析
1 使用简便，工作量小。
2 用户应用程序使用log4j作为日志记录jar包，而且项目中使用的jar包要在log4j-1215版本以上，
3 应用系统必须将flume所需jar包引入到项目中。如下所示为所有必须jar包：可能会存在jar冲突，影响应用运行
4 能够提供可靠的数据传输，使用flume log4jAppender采集日志可以不在客户机上启动进程，而只通过修改logapppender直接把日志信息发送到采集机（参见图一），此种情况可以保证采集机接受到数据之后的数据可靠性，但是客户机与采集机连接失败时候数据会丢失。改进方案是在客户机上启动一个agent，这样可以保证客户机和采集机不能连通时，当能连通是日志也被采集上来，不会发送数据的丢失（参见图二），为了可靠性，需在客户机上启动进程
13 日志代码
Loginfo(“this message has DEBUG in it”);
14 采集到的数据样例
this message has DEBUG in it
this message has DEBUG in it
2 Exec source（放弃）
The problem with ExecSource and other asynchronous sources is that thesource can not guarantee that if there is a failure to put the event into theChannel the client knows about it In such cases, the data will be lost As afor instance, one of the most commonly requested features is thetail -F [file]-like use casewhere an application writes to a log file on disk and Flume tails the file,sending each line as an event While this is possible, there’s an obviousproblem; what happens if the channel fills up and Flume can’t send an eventFlume has no way of indicating to the application writing the log file that itneeds to retain the log or that the event hasn’t been sent, for some reason Ifthis doesn’t make sense, you need only know this: Your application can neverguarantee data has been received when using a unidirectional asynchronousinterface such as ExecSource! As an extension of this warning - and to becompletely clear - there is absolutely zero guarantee of event delivery whenusing this source You have been warned
注：即使是agent内部的可靠性都不能保证
21 使用说明
211 flume agent配置
# The configuration file needs to define the sources,
# the channels and the sinks
# Sources, channels and sinks are defined per agent,
# in this case called 'agent'
# exampleconf: A single-node Flume configuration
# Name the components on this agent
agent1sources = source1
agent1sinks = sink1
agent1channels = channel1
# Describe/configure source1
#agent1sourcessource1type = avro
agent1sourcessource1type = exec
agent1sourcessource1command = tail -f /home/yubojie/logs/ultraIDCPServerlog
#agent1sourcessource1bind = 1921680146
#agent1sourcessource1port = 44444
agent1sourcessource1interceptors = a
agent1sourcessource1interceptorsatype = orgapacheflumeinterceptorHostInterceptor$Builder
agent1sourcessource1interceptorsapreserveExisting = false
agent1sourcessource1interceptorsahostHeader = hostname
# Describe sink1
#agent1sinkssink1type = FILE_ROLL
#agent1sinkssink1sinkdirectory = /home/yubojie/flume/apache-flume-120/flume-out
agent1sinkssink1type = hdfs
agent1sinkssink1hdfspath = hdfs://localhost:9000/user/
agent1sinkssink1hdfsfileType = DataStream
# Use a channel which buffers events in memory
agent1channelschannel1type = memory
agent1channelschannel1capacity = 1000
agent1channelschannel1transactionCapactiy = 100
# Bind the source and sink to the channel
agent1sourcessource1channels = channel1
agent1sinkssink1channel = channel1
22 分析
1 tail方式采集日志需要宿主主机能够执行tail命令，应该是只有linux系统可以执行，不支持window系统日志采集
2 EXEC采用异步方式采集，会发生日志丢失，即使在节点内的数据也不能保证数据的完整
3 tail方式采集需要宿主操作系统支持tail命令，即原始的windows操作系统不支持tail命令采集
23 采集到的数据样例
2012/10/26 02:36:34 INFO LogTest this message has DEBUG 中文 in it
2012/10/26 02:40:12 INFO LogTest this message has DEBUG 中文 in it
24 日志代码
Loginfo(“this message has DEBUG 中文 in it”);
3 Syslog
Passing messages using syslogprotocol doesn't work well for longer messages The syslog appender forLog4j is hardcoded to linewrap around 1024 characters in order to comply withthe RFC I got a sample program logging to syslog, picking it up with asyslogUdp source, with a JSON layout (to avoid new-lines in stack traces) onlyto find that anything but the smallest stack trace line-wrapped anyway Ican't see a way to reliably reconstruct the stack trace once it is wrapped andsent through the flume chain（注：内容不确定是否12版本）
Syslog TCP需要指定eventsize，默认为2500
Syslog UDP为不可靠传输，数据传输过程中可能出现丢失数据的情况。
0条评论