apache、nginx、iis日志记录的各个字段内容与含义。

1、Apache访问日志格式详解   

访问日志access_log记录了所有对Web服务器的访问活动，下面是访问日志access_log中的一个标准记录

192.168.115.5 - - [01/Apr/2018:10:37:19 +0800] "GET / HTTP/1.1" 200 45

日志字段所代表的内容如下：

1.远程主机IP：表明访问网站的是谁 

2.空白(E-mail)：为了避免用户的邮箱被垃圾邮件骚扰，第二项就用“-”取代了

3.空白(登录名)：用于记录浏览者进行身份验证时提供的名字。

4.请求时间：用方括号包围，而且采用“公用日志格式”或者“标准英文格式”。 时间信息最后的“+0800”表示服务器所处时区位于UTC之后的8小时。

5.方法+资源+协议：服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”，即“方法 资源 协议”。

 METHOD: GET、POST、HEAD、……

RESOURCE: /、index.html、/default/index.php、……（请求的文件）

 PROTOCOL: HTTP+版本号

6.状态代码：请求是否成功，或者遇到了什么样的错误。大多数时候，这项值是200，它表示服务器已经成功地响应浏览器的请求，一切正常。

7.发送字节数：表示发送给客户端的总字节数。它告诉我们传输是否被打断（该数值是否和文件的大小相同）。把日志记录中的这些值加起来就可以得知服务器在一天、一周或者一月内发送了多少数据。

2、Apache错误日志格式详解

错误日志的文件名字是error_log（Windows平台是error.log）。错误日志的位置可以通过ErrorLog指令设置：ErrorLog logs/error.log ， 除非文件位置用根“/”开头，否则这个文件位置是相对于ServerRoot目录的相对路径。

错误日志无论在格式上还是在内容上都和访问日志不同。然而，错误日志和访问日志一样也提供丰富的信息，我们可以利用这些信息分析服务器的运行情况、哪里出现了问题。

错误日志记录了服务器运行期间遇到的各种错误，以及一些普通的诊断信息，比如服务器何时启动、何时关闭等。我们可以设置日志文件记录信息级别的高低，控制日志文件记录信息的数量和类型。这是通过LogLevel指令设置的，该指令默认设置的级别是error，即记录称得上错误的事件。有关该指令中允许设置的各种选项的完整清单，请参见http://www.apache.org/docs/mod/core.html#loglevel的Apache文档。 

我们在日志文件中见到的内容分属两类：文档错误和CGI错误。但是，错误日志中偶尔也会出现配置错误，另外还有前面提到的服务器启动和关闭信息。

（1）文档错误

文档错误和服务器应答中的400系列代码相对应，最常见的就是404错误——Document Not Found（文档没有找到）。除了404错误以外，用户身份验证错误也是一种常见的错误。  

       404错误在用户请求的资源（即URL）不存在时出现，它可能是由于用户输入的URL错误，或者由于服务器上原来存在的文档因故被删除或移动。  因此建议在不提供重定向或者其他补救措施的情况下，我们永远不应该移动或者删除Web网站的任何资源。  当用户不能打开服务器上的文档时，错误日志中出现的记录如下所示：           

[Fri Mar 30 14:45:09 2018] [error] [client 192.168.115.120] 

File does not exist:  /usr/local/apache/bugletdocs/Img/south-korea.gif

错误日志格式说明：

1.错误发生的日期和时间

2.错误的级别或严重性

3.导致错误的IP地址

4.错误信息本身。

