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 命令行如下所示：
当成功启用了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，将会显示大量信息，具体如下图所示：
正如你所看到的，一些条目可能直接就可以被用来Troubleshooting和性能调优，比如Duration（持续时间）和Page CheckOut Level（页面签出级别）。对于SharePoint 2013，可能最常听到的抱怨是"你为何如此之慢"，但是没有具体的定义"慢"到底是什么，是什么引起了SharePoint如此之慢。现在有了SharePoint Developer Dashboard，可以轻松的根据客观存在的数字来反映Page加载了多久。如果一张页面花费很长时间加载，你可以在Scope（范围）选显卡去查找原因，Scope选项卡展示了构建和展现Page所需要的所有步骤，并且也显示了每一步所花费的时间，如下所示：
- 当然，没有必要去逐步了解每个细节，但你可以快速的往下浏览是否存在异常值。所以当你在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，我们也不是无计可施，详细信息，如下所示：
- 最后，Developer Dashboard需要一点额外的需求在SharePoint Farm上。如果你打开Developer Dashboard发现没有数据填充（即一张空页面），可能是没有足够的内存。默认情况下，当服务器在负载很重的情况下，你必须留至少5%的内存让Dveloper Dashboard去获得可用的结果。
小结
本文参考《Professional SharePoint 2013 Administration》Chapter 19 Troubleshooting。即兴翻译，不足之处，望多多包涵。
