探索日志查看工具：面对庞大网站日志，如何高效分析及浏览方法

网站记录过大如何进行解析？记录过大如何进行查阅？

怎样进行网站记录分析？

一、何为网站记录？

1.网站记录是一类以log为后缀的文件，记录了各类原始数据，例如web服务器接收到的处理请求和运行时错误。

2.通过网站记录，可以明确知晓用户在何种IP、何时、何种操作系统、何种浏览器、何种解析设备下访问了网站的哪个页面，访问是否成功。

3.搜索引擎也属于网站用户的一类。我们今天的分享课程主要是针对服务器上类似搜索引擎的用户留下的记录进行分析。

为了便于阅读搜索引擎记录，我们需要了解不同搜索引擎爬虫的标识。以下是四个搜索引擎的标志：百度爬虫：Baiduspider搜狗：搜狗新闻爬虫360：360爬虫谷歌：Googlebot

二、如何理解网站记录

(以下为记录示例)www.cafehome.com

58.180.251.134--[2015年3月25日13时24分33秒0800]GET/m53256.html

HTTP/1.120012264Mozilla/5.0

(WindowsNT6.1)appleWebKit/537.36(KHTML，像壁虎一样)

chrome/35.0.1916.153Safari/537.36SE2。XMetaSr1.0

以下字段的解释：

通常，当日志文件较大时，需要结合shell和python来提取和分析数据。因此，读取网站记录中的字段有利于日常分析。这里就不详述了。感兴趣的读者可以继续深入了解。

大型网站通常可以使用上述方法进行记录分析。

一般的个人网站，或者企业网站，可以通过光年记录分析工具，与百度站长平台配合使用。

三、为何要进行网站记录分析？

我们先来了解一下SEO流量获取流程：抓取->索引->排名->点击->流量

因此，获得SEO流量的前提一定是有价值的页面被搜索引擎抓取。

因此，对于SEO运营来说，分析搜索引擎的网站记录是非常必要的：分析是否有抓取：解决一定的索引问题。发现异常：及时避免。比如有大量的异常页面，404等。抓取控制：让更多的优质内容被抓取，过滤无效。

Web分析的目标：让更多有价值的页面被抓取，你就有机会获得索引，从而有机会获得SEO流量。

四、如何进行网站记录分析

定期监控搜索引擎抓取量的变化，历史数据的横向和纵向对比可以发现异常情况。使用第三方站长平台，如百度站长平台，了解搜索引擎抓取频率的变化。借助光年记录分析工具，定期做数据记录，了解重要栏目和页面抓取量的变化。

举个例子：

老站点（建站1年，有人维护的网站）：Seo流量波动异常。

有两种情况：

了解外界：了解外界的前提是你平时有一定的网络基础。如果没有，也没关系。泡在2个地方——去搜索引擎站长平台或者加入搜索引擎站长群。比如像百度搜索引擎，有站长平台，也会相应建立站长QQ群。在人脉的基础上，可以直接了解外界——有没有类似的波动？这个前提要和你短期的SEO操作一起考虑，避免误判。无人脉，泡泡群，泡泡站长平台。通常如果搜索引擎算法升级，群内或者站长平台都会有相关的小道消息。如果是搜索引擎自身算法升级导致的流量波动，就必须根据新的算法做出相应的站内优化。比如百度冰桶3.0版本提出，将严厉打击百度移动搜索中打断用户完整搜索路径的调用行为。如果站点有以上情况，就需要有针对性的优化：无论是通过对接的APPLINK调用，还是网页本身调用的应用，还是普通的网页，都应该是可返回可关闭的。用户验证搜索结果的准确性，不需要下载应用程序或获得许可。

分析内部：

在分析内部之前，再抛一下这个公式：Seo流量=抓取量收录率(准确的说应该是索引率)首页率点击率。

。当抓取频率异常时，抓取量必然会减少。因此，排除外部因素，有必要对网站记录进行分析。如果你的站点是中文站点，并且是百度站长平台的VIP用户。那么，可以先使用第三方站长平台(比如百度)的“抓取频率”工具，了解搜索引擎的近期抓取频率、抓取时间、异常页面等。通常在这个工具的帮助下，我们可以对搜索引擎最近的抓取情况有一个初步的了解，也可以借助这个工具找到一些相应的解决方法。

这里，首先解释一下这个概念，以便于理解：

1.抓取频率：抓取频率是搜索引擎在单位时间内(天级)抓取网站服务器的总次数。如果搜索引擎对某个站点的抓取频率过高，很可能造成服务器不稳定，蜘蛛会根据网站内容更新频率、服务器压力等因素自动调整抓取频率。