可以看到，正如访问日志access_log文件一样，错误日志记录也分成多个项。错误记录的开头是日期/时间标记，注意它们的格式和access_log中日期/时间的格式不同。access_log中的格式被称为“标准英文格式”。 

       错误记录的第二项是当前记录的级别，它表明了问题的严重程度。这个级别信息可能是LogLevel指令的文档中所列出的任一级别（参见前面LogLevel的链接），error级别处于warn级别和crit级别之间。404属于error错误级别，这个级别表示确实遇到了问题，但服务器还可以运行。  

      错误记录的第三项表示用户发出请求时所用的IP地址。  

  记录的最后一项才是真正的错误信息。对于404错误，它还给出了完整路径指示服务器试图访问的文件。当我们料想某个文件应该在目标位置却出现了404错误时，这个信息是非常有用的。此时产生这种错误的原因往往是由于服务器配置错误、文件实际所处的虚拟主机和我们料想的不同，或者其他一些意料不到的情况。  

   由于用户身份验证问题而出现的错误记录如下所示：    

[Fri Mar 30 14:53:15 2018] [error] [client 192.168.115.120]

user rbowen@rcbowen.com : authentication failure for "/cgi-bin/hirecareers/company.cgi" : password mismatch  

 注意：由于文档错误是用户请求的直接结果，因此它们在访问日志中也会有相应的记录。  

（2）CGI错误

     错误日志最主要的用途或许是诊断行为异常的CGI程序。为了进一步分析和处理方便，CGI程序输出到STDERR（Standard Error，标准错误设备）的所有内容都将直接进入错误日志。这意味着，任何编写良好的CGI程序，如果出现了问题，错误日志就会告诉我们有关问题的详细信息。 

     然而，把CGI程序错误输出到错误日志也有它的缺点，错误日志中将出现许多没有标准格式的内容，这使得用错误日志自动分析程序从中分析出有用的信息变得相当困难。 

     下面是一个例子，它是调试Perl CGI代码时，错误日志中出现的一个错误记录： 

 [Web Mar 30 15:32:10 2018] [error] [client 192.168.115.120] Premature 

  end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

  Global symbol "$rv" requires explicit package name at 

  /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.

  Global symbol "�tails" requires explicit package name at 

  /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.

  Global symbol "$Config" requires explicit package name at 

  /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.

  Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi 

  aborted due to compilation errors.  

可以看到，CGI错误和前面的404错误格式相同，包含日期/时间、错误级别以及客户地址、错误信息。但这个CGI错误的错误信息有好几行，这往往会干扰一些错误日志分析软件的工作。 

     有了这个错误信息，即使是对Perl不太熟悉的人也能够找出许多有关错误的信息，例如至少可以方便地得知是哪几行代码出现了问题。Perl在报告程序错误方面的机制是相当完善的。当然，不同的编程语言输出到错误日志的信息会有所不同。 

     由于CGI程序运行环境的特殊性，如果没有错误日志的帮助，大多数CGI程序的错误都将很难解决。 

3.nginx日志记录解析

Nginx日志主要分为两种：访问日志和错误日志。日志开关在Nginx配置文件（/etc/nginx/nginx.conf）中设置，两种日志都可以选择性关闭，默认都是打开的。

访问日志

访问日志主要记录客户端访问Nginx的每一个请求，格式可以自定义。通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息。Nginx中访问日志相关指令主要有两条：

（1）.log_format

log_format用来设置日志格式，也就是日志文件中每条日志的格式，具体如下：

log_format name(格式名称) type(格式样式)

举例说明如下：

log_format main '$server_name $remote_addr - $remote_user [$time_local] "$request" '

'$status $uptream_status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for" '

'$ssl_protocol $ssl_cipher $upstream_addr $request_time $upstream_response_time';

每个样式的含义如下：

$server_name：虚拟主机名称。

$remote_addr：远程客户端的IP地址。

-：空白，用一个“-”占位符替代，历史原因导致还存在。

$remote_user：远程客户端用户名称，用于记录浏览者进行身份验证时提供的名字，如登录百度的用户名scq2099yt，如果没有登录就是空白。

[$time_local]：访问的时间与时区，比如18/Jul/2012:17:00:01 +0800，时间信息最后的"+0800"表示服务器所处时区位于UTC之后的8小时。

$request：请求的URI和HTTP协议，这是整个PV日志记录中最有用的信息，记录服务器收到一个什么样的请求

