之前博客中老王介绍了下WSFC中的仲裁，主要用于维持群集持续可用，出现宕机时应该处理的一些思路，在接下来的文章中老王将为大家介绍下WSFC中的日志分析，很多时候当出现问题了，或者需要进行性能优化，都需要通过看日志来进行分析判断，因此WSFC中掌握日志的分析更是重中之重，老王希望能够通过几篇文章把WSFC的日志分析功能授人以渔，介绍给更多的朋友们。
其实从2012时代开始，群集事件日志这方面，老王个人感觉已经优化了很多，说的基本上很清楚，对于ITpro来说已经可以很直观的从事件日志里面发现问题
首先我们先来看下系统日志，默认情况下，WSFC群集会将关于群集状态的，例如，节点，存储，网络，群集，仲裁状态信息，凡是出现关键，错误，警告，资源失败等一类的日志，都会显示在系统日志中，管理员直接在系统日志中筛选来自群集类别的日志就可以
筛选完成后打开就可以看到群集相关的日志，基本上绝大部分情况，在系统日志里面WSFC就会告诉你故障是怎么回事，是群集坏了，是存储脱机了，是网络分区了，还是没办法仲裁了，等等，因此，第一步可以先从看系统日志下手，理解里面群集日志说的内容，一些情况下可以直接按照系统日志中给出的方向去进行修复，最起码已经给出明确的方向范围
除了系统日志，在应用程序日志里面也有两个和群集有关的关键日志，一些排错的场景也许也会用到
FailoverClustering - Operational
FailoverClustering - Manager -Diagnostic
FailoverClustering - Operational 日志主要记载在群集在运行过程中的资源变化等信息，安全管理器，NetFT群集网络通信拓扑生成，运行状况检测情况，群集应用或者群集磁盘的状态变化，上线，离线或转移等等，都会被详细的记录在这个事件日志中，因此如果想要重现群集的一些问题，确认资源变化是否生效，都可以查看Operational日志得知
FailoverClustering - Manager -Diagnostic，这个日志会记录着群集管理员在打开群集管理器时每一个执行过的动作，做过的修改，都会在这个日志中记录，这在一些故障排除场景下会非常有用，可以帮助管理员们找到可能是由于做了哪些修改导致的问题
其它日志功能如下
FailoverClustering - Diagnostic ：群集诊断日志，2012R2中level 3详细级别，可以完整呈现出群集运作时后台发生的步骤，用于高级排查，原理学习。
FailoverClustering - Performance-CSV：针对于CSV的性能分析日志
FailoverClustering - Client：创建群集或添加节点时的详细分析日志
FailoverClustering - CSVFT -Diagnostic：2012新增，用于帮助管理员分析CSV在各节点挂载读取情况，Metadata的读取写入，IO重定向等日志
FailoverClustering - CSVFS -Operational：用于跟踪CSV挂载情况，及直接IO情况
FailoverClustering - Manager -Operational：主要记录针对于群集执行的管理操作，例如PS脚本是否正常下发执行，那些节点当前无法接受管理等管理操作记录
FailoverClustering - WMIProvider -Admin：用于当群集使用通用WMI程序或其它调用WMIProvider的群集程序时进行排错
除了群集本身的日志，2012开始也会有CAU更新单独的日志，在这里可以看到群集节点进行CAU时的状态，以及详细信息。
在老王看来，对于一般的企业管理员维护群集来讲，事件管理器中掌握会看群集系统日志，FailoverClustering - Operational，FailoverClustering - Manager -Diagnostic，就已经足够了，已经可以重现分析出绝大部分问题，但是对于一些痴迷于技术的爱好者们来讲可能还并不满足，他们希望深入至群集的最底层，或者一些高级排错的场景，希望能够完整的看到整个群集的最详细执行过程，那么你就需要去看Diagnostic日志，在FailoverClusterin - Diagnostic 诊断日志中会记载着几乎是最详细的群集执行过程，你会看到这个日志会不断的增长，后面老王会在进阶篇中专门讲解这种诊断日志。
在上文中老王是直接以2012R2为例，但其实对于群集日志来讲，从很久以前就已经有了，在Windows Server 2003时，那时候事件管理器还不像现在这么花花，所以那时候群集的日志，都是通过一个log来完成，群集一边执行着，那边日志就不断的增长，当出现问题时管理员直接连到C:\Windows\Cluster下的cluster.log进行排错
在2008时发生了一些变化，群集日志一部分改成了通过事件跟踪会话的形式进行收集
凡是被这种数据收集器采集的日志，你会发现，在事件管理器中都不能直接看
可以看到诊断日志，在2008开始就被分成了多个一个个的ETL文件，这种文件并不能直接打开
只能通过tracerpt命令转换为csv格式进行查看
因此，如果在2008时代，想看详细的群集诊断日志，事件管理器里面是不能看的，只有通过Cluster log /gen或者Get-Clusterlog命令查看，当执行这条命令之后，它会把所有诊断分析的ETL文件合并，然后去掉无用的元数据，保存成cluster.log文件供大家查看，因此老王认为2008时代比起2012时代的群集日志还是操作上还要差一些
到了2012时代开始，可以看到诊断日志已经从数据收集器中独立出来，单独有自己的事件单元，可以直接在事件管理器中看了
至此主要介绍群集日志在事件管理器的查看分析，老王认为学习群集日志分析，可以先从事件管理器入手，先学会看群集系统日志，FailOverClustering - Operational，FailoverClustering - Manager -Diagnostic这三个日志，然后用到时再看其它的，在这个部分老王对于诊断日志只是一带而过，因为打算进阶篇详细讲，事实上老王也建议大家先学会看基本的这个三个日志，最后再去看诊断日志，因为诊断日志中涉及到的群集底层知识较多，如果对群集并不是了解很深入可能看起来会有点吃力，事件管理器现在清晰明了，是个不错的入手方向。
除了事件管理器，群集还提供了一些直观的报告，在C:\Windows\Cluster\Report目录下，可以看到有验证报告，添加节点的报告，创建群集的报告，群集仲裁配置报告，等等，这些MHTML的文档都是群集已经帮我们设计好了的，打开之后都会有很友好的界面，不论是管理员看或是给经理看都很直观
其中群集验证报告我们可以把它理解为一个群集的私人医生，当创建群集的时候，强烈建议运行一次群集验证报告，它会帮助我们从系统配置，网络，存储等多个角度来诊断出一份详细的报告，当前环境是否适合创建群集，针对于不适合的地方会给出错误提示，也会使用内置的最佳实践来提示那些是应该改进的
除了群集创建时应该运行群集验证报告，在向群集变更网络，存储环境后也建议运行下群集验证，它会帮助我们分析模拟变更后的环境是否会影响群集的正常运行
如果在群集已经跑了应用的话，运行群集验证报告也会帮助我们去验证模拟群集应用，这里需要注意的一点是，当运行群集验证报告的时候，存储一栏要谨慎勾选，一旦群集验证报告勾选了存储，那么验证过程会尝试离线再上线群集磁盘，可能会导致应用的宕机，可以选择安排在合适的时间做，或者取消勾选存储即可。
报告目录这里面的MHTML报告，主要是当群集发生变化，或者我们触发一个报告时，我们提供一个直观的报告展示界面，但是当管理员要进行详细的排错时，有时仍需要看文件夹中的ValidateStorage日志，它会比MHTML的信息更加详细。
对于想要学习群集日志分析的朋友来说，第二个步骤可以选择掌握群集验证报告，和目录下的其它报告，起码先学会看懂报告，理解群集验证报告，会帮助你快速的了解，群集创建时发生的步骤，以及群集在运行时应该遵守的要求
第三个步骤，即掌握群集管理器中事件查询的用法
打开群集管理器，我们可以看到首页会提示当前最近的群集事件有2个关键，30个错误，3个警告，那么这些事件是在哪里来的呢？答案其实也是从事件管理器来的，只不过群集调用了事件管理器，使用自己的GUI做了一个查询显示
点击事件的链接，可以看到跳转进入了一个群集事件的界面，这个界面和我们事件管理器里面看到的差不多
但实际上，群集管理器里面的事件还是和普通事件管理器中的事件有点区别，设想一下，我们做了群集，那么肯定是希望能够站在一个整体的角度，来看群集的状态，默认情况下事件管理器所展示的只是单台
因此，群集管理器中做了优化，我们在群集事件中看到的日志，实际上是群集搜集了群集中所有群集节点，而呈现出来的日志
打开群集事件界面下的查询可以看到，当前日志来源是收集了群集所有节点中的，群集相关事件的关键，错误，警告部分，并且默认是查询24小时内的 ，这个设计的就很好，帮助管理员在一个群集事件的界面下就可以看到所有节点的日志
除了默认收集所有节点中的系统群集日志，我们也可以手动选择，希望让群集收集的各节点日志
例如，如果我们是一个Hyper-V集群，我们也可以选择上Hyper-V的相关日志，当进行一个虚拟化集群的排错时，我们不仅可以在群集事件中集中看到群集相关的日志，也可以集中看到Hyper-V的报错日志
这里需要注意的一点是，由于这个查询是在所有节点做，因此建议，除了群集本身的日志外，不要选择过多其他的日志，可以选择单独的一项两项，例如选择SQL的，或者Hyper-V的，这里的关键是我们要在排错的过程中，整体的，精确的来判断一个问题的故障点，如果这里收集的来源过多就失去了意义
我们目前是在群集事件中查看群集整体的日志情况，如果只是单一的群集应用程序出现问题，我们也可以点击单个的应用程序，在旁边选择 显示关键事件 就可以看到，关于当前应用的，在所有群集节点聚合起来的关键错误信息
如果是群集磁盘，也可以通过显示关键信息的方式，来获取针对于群集磁盘的，在各个节点汇集起来的关键错误信息
因此我们可以看到，WSFC内置已经帮助我们实现了群集节点事件汇总分析的功能，我们可以在整体的群集事件上面看所有群集节点的日志，WSFC也帮我帮助我们在具体的群集应用，群集磁盘上面内置了这项功能，针对于单独的应用或磁盘进行分析，也可以通过这种简单的方式来获取所有节点上面的日志。
至此，WSFC日志分析基础篇结束，在这一篇中老王主要为大家介绍了WSFC日志分析相对来说基础一点的三个地方，分别是事件管理器，群集报告目录，群集管理器事件，对于群集日志分析没有头绪的朋友可以先从这三个地方看起，仔细看懂里面的内容，学会利用它们，相信对提高您的日志分析能力会有所帮助
本文转自 老收藏家 51CTO博客，原文链接:http://blog.51cto.com/wzde2012/1953875