2.抓取时间：是指搜索引擎每次抓取所花费的时间。影响抓取频率的可能原因有：

(1)如果抓取频率的上限被错误地调整和降低，将直接影响抓取量。抢量减少，指标量就少，流量也相应减少。

(2)运营层面：存在大量重复页面(案例一:自身网站存在大量重复内容。情况二:自己网站的内容大量收集互联网上已有的内容)。从搜索引擎的目标出发——搜索引擎想要抓取更多更好的页面，但是你的网站产生了大量的在线内容。为什么要在你的网站上浪费资源？另外，网站内容更新时间不长。建议通过定时、定期生产优质内容来解决这个问题。抓取时间越长，网站抓取越少。通常情况下，有可能服务器速度慢会导致抓取时间变长。还有一种可能是和网站本身的结构有关。太深的等级制度导致。

总结一下：

老网站如何进行网站记录分析(针对中文网站)：外部排除；

了解搜索引擎的最新算法是否有变化，同行是否有类似变化。

内在分析：

(1)使用工具：百度站长平台(非VIP账号，见下面介绍)

(2)分析方法：主要使用抓取频率分析工具进行分析，网站抓取频率、抓取时间、页面异常情况等数据变化。并与相关部门进行对接解决。

(2)分析方法：主要运用捕获频率分析工具展开探究，关注网站捕获频率、捕获时间、页面异常状况等数据变动。并同相关机构进行沟通处理。

五、运用光年日志分析软件

非百度VIP：

步骤：

1.下载网站日志（若是企业网站，可请运维部门的同事协助下载。若是个人站长，可在所购虚拟主机后台直接下载。文件格式为.日志）

2.开启光年日志分析软件，上传网站日志。

3.审视分析成果。主要包括以下几方面：

(1)常规分析：各类爬虫的总捕获量、总停留时间、总访问次数。

(2)目录分析：探究各类爬虫捕获各个目录的情况。通过此，我们能了解搜索引擎对某些重要栏目的捕获，以及捕获了哪些无效页面。

(3)页面分析：通过页面分析，能知晓哪些页面被频繁重复捕获，据此进行优化和调整。例如，一些网站的注册页面和登录页面，常常发现被捕获多次。当此类情况发生时，我们通常会屏蔽登录/注册页面。

(4)状态码有两种：爬虫状态码和用户状态码。反映主用户/爬虫访问页面时的页面状态。通过页面状态码，我们能了解页面状态，并做出相应调整，例如，当网站中存在大量404页面时。这需要进一步调查。例如，一些团购页面，团购到期后页面直接变成404，但死链列表未提交至百度站长平台，这样很容易导致捕获无效。

SQLServer数据库日志文件过大，如何清理？

缩小数据库一般情况下，SQL数据库的缩小并不能在很大程度上减小数据库大小，其主要作用是缩小日志大小，应当定期进行此操作以免数据库日志过大

1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点击MicrosoftSQLServer-->SQLServer组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称（如论坛数据库Forum）-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”，然后按确定保存

2、在当前数据库上点击右键，查看所有任务中的缩小数据库，一般里面的默认设置不用调整，直接点击确定

3、缩小数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据

互联网分析数据的条件？

第一阶段：数据搜集

假设在线业务大多都在你公司官网上进行，那么大部分线上营销、搜索营销和用户行为活动的相关数据，都可以通过：

网页日志文件搜集—你必须精通网页日志文件搜集数据的原理，并且知道哪些数据是可搜集的。网站日志文件可以"记录"所有用户在网站上加载的文件，因此你可以轻易地发现网页的哪些"部分"没有响应用户的请求。网站日志分析参考：网站日志分析。

网站分析—全球大部分网站都使用分析工具。网站分析工具一般具有图形界面，可以快速显示用户的数据趋势。所有数据可以以表格、文本文件甚至是PDF文件的形式下载到本地。

利用网站分析工具搜集用户数据前，需要安装基础设置来追踪数据。通常要插入一些JavaScript的追踪脚本或者在网站所有HTML页面插入一些1*1像素的脚本。如果你需要搜集的用户数据超出默认设置所搜集的用户数据，需在常规追踪脚本外安装高级追踪脚本。

网站运维工具使用iis日志分析工具分析iis日志

对于一个需要长期维护的网站来说，如何让网站长久稳定运行是件很有意义的事情。有些在开发阶段没有暴露的问题很有可能就在运维阶段出现了，这也是很正常的。还有些时候，我们希望不断地优化网站，让网站更快速的响应用户请求，这些事情都发生在开发之后的运维阶段。