$status：记录请求返回的http状态码，比如成功是200。

$uptream_status：upstream状态，比如成功是200.

$upstream_addr:后端服务器的IP地址

$upstream_status：后端服务器返回的HTTP状态码

在server{}中添加 add_header backendIP $upstream_addr; add_header backendCode $upstream_status;

$body_bytes_sent：发送给客户端的文件主体内容的大小，比如899，可以将日志每条记录中的这个值累加起来以粗略估计服务器吞吐量。

$http_referer：记录从哪个页面链接访问过来的。 

$http_user_agent：客户端浏览器信息

$http_x_forwarded_for：客户端的真实ip，通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。

$ssl_protocol：SSL协议版本，比如TLSv1。

$ssl_cipher：交换数据中的算法，比如RC4-SHA。 

$upstream_addr：upstream的地址，即真正提供服务的主机地址。 

$request_time：整个请求的总时间。 

$upstream_response_time：请求过程中，upstream的响应时间。

访问日志中一个典型的记录如下：

192.168.1.102 - scq2099yt [18/Mar/2013:23:30:42 +0800] "GET /stats/awstats.pl?config=scq2099yt HTTP/1.1" 200 899 "http://192.168.1.1/pv/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows XXX; Maxthon)"

需要注意的是：log_format配置必须放在http内，否则会出现如下警告信息：

nginx: [warn] the "log_format" directive may be used only on "http" level in /etc/nginx/nginx.conf:97

（2）access_log

access_log指令用来指定日志文件的存放路径（包含日志文件名）、格式和缓存大小，具体如下：

access_log path(存放路径) [format(自定义日志格式名称) [buffer=size | off]]

举例说明如下：

access_log logs/access.log main;

如果想关闭日志，可以如下：

access_log off;

能够使用access_log指令的字段包括：http、server、location。

需要注意的是：Nginx进程设置的用户和组必须对日志路径有创建文件的权限，否则，会报错。

Nginx支持为每个location指定强大的日志记录。同样的连接可以在同一时间输出到不止一个的日志中。

 错误日志

错误日志主要记录客户端访问Nginx出错时的日志，格式不支持自定义。通过错误日志，你可以得到系统某个服务或server的性能瓶颈等。因此，将日志好好利用，你可以得到很多有价值的信息。错误日志由指令error_log来指定，具体格式如下：

error_log path(存放路径) level(日志等级)

path含义同access_log，level表示日志等级，具体如下：

[ debug | info | notice | warn | error | crit ]

从左至右，日志详细程度逐级递减，即debug最详细，crit最少。

举例说明如下：

error_log logs/error.log info;

需要注意的是：error_log off并不能关闭错误日志，而是会将错误日志记录到一个文件名为off的文件中。

正确的关闭错误日志记录功能的方法如下：

error_log /dev/null;

上面表示将存储日志的路径设置为“垃圾桶”。

参考链接：https://www.cnblogs.com/xulan0922/p/9219178.html

4.iis日志记录：

IIS 的WWW日志文件默认位置为 %systemroot%system32logfilesw3svcN，（例如： C:WINDOWSsystem32LogFilesW3SVC1）。一般服务器上日志的保存不使用默认路径，更换一个记录日志的路径，同时设置日志访问权限，只允许管理员和SYSTEM为完全控制的权限。

日志文件的名称格式是：ex+年份的末两位数字+月份+日期。

