SharePoint 2013 Troubleshooting——启用 Developer Dashboard

 

SharePoint 2010的管理员和开发者可能对SharePoint Developer Dashboard(开发人员仪表盘)很熟悉。在SharePoint 2013这个工具已经被大范围的改写了,在你的Troubleshooting(故障排查)工具包中他已经变得越来越可用了。SharePoint 2013的Developer Dashboard对2010的版本做了大幅度的提升,解决了某些性能问题。并且它具有独立的窗体来显示一切你想要的信息。当运行 Developer Dashboard,弹出的新窗体将加载位于/_layouts/15/devdash.aspx页面。

启用 Developer Dashboard

SharePoint 2013 Developer Dashboard无法在SharePoint Central Administration中激活。所以,最好的方法是用PowerShell,所以为了使用Developer Dashboard,打开SharePoint 2013 Management Shell and 输入以下命令:

如果在使用结束后想Disable Dashboard,只要将之前的命令$devdash.DisplayLevel="On"替换为$devdash.DisplayLevel="Off"即可。

SharePoint 2013 Developer Dashboard依赖于Usage and Health Data Collection Service Application。如果没有创建这个Service,请创建并且确保他是运行的,为了演示,我预先把已存在的Usage And Health Data Collection Service Application 删除掉,详细的PowerShell 命令行如下所示:

SharePoint 2013 Troubleshooting——启用 Developer Dashboard_第1张图片

当成功启用了Developer Dashboard,会在SharePoint Page右上角添加一个icon,就像一个"医疗设备",如下图所示:

Developer Dashboard并不是显示给全部用户,只显示给具有AddAndCustomizePages Permissions Level 权限的用户。这是有道理的,因为没有必要将这个按钮显示给那些并不关心页面用户。因为只有特定权限的用户才能看到。然而,不要忘记SharePoint中的用户经常会被提升到各种权限,所以他们就会看到这个按钮。所以为了避免让这些用户对这个Icon产生困惑,最好的方法是,只在Troubleshooting时激活Developer Dashboard

该变Developer Dashboard Permission

在一些场景下,默认的Developer Dashboard Permission(AddAndCustomizePages)可能权限太高或者太低了。当然,你也是可以改变它的。比如用以下的PowerShell命令可以使每个人都可以看到Developer Dashboard:

现在,对于所有的用户,不管他或者她是否对此WebSite有权限,都将可以看到Developer Dashboard Icon。但是,值得注意的是,Developer Dashboard提供了大量的信息,如果写的很烂的Web Parts或者Controls可能会暴露后端的用户名和密码。所以,最佳实践是,不要暴露Developer Dashboard给任何用户(只在Troubleshooting时启用)

利用Developer Dashboard实现故障排除

当你打开Developer Dashboard你可能注意到大部分的字段是空的。只有一个URL在Requests选项卡可用来被分析。当在Dashboard打开之后加载或者重新加载SharePoint Pages,URL将会出现在Request 选项卡里。点击这些可用的URL,将会显示大量信息,具体如下图所示:

SharePoint 2013 Troubleshooting——启用 Developer Dashboard_第2张图片

正如你所看到的,一些条目可能直接就可以被用来Troubleshooting和性能调优,比如Duration(持续时间)和Page CheckOut Level(页面签出级别)。对于SharePoint 2013,可能最常听到的抱怨是"你为何如此之慢",但是没有具体的定义"慢"到底是什么,是什么引起了SharePoint如此之慢。现在有了SharePoint Developer Dashboard,可以轻松的根据客观存在的数字来反映Page加载了多久。如果一张页面花费很长时间加载,你可以在Scope(范围)选显卡去查找原因,Scope选项卡展示了构建和展现Page所需要的所有步骤,并且也显示了每一步所花费的时间,如下所示:

SharePoint 2013 Troubleshooting——启用 Developer Dashboard_第3张图片

  • 当然,没有必要去逐步了解每个细节,但你可以快速的往下浏览是否存在异常值。所以当你在Troubleshooting一张显示很慢的页面,去分析这些执行步骤是一个很好的开始。另外,一张unpublished页面加载所花费的时间比published页面长,甚至可能抛出"Access Denied"错误,所以知道Page CheckOut Level也会帮助你分析故障。
  • 我们再来分析一下Server Info(服务器信息)选项卡,它包含了另一个有用的信息——Correlation ID(关联ID)。正如我们了解的那样,当SharePoint Page发生完全错误失败时,SharePoint提供一个Correlation ID在错误页面上。但是如果只是页面一部分错误,如Web Part,你可以在Developer Dashboard获得这Correlation ID来开始你的Troubleshooting。
  • 说到Troubleshooting时,Developer Dashboard还有另一个秘籍。ULS选项卡展示了属于当前页面的部分Trace Log,这使你避免了从大量文本文件中去挖取信息。所以,即使没有PowerShell和 ULS Viewer,我们也不是无计可施,详细信息,如下所示:

SharePoint 2013 Troubleshooting——启用 Developer Dashboard_第4张图片

  • 最后,Developer Dashboard需要一点额外的需求在SharePoint Farm上。如果你打开Developer Dashboard发现没有数据填充(即一张空页面),可能是没有足够的内存。默认情况下,当服务器在负载很重的情况下,你必须留至少5%的内存让Dveloper Dashboard去获得可用的结果。

小结

本文参考《Professional SharePoint 2013 Administration》Chapter 19 Troubleshooting。即兴翻译,不足之处,望多多包涵。

 

 

你可能感兴趣的:(SharePoint 2013 Troubleshooting——启用 Developer Dashboard)