与开发阶段不同的，运维阶段不可能让你去调试程序，发现各类问题，我们只能通过各种系统日志来分析网站的运行状况，对于部署在IIS上的网站来说，IIS日志提供了最有价值的信息，我们可以通过它来分析网站的响应情况，来判断网站是否有性能问题，或者存在哪些需要改进的地方。

IIS日志包含了哪些信息

我前面说到【IIS日志提供了最有价值的信息】，这些信息有哪些呢？看看这个截图吧：

这里面记录了：

1.请求发生在什么时刻，

2.哪个客户端IP访问了服务端IP的哪个端口，

3.客户端工具是什么类型，什么版本，

4.请求的URL以及查询字符串参数是什么，

5.请求的方式是GET还是POST，

6.请求的处理结果是什么样的：HTTP状态码，以及操作系统底层的状态码，

7.请求过程中，客户端上传了多少数据，服务端发送了多少数据，

8.请求总共占用服务器多长时间、等等。

这些信息在分析时有什么用途，我后面再说。先对它有个印象就可以了。

IIS日志的配置

默认情况下，IIS会产生日志文件，不过，还是有些参数值得我们关注。IIS的设置界面如下（本文以 IIS 8的界面为例）。

在IIS管理器中，选择某个网站，双击【日志】图标，请参考下图：

此时（主要部分）界面如下：

在截图中，日志的创建方式是每天产生一个新文件，按日期来生成文件名（这是默认值）。

说明：IIS使用UTC时间，所以我勾选了最下面的复选框，告诉IIS用本地时间来生成文件名。

点击【选择字段】按钮，将出现以下对话框：

注意：【发送的字段数】和【接收的字节数】默认是没有选择的。建议勾选它们。

至于其它字段，你可以根据需要来决定是否要勾选它们。

如何分析IIS日志

如果你按照我前面介绍的方法设置了IIS日志参数，那么IIS在处理请求后（的一段时间之后），会生成IIS日志。

若你依照我之前所述的步骤调整了IIS日志的相关参数，那么在IIS处理完请求后的某个时刻，便会生成IIS日志。

我们可在【日志界面】的右侧区域【操作】部分点击【浏览日志文件】迅速定位至IIS日志的初始目录，之后在目录中寻找对应的日志文件（默认情况下会根据应用程序池的序号来区分不同的目录）。

例如：我找到了所需的日志：

该文件充斥着大量的繁复字符，那么我该如何解析它呢？

有一个名为 Log Parser 的工具能够专门解析IIS日志，我们可以利用它来查看日志中的内容。

例如，我可以运行以下命令行（注意：为了不影响页面宽度，我将命令文本进行了换行）：

复制代码

代码如下:

"C:/Program Files/Log Parser 2.2/LogParser.exe"-i:IISW3C-o:DATAGRID

"SELECT c-ip,cs-method,s-port,cs-uri-stem,sc-status,sc-win32-status,

sc-bytes,cs-bytes,time-taken FROM u_ex130615.log"

现在就可以以表格的形式来查看IIS日志了：

说明：我不推荐使用这种方法来分析IIS日志，原因有两点：

1.速度慢：当日志文件较大时，使用它进行分析会比较耗时（尤其是需要进行多次统计时）。

2.不便：它支持的查询语法不够丰富，没有像SQL Server针对数据表查询那样全面。

推荐的IIS日志分析方法

尽管Log Parser支持将解析的IIS日志以表格形式呈现，但有时我们可能需要进行更细致的分析，可能需要以不同的方式【反复】进行查询。对于这种需求，如果每次查询都直接运行Log Parser，你会浪费很多时间。幸运的是，Log Parser支持将解析结果以多种格式导出（以下为帮助文档截图）：

在此，我建议选择输出格式为 SQL。

注意：这里的SQL并不是指SQLSERVER，而是指所有提供ODBC访问接口的数据库。

我可以使用以下命令将IIS日志导入到SQLSERVER中（注意：为了不影响页面宽度，我将命令文本进行了换行）：

复制代码

代码如下:

"C:/Program Files/Log Parser 2.2/logparser.exe"

"SELECT* FROM'D:/Temp/u_ex130615.log' to MyMVC_WebLog"-i:IISW3C-o:SQL

-oConnString:"Driver={SQL Server};server=localhost/sqlexpress;database=MyTestDb;Integrated Security=SSPI"

-createtable:ON

导入完成后，我们就可以使用熟悉的SQLSERVER进行各种查询和统计分析了，例如下面的查询：

