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

q989

　　诊断日志记录的位置
　　====================
　　默认
　　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节点里的&quot;Source&quot;项相一致.
　　
　　Category
　　这个与Event Log的Application节点里的&quot;Category&quot;项相一致.
　　
　　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