( 如2013年4月10日的WWW日志文件是ex130410.log ）

IIS日志字段

#Software: Microsoft Internet Information Services 7.5

#Version: 1.0

#Date: 2013-08-21 01:00:00

#Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken

日志的主体是一条一条的请求信息，请求信息的格式是由#Fields定义的，每个字段都有空格隔开。

若是重启进程，则这四行会再记录一次。

前缀	含义
s-	服务器操作。
c-	客户端操作。
cs-	客户端到服务器的操作。
sc-	服务器到客户端的操作。

各个字段的含义 

序号	字段	字段	格式及值	备注
1	date	日期	2013-08-21	活动发生的日期。
2	time	时间	01:16:11 +8小时	活动发生的时间。
3	s-sitename	服务名	W3SVC2	客户端所访问的该站点的 Internet 服务和实例的号码。
4	s-computername	服务器名	VMS01487	生成日志项的服务器名称。
5	s-ip	服务器IP	10.8.2.174	生成日志项的服务器的IP地址。
6	cs-method	方法	GET/POST	客户端试图执行的操作（例如 GET 方法）
7	cs-uri-stem	请求访问的页面	/TrainBooking/Search.aspx	/表示访问主页
8	cs-uri-query	访问的查询字符串	from=beijingxi&to=xinxiang2&day=1&number=&fromCn=%B1%B1%BE%A9&toCn=%D0%C2%CF%E7	客户端正在尝试执行的查询（如果有）。查询HTTP请求中问号（?）后的信息
9	s-port	服务器端口	80	客户端连接的服务器端口号。
10	cs-username		-	对于通过身份验证的用户，格式是“域用户名”；对于匿名用户，是一个连字符 (-)。
11	c-ip	客户端IP	120.71.108.114	访问服务器的客户端 IP 地址。（已过滤掉中间各种IP，是真实的客户端IP）
12	cs-version	协议版本	HTTP/1.1	客户端使用的协议（HTTP，FTP）版本。对于 HTTP，这将是 HTTP 1.0 或 HTTP 1.1。
13	cs(User-Agent)	用户代理	Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+QQDownload+718)	在客户端使用的浏览器。
14	cs(Cookie)	Cookie	Session=SmartLinkLanguage=zh&SmartLinkHost=&SmartLinkQuary=&SmartLinkKeyWord=&SmartLinkCode=U217664;+Union=OUID=baidu6a%7Ctrain%7C%7C%7C&AllianceID=4897&SID=217664;+rt=4_1;+__utma=1.1239641147.1377046635.1377046635.1377046635.1;+__utmb=1.1.10.1377046635;+__utmc=1;+__utmz=1.1377046635.1.1.utmcsr=baidu|utmccn=Baidu6a|utmcmd=cpc|utmctr=%E7%81%AB%E8%BD%A6%E7%A5%A8%E6%9F%A5%E8%AF%A2;+traceExt=campaign=CHNbaidu6a&adid=train;+_bfa=1.1377046635093.2zk2zs.1.1377046635093.1377046635093.1.1;+_bfs=1.1;+_bfp=469547008;+_bfi=p1=108001&p2=0&v1=1&v2=1;+ALLYESID4=06D7467F7F5F739E;+TrainLastSearch=%E9%93%9C%E4%BB%81%7Ctongren%7C%E6%B7%B1%E5%9C%B3%E8%A5%BF%7Cshenzhenxi%7C2013-08-21%7C;+ASP.NET_SessionId=kqc0qh3d3zmg42zlnruijtb1	发送或接收的 Cookie 的内容（如果有）
15	cs(Referer)	引用站点	http://trains.xxx.com/TrainBooking/RoundTrip.aspx?from=liuan&to=jiaxing&day=4&dayreturn=5&number=&fromCn=六安&toCn=嘉兴	用户访问的前一个站点。此站点提供到当前站点的链接。
16	cs-host	主机	trains.xxx.com （有时直接访问服务器IP，10.8.2.174）	显示主机头的内容。
17	sc-status	协议返回状态	200	以HTTP或FTP表示的操作的状态
18	sc-substatus	HTTP子协议的状态	0
19	sc-win32-status	Win32® 状态	0	用 Windows® 使用的术语表示的操作的状态。
20	sc-bytes	服务器发送的字节数	87682	服务器发送的字节数。
21	cs-bytes	服务器接受的字节数	1324	服务器接收的字节数。
22	time-taken	所用时间	187	操作花费的时间长短（亳秒）