复制代码

代码如下:

SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken

FROM dbo.MyMVC_WebLog

如果如下：

注意：

1. 在将IIS日志结果导出到SQLSERVER时，不符合标识符规范的字段名将被删除。例如：c-ip会变成 cip， s-port会变成 sport。

2. IIS日志中记录的时间是UTC时间，且将日期和时间分开，导出到SQLSERVER时，会生成两个字段：date, time。这两个字段看起来不太舒服，对吧？

我也很反感这个结果，下面来说说两种解决方法：

1. 在SQLSERVER中增加一列，然后将UTC时间换成本地时区的时间，T-SQL脚本如下：

复制代码

代码如下:

alter table MyMVC_WebLog add RequestTime datetime

go

update MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120)

+''+ convert(varchar(13),time,114))

2. 在导出IIS日志时，将时间转换过来，此时需要修改命令：

复制代码

代码如下:

"C:/Program Files/Log Parser 2.2/logparser.exe"

"SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date,'yyyy-MM-dd'), TO_STRING(time,'hh:mm:ss')),

'yyyy-MM-dd hh:mm:ss')) AS RequestTime,* FROM'D:/Temp/u_ex130615.log' to MyMVC_WebLog2"

-i:IISW3C-o:SQL

-oConnString:"Driver={SQL Server};server=localhost/sqlexpress;database=MyTestDb;Integrated Security=SSPI"

-createtable:ON

再看这三列：

复制代码

代码如下:

select RequestTime, date, time from MyMVC_WebLog2

这样处理后，你就可以直接删除date, time这两列了（你也可以在导出IIS日志时忽略它们，但要明确指出每个字段名）。

IIS日志中的UTC时间问题就讲解到这里，希望每个人都明白了~~~~~~~~~~~

IIS日志中的异常记录

IIS日志中记录了每个请求的信息，包括正常的响应请求和出现异常的请求。

这里所说的【异常】与.net framework中的异常没有关系。

对于一个ASP.NET程序来说，如果抛出一个未捕获异常，会记录到IIS日志中（500），但我所说的异常不仅限于此。

本文所说的异常可分为四个部分：

1.（ASP.NET）程序抛出的未捕获异常，导致服务器产生500的响应输出。

2. 404之类的请求资源不存在错误。

3.大于500的服务器错误，例如：502，503

4.系统错误或网络传输错误。

前三类异常可以用以下查询获取：

复制代码

代码如下:

select scStatus, count() AS count, sum(timetaken 1.0)/1000.0 AS sum_timetaken_second

from MyMVC_WebLog with(nolock)

group by scStatus

order by 3 desc

IIS日志中有一列：sc-win32-status，它记录了在处理请求过程中，发生的系统级别错误，例如网络传输错误。

正常情况下，0表示正常，出现非零值意味着出现了错误。我们可以这样统计这类错误

在常规情形下，0代表正常状态，若出现非零数值，则表明存在错误。对此类错误，我们可以这样进行统计：

代码如下：

sql

declare recCount bigint;

select recCount = count(*) from MyMVC_WebLog with(nolock);

select scWin32Status, count(*) AS count, (count(*) * 100.0 / recCount) AS [percent]

from MyMVC_WebLog with(nolock)

where scWin32Status <> 0

group by scWin32Status

order by 2 desc;

下表列出了常见的网络错误及其说明：

- scWin32Status 含义

- 64 客户端连接已终止（或中断）

- 121 传输超时

- 1236 本地网络中断

所有状态码的解释可通过以下命令获取：

D:/Tempnet helpmsg 64 指定的网络名不再可用。

关于scwin32status与scStatus，还需补充说明：它们之间无关联。

例如，请求该地址：

有可能scStatus=200，但scwin32status=64，这时表示ASP.NET已成功处理请求，但IIS在发送响应结果时，客户端的连接已断开。

另一种情况是：scStatus=500，但scwin32status=0，这时表示，在处理请求过程中发生了未捕获异常，但异常结果已成功发送给客户端。

再谈 scwin32status=64

记得以前看到scStatus=200，scwin32status=64这种情况时感到困惑，于是上网搜索，各种解释都有，有的甚至提到与网络爬虫有关。为了验证这些解释，我进行了一个试验。我编写了一个ashx文件，用它来模拟长时间的网络传输，代码如下：

