SharePoint中的诊断日志记录(也就是ULS)

诊断日志记录的位置

====================

默认

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

如果修改了, 除了管理中心, 还可以在注册表中查看位置:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS

 

日志记录的文件名格式

====================

<servername>-<YearMonthDay-time>.log

 

确定日志所监视的时间范围的技巧

====================

从ULS Log的文件名可以看出该文件被创建的时间点, 再看一下该文件的Date Mofidied属性, 就可以确定该文件所监视的最后的时间点.

如果你还知道你所感兴趣的问题发生的时间, 你就可以通过上面的知识点来找到相应的LOG文件来查找原因了.

 

陈列, 修改 日志记录等级的命令

====================

stsadm.exe -o listlogginglevels [-showhidden]

 

stsadm.exe -o setlogginglevel   [-category < [CategoryName | Manager:CategoryName [;...]] ] {-default | -tracelevel < trace level setting> [-windowslogginglevel] <Windows event log level setting>}

 

ULS日志的格式说明

===================

Timestamp

与Event Log中的“TimeGenerated” 项是等同的

 

Process

被记录的活动的进程镜像名称, 后面跟随的是进程的ID (PID). 有趣的是, IIS 工作者进程也会记录他们的动作, 他们都会在w3wp.exe之下进行记录.

 

TID

线程ID

 

Area

这个与Event Log的Application节点里的"Source"项相一致.

 

Category

这个与Event Log的Application节点里的"Category"项相一致.

 

EventID

一个独一无二的事件IDA unique internal Event ID, 可能与源代码有对应关系.

 

Level

该条记录的详细程度的等级

 

Message

具体的记录信息

 

Correlation

这里有时会带有一个链接, 指向另一个记录了的事件记录条目

 

Tracing Service lost trace events

================

如果遇到这样的日志文件, 不用着急, 重启一下Windows SharePoint Tracing Service即可.

 

如何强制SharePoint创建一个新的ULS Log?

===============

SharePoint 2007中, 我们需要重启Windows SharePoint Services Tracing服务.

可以运行如下的命令行:

net stop SPTrace & net start SPTrace

 

SharePoint 2010 中创建一个新的ULS log, 有两种方式

我们可以使用MOSS 2007中的重启SPTrace的方法.

net stop SPTraceV4 & net start SPTraceV4

也可以使用PowerShell命令

Add-PSSnapin Microsoft.SharePoint.PowerShell

ErrorAction “SilentlyContinue”

New-SPLogFile.

 

SharePoint Server 2007 Diagnostic Logging中所有的Categories

http://www.cnblogs.com/awpatp/archive/2010/02/19/1669378.html