```csharp

public class Test_IIS_time_taken : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

context.Response.ContentType = "text/plain";

System.Threading.Thread.Sleep(1000 * 2);

context.Response.Write(string.Format("{0},{1}

", "Start", DateTime.Now));

context.Response.Flush();

System.Threading.Thread.Sleep(1000 * 2);

    for (int i = 0; i < 20; i++)

    {
        context.Response.Write(string.Format("{0},{1}

", i, DateTime.Now));

context.Response.Flush();

System.Threading.Thread.Sleep(1000 * 1);

}

    context.Response.Write("End");

}

}

```

这段代码很简单，我不想过多解释，只想说一句：我用Thread.Sleep与Response.Flush这两个方法来模拟一个长时间的持续发送过程。

我们可以在浏览器中看到这样的输出（显示还没有完全结束时我截图了）

我把这个测试做了8次，只有2次是全部显示完成了，其余6次我提前关闭了浏览器窗口。

然后，我们再来看IIS日志的内容：

根据IIS日志并结合我的操作可以发现：

1. 当我提前关闭浏览器窗口时，就会看到scStatus=200，scwin32status=64

2. 如果请求内容全部显示完成，我就会看到scStatus=200，scwin32status=0

从这个试验我们还可以发现：timeTaken包含了网络传输时间。

根据这个试验的结果，你是否想过一个问题：

如果你的网站的IIS日志中出现了大量的scStatus=200，scwin32status=64，而且请求是由用户的浏览器发起的。

这是什么原因造成的呢？

我的【推测】是：用户在访问这个网站时已经不愿意再等待了，他们把浏览器窗口关掉了。

换句话说：可以从scwin32status=64的统计结果看出网站的响应速度是否能让用户满意。

寻找性能问题

IIS日志中有一列叫：timeTaken，在IIS的界面中显示了它的含义：所有时间。

这个所用时间的定义是：从服务端收到请求的第一个字节开始起，直到把所有响应内容发送出去为止的时间。

微软的网站有对这个字段做过说明：

知道了timeTaken的定义后，我们就可以利用它来分析一些请求的处理时间，即性能分析。

例如，我想查看最慢的20个页面的加载情况，可以这样查询：

sql

select top 20 csuristem, scstatus, scwin32status, scbytes, csbytes, timeTaken

from dbo.MyMVC_WebLog with(nolock)

where csUriStem like '/Pages/%'

order by timeTaken desc;

再或者我想再看看最慢的20个AJAX情况的响应情况，可以这样查询：

sql

select top 20 csuristem, scstatus, scwin32status, scbytes, csbytes, timeTaken

from dbo.MyMVC_WebLog with(nolock)

where csUriStem like '/ajax/%'

order by timeTaken desc;

总之，寻找性能问题的方法就是：在查询时选择timeTaken字段，并按其降序排序。

注意：scbytes, csbytes这两个字段也值得我们关注：

1. csbytes如果过大，我们就要分析一下是否是因为表单包含了过多的无用数据，是否可以将表单拆分。

csbytes变大还有一种可能：Cookie太大，但它会表现为很多请求的csbytes都偏大，因此容易区分。

2. scbytes如果过大，我们就要检查页面是否没有分页，或者可以考虑用按需加载的方式来实现。

典型的情况是：当大量使用ViewState时，这两个值都会变大。因此我们能通过IIS日志发现ViewState的滥用问题。

典型的状况是：在大量应用ViewState的情况下，这两个数值都会增加。因此，我们可以通过IIS日志察觉到ViewState的过度使用问题。

还有一种特殊状况是：上传下载文件也会使这两个数值增加，具体原因在此不做详述。

scbytes、csbytes，无论哪个数值过高，都会耗费网络传输时间，对用户而言，就需要更漫长的等待期。

一下子提及了三个指标，在查找性能问题时，究竟应以哪个为准？

我认为：应当优先考虑timeTaken，因为它的数值直接体现了用户的等待时长（不包括前端渲染时间）。

若timeTaken过大，有必要检查scbytes、csbytes是否也过大，

若后两者同样过大，那么优化的方向应是降低数据传输量，否则表明程序处理占用了过多时间，应考虑优化程序代码。

探寻可优化的目标

除了能从IIS日志中找出性能问题，还可以用它来探寻可优化的目标。

例如：

1.是否存在404错误？

2.是否存在大量304请求？

3.是否存在大量重复请求？

当发现404反馈时，我们应该分析引发404的原因：

1.是用户输入错误的URL地址吗？

2.还是开发者引用了不存在的资源文件？

如果是后者，就应该尽快移除无效的引用，因为404反馈也是一个页面反馈，而且它们也会消耗网络传输时间，尤其是这类请求无法缓存，它会持续出现，浪费网络资源。