在群集日志分析基础篇中，老王为大家介绍了几种群集日志的位置和用途，例如事件管理器系统日志中可以告诉我们，当群集出现故障时，大体是什么原因导致的，给出一个方向，应用程序日志里面的FailoverClustering - Manager -Diagnostic日志可以帮助我们在事件发生后回溯执行过那些操作，FailoverClustering - Operational日志可以帮助我们了解群集资源，网络检测，安全的基本变化情况是否正常，还有群集管理器中的汇总日志，这些日志，通常情况下可以为我们指出一些明确的方向，告诉我们应该去看什么的问题，可以看见一些基本的资源变化信息和操作记录，帮助我们回溯一部分问题。
但是在一些情况下，可能出现的问题，在这些日志中并没有给出明确的解释，或者我们认为可能并不是事件日志里面所说的问题，我们仍需要更加详细的信息，这时候我们就可以去看群集诊断日志，什么是群集诊断日志，简单来说，群集诊断就是记录群集运行过程中的所有内部执行过程，你能想到的，资源上线下线迁移，运行状况检测，等等，几乎所有和群集运行有关的东西都会被记录在这个诊断日志中，2012时代开始默认情况可以在事件管理中看到，群集一边运行着，这个事件日志就会不断的更新增长
诊断日志和其它日志最大的不同就是，其它的群集相关日志也会记录群集的运行状况，资源变化，但是呈现在事件日志中都相对友好一些，基本上不会出现很多底层的语言，让我们看到基本上就可以看懂，而诊断日志则不同，在诊断日志中，会把群集中的一些核心组件也呈现出来，例如RHS,RCM,NetFT等核心组件的运作也会呈现出来，因此诊断日志也最为深入和详细，不论是对于群集做深入的排错，还是希望了解群集内部的运作原理，学会看诊断日志是最佳的选择。
在看诊断日志的时候，您可能会看到里面有很多群集核心组件的缩写，例如下图这些，初学者如果看不懂缩写的意思，可以复制下来，去网上搜索，然后记下来，这里老王挑选三个我认为比较主要的核心组件来和大家解释
RHS：中文 资源主机子系统，实际运作时会呈现成一个个的系统进程，这个组件干嘛的呢，它会根据Resource.dll里面定义的检测规则，以及我们定义的检测策略，去实时监控各种群集对象的运行状况，例如群集磁盘，群集IP地址，群集网络名称，应用程序，RHS实际检测的时候主要是依据当前已经加载的群集资源对象Resource.dll中两个参数来判断群集资源的存活与否状态，分别是looksalive check，is alive check
顾名思义looksalive check就是说，资源看起来是活着的，因此，在looksalive check过程中，通常情况下RHS会执行相对来说简单的检测操作，例如每隔3秒检测群集磁盘是否接受预留请求请求。如果通过looksalive check并不能有效的检测出资源是否存活，RHS还会尝试使用is alive check的方式进行具体的检测，相比较looksalive来说is alive则会从更加深入的角度去检测资源的存活状态，例如，is alive对于群集磁盘的检测会实际要求执行一个Dir命令，针对于SQL的检测，会实际执行一个查询来确认SQL群集资源的存活，因此lookalive的检测通常是基本化的，is alive检测通常是彻底的深入的，如果is alive的检测也失败，则RHS会报告资源的状态为失败，然后反馈给RCM组件进行进一步的资源处理
RHS，不论是对于任何的一个群集资源都会去尝试执行looksalive check，is alive check的检测操作，但是针对于不同的群集资源对象，检测的方法都会不同，针对于一部分群集默认资源，例如群集IP，群集资源，群集网络名称，RHS会通过加载默认的ClusRes.DLL去进行检测，不同的群集对象可能会用到不同的Resource.dll，开发人员可以把自己的程序与WSFC集成，编写自己程序的Resouce.dll融入到群集中
通常情况下，Resource.dll会起到以下两个主要作用，一个起到应用程序与群集之间的代理作用，当我们在故障群集管理器上面针对于群集对象联机，脱机，启用，禁用等操作时，实际上要求会直接发给资源对应的Resource.dll，再由Resource.dll去通知资源进行状态变化，因此如果要自己编写Resource.dll，首先要确保dll可以对相应的资源对象能够执行管理操作感知
另外Resource.dll还应该明确定义出，针对于特定资源类型的looksalive check和is alive check的检测方法，当is alive检测失败时候应该返回False参数，RHS收到False参数后会把资源标记为ClusterResourceFailed状态
RHS检测系统会根据所有的定义在群集中的Resource.dll里面的looksalive check和is alive check规则去检测群集资源的存活，通常情况下，如果要把自定义开发的应用与群集化，建议还是编写好Resource.dll，这样群集可以进行更加深入的检测，否则只能通过默认ClusRes.DLL去检测应用进程的基本状况
例如微软的SQL和Hyper-V群集化了之后，RHS都会通过它们自身单独的Resource.dll规则去进行检测，SQL Server群集化了之后会在群集中产生特定的SQL服务资源对象，同时也有自身特定的检测方式，RHS可以实际上发出一个真实的查询去is alive检测SQL的存活，Hyper-V群集化了之后也会调用自身特定的Resource.dll，实现可以通过我们定义的高级策略来检测来宾OS是否蓝屏，来宾OS里面的服务是否存活等等，当根据我们定义的检测策略和is alive检测，检测到资源当前不存活，过阵子会在RHS中标记资源为失败状态并报告给RCM，然后RCM看到RHS的标记则会根据资源的故障转移策略对资源尝试执行故障转移，重启启动等操作。
在之前2003时代，群集里面所有资源都在一个RHS进程下面托管着，这样子如果当一个资源对象因为检测失败，也会导致其它群集资源一起出现崩溃或重启的情况，因此在2008时代开始，微软将一部分群集自身的资源对象，例如，群集IP，群集名称，群集磁盘等可以被群集共享的资源放在一个单独的RHS进程中，我们在群集中创建的群集应用可以在单独的RHS进程中工作，这样一旦单个群集应用的RHS检测失败或进程出现问题，并不会影响到群集其它资源的工作，可以通过 cluster . res /prop命令来查看群集资源的所有属性
其中几个和RHS有关的关键参数
MonitorProcessID： 群集资源关联的RHS进程ID，可以通过查看这个参数来判断分析那些群集资源当前处在同一进程中
SeparateMonitor： 指示资源是否已被放置在单独的监视器中（0：否，1：是）
IsAlivePoleInterval： 默认值如图所示，表示它正在使用该特定资源类型的默认设置。
LooksAlivePollInterval： 默认值如图所示，表示它正在使用该特定资源类型的默认设置。
DeadlockTimeout： 默认设置，表示5分钟。
2008R2时代开始群集资源已经不是都在同一个RHS进程下面运作，针对于关键群集资源和群集应用实际上已经分开了不同的进程，来避免因为单个群集应用崩溃而导致其它群集资源崩溃的情况，但是默认情况下大部分群集资源仍在一个共享配置的监视器中运作，当RHS检测到一个群集资源失败或dll崩溃，则会把它放置在一个独立监视器中进行检测，彻底防止它影响到其它群集资源，在针对群集进行resource.dll的调试时，你也需要把SeparateMonitor值设置为1，否则会因为调试可能时会让共享监视器中其它资源失败。
#设置群集资源在单独的监视器中工作
(Get-ClusterResource “Resource Name”).SeparateMonitor = 1
例如在2008R2时代的虚拟化群集场景，默认情况下所有虚拟机都在同一个共享监视器下运行，一旦发生单个虚拟机发生资源死锁情况，可能会导致上面所有虚拟机都无法使用，因此可以把出现问题的虚拟机单独放在隔离监视器中运行，在实际使用中，对于隔离监视器的使用需要谨慎，因为有时候启用单独的隔离监视器就会出现单独的RHS进程，每个进程都要占用CPU和内存资源，因此需要在考虑服务器资源的情况下启用该高级功能。
RCM：Resource Control Manager ，资源控制管理器，顾名思义，这个组件是帮助我们去管理群集资源的，小到群集磁盘，大到一个群集组，都是通过RCM来帮助我们进行操作管理，可以说，RHS的功能主要是进行检测，发生问题，然后报告问题，而RCM则是实际做处理的，它会根据我们对于群集的操作指令，或者RHS检测到的结果，来进行资源的上线，离线，挂起尝试，故障切换等操作
RCM在执行操作的时候会考虑两点，一点是依赖关系，例如我们要联机上线一个群集组，群集组依赖于群集网络名称，网络名称又依赖于网络IP，因此RCM在处理我们这个联机请求的时候，会先去尝试构建出依赖关系，然后按照依赖关系逻辑逐步完成资源的联机，例如会先去尝试联机网络IP，网络IP联机之后尝试联机网络名称，最终依赖的资源都已经联机成果，才联机整个群集组。
另外一点，当RCM执行操作的时候，默认情况会使用资源定义的故障策略，以及高级策略来进行评估，最终做出合适的操作，例如，当RHS报告群集资源失败，RCM会按照故障转移策略每隔一段时间尝试联机挂起，经过一段时间无法挂起，会把资源置为失败状态，一段时间依然尝试重启启动该资源，如果始终无法重现启动成功，还会尝试把资源移动至其它节点进行尝试，如果都无法成功，会把资源置为失败状态。
由此可以看出，RCM组件主要的作用就是用于执行群集资源的管理操作，以及当群集资源，群集组出现故障时，评估依赖关系，故障策略，高级策略来对资源进行尝试，故障转移，状态确认。
NetFT：NetFT通常指的是Failover Cluster Virtual Adapter，当我们安装群集之后，在设备管理器里面显示隐藏设备可以看到有这样一个虚拟网络适配器，用ipconfig /all也可以看到这块网卡，但是并没有配置IP地址，这个群集虚拟网络适配器的主要作用是帮助我们构建一个群集中网络通信的高可用拓扑，例如，我们群集节点与节点之间要进行心跳检测，每隔一段时间，NetFT就会去帮我们重新构建这个拓扑，例如节点1和节点2，分别有两块网卡，一块专用于群集网络，一块用于群集网络+管理网络，那么当NetFT检测到如果专用的群集网络不能执行心跳检测，就会动态切换至另外一块网卡帮助我们进行心跳检测，NetFT的功能主要就是帮助管理员自动构建群集先有的通信拓扑，在最大程度的帮我们确保群集网络都可以正常的通信。
介绍了几个重要的理论后，我们来实际看下群集的诊断日志，到底长什么样子呢，默认情况下在2012时代诊断日志可以在事件管理器中看到，但是由于是实时增长的，看起来不太直观，我们很难在里面快速找到自己想要的信息，所以除了事件管理器，我们也可以通过Powershell命令Get-ClusterLog来生成群集的诊断日志，和事件管理器中的诊断日志不同，当我们使用Get-Clusterlog获取诊断群集日志时，不论是2008还是2012，都会把事件管理器，或ETL文件里面的诊断日志合并，然后筛检一部分，去掉无用的信息，只保留下来真正有用的诊断信息，形成一个log文件，便于管理员分析。
默认情况下如果我们直接在powershell中执行 Get-CluserLog就可以输出群集的诊断日志，打开之后就可以看到，但是，默认情况下2012R2里面诊断日志最大是300MB，一旦超过这个大小，则当日志再出现时，会覆盖掉之前日志，2008时代是100MB的限制
如果直接执行Get-ClusterLog，将会输出从群集开始到现在所有的Log，假设你的群集日志没有达到过300MB，没有发生过覆盖，会生成出所有的log，但是有时候生成这么大的日志会花费一些时间，而且Get-ClusterLog这条命令一旦执行下去，不单单是生成当前节点的诊断日志，也会去让其它节点也生成cluster.log到report目录，因此，使用Get-ClusterLog时有一些参数可以配合使用
#日志不多，可以直接运行Get-ClusterLog，会输出从集群建立到现在所有的
Get-ClusterLog
#只希望输出最后五分钟的日志
Get-Clusterlog -TimeSpan 5
#只希望指定的节点生成日志
Get-Clusterlog -Node Nodename
#如果在不指定路径的情况下，每次生成都会覆盖Report目录下已有的log，希望把各个节点的日志统一生成到一个目录下，可用利用Destination参数，在目录中会看到带有节点名字的各个log
Get-Clusterlog -Destination path
默认情况下cluster log的日志级别为3，通常情况下Level 3已经足够详细，如果在进行一些诊断的时候，你也可以通过 Set-ClusterLog -Level 5 设置级别为5进行高级诊断,需要注意如果设置Level 5 会导致短时间内日志持续飞速增长，建议诊断完成后及时恢复3
下面我们实际生成一下来看
生成完成的clusterlog默认会存在各节点的Report路径下
打开之后界面如下
这时候你可能需要一个自己用的习惯的日志分析用具
可以看到clusterlog似乎与我们其他地方看到的log不太一样，到底应该如何去理解呢，我们以一个例子来看
进程ID：资源所在的16位RHS进程ID
线程ID：资源16位RHS线程ID
GMT时间：事件发生时的GMT时间，精确至毫秒级别，最初考虑到群集节点可能会是分布在不同的时区，所以使用了GMT，实际看的时候，东半球需要加上8小时，在2016群集中新增了UseLocalTime 参数，生成clusterlog的时候，如果我们确认节点都在同一时区可以使用UseLocalTime生成本地时间戳记
日志级别：通常有INFO，ERR , WARN，DBG等状态，其中可以在日志分析中跟踪ERR关键字
资源类别：是有那个类别的资源类型和群集组件产生的日志
资源名称：具体的资源名称
说明：对于日志的详细说明
在Cluster.Log中有一些关键的属性，大家在使用Cluster.Log的时候可以主要关注下，并且设置在分析工具中追踪
OnlinePending：资源联机挂起
OfflinePending：资源正在进行离线
Offline：资源离线
ProcessingFailure：资源失败
通过直接在日志分析工具中搜索相应的关键字，就可以看到附近发生的上下文过程
下面我们以几个实际的案例来看
NetFT组件尝试帮助我们构建群集网络通信拓扑，可以看到这里详细的运作过程，发现只会在18网段，10，20网段之间进行尝试建立3343连接，因为我们设置了30 40网段为存储网络，不参与群集通信，因此构建拓扑时NetFT不会考虑这两个网络
08R2群集由于当前只有一个节点在运行，群集存储之前一直是失败状态，17:10这个时间节点，我将群集存储恢复联机上线，17:11时间节点，禁用ISCSI目标
生成clusterlog可以看到，10分的时候，RHS继续尝试检测群集磁盘1，发现群集资源1的RES资源已经正常挂载，检测也正常通过，因此RHS将把群集磁盘1状态变成联机的情况报告给RCM，RCM变更群集磁盘状态为联机
11分的时候RHS针对于群集磁盘1的Is Alive检测失败，判定该资源失败，并将失败的状态报告给RCM，RCM变更群集磁盘状态为失败，紧接着RCM会按照故障策略对群集磁盘尝试进行挂起重试操作，在一段时间内一直得到失败的结果，会标记群集磁盘为失败状态，然后隔一段时间后再尝试联机
第三个实例我们查看当我们执行LowerQuorumPriorityNodeID时群集内部发生的动作
时间节点1，群集四个节点，见证磁盘失效，当前群集随机调整去掉一个节点投票
时间节点2 ，使用LowerQuorumPriorityNodeID设置去掉HV04节点的投票
#使用命令输出所有群集节点最后五分钟的目录至统一文件夹
Get-ClusterLog -Destination \\iscsi\clusterlog -TimeSpan 5
打开HV03的日志可以看到，时间节点1，当检测到群集磁盘离线时，仲裁首先挑选去掉节点1的投票，时间节点2我们手动设置LowerQuorumPriorityNodeID为HV04，群集重新调整动态仲裁，去掉HV04的投票
第四个实例，我们可以看到，当NetFT构建群集内网络通信拓扑时，会考虑到网络会子网内还是跨子网，可以根据情况设计不同网络环境下的运行状况检测频率，NetFT会按照我们的定义来构建不同网络环境运作状况检测的拓扑。
最后一个实例，我们来模拟下当群集四个节点，坏掉三个节点，且最后两个节点时，投票节点忽然被断电，强制启动群集后的阻止仲裁情况
现在群集只剩下HV01节点被强制启动，我们这时启动下HV04节点
获取群集诊断日志，我们就看最近20分钟左右的，看看从群集关闭，强制仲裁，再到阻止仲裁到底发生了什么
Get-ClusterLog -Node HV01,HV04 -Destination \\iscsi\clusterlog -TimeSpan 20
我们先看HV01的日志
可以看到，时间节点一，HV01强制启动了群集服务
紧接着初始化各个群集组件，仲裁组件判定HV01已经初始化完毕，提升HV01的paxos标记为权威，这时应标记为FixQuorum状态，可以看到，虽然不在UI显示了，但是在后台运作的时候仍然会指出当前节点正在强制模式下运行
这时HV04试图上线，但会被阻止，HV01会收到群集环境内有新的加入请求，并告诉我它我是权威的节点，我的paxos标记最高，你应该以我的为准，加入我的分区，同步我的群集数据库
这时我们再来看看HV04的日志，因为HV04的ID为3，因此在日志中会看到Node 3 也就是HV04
时间节点1，Node3 尝试启动群集服务，但是启动之后被终止，
时间节点2 Node3指出，我的仲裁状态属于阻止状态，我试图加入，我应该先去和那个权威节点同步
时间节点3 Node3收到HV01的响应，以HV01为群集的权威方，按照HV01的paxos标记更新数据库
时间节点4 Node 3已经将群集数据库和HV01保持一致，再次加入群集，正常加入，关闭阻止仲裁模式，并且去掉了NeedsPrevent标记！
以上老王通过几个简单的实例，来为大家讲解了下应该如何去看cluster log，希望能够引起朋友们的兴趣，可以看到cluster log里面会真正涉及到很多群集底层组件的详细运作过程，如果你能够把这些底层组件的工作原理都搞清楚，老王相信不论是对于你进行排错，或者学习都会有一个不一样的境界。
在实际的群集排错中呢，老王认为主要还是通过不断的学习，实验，实战来巩固自己的知识经验，排错时手段占一部分，但是自身的知识和经验积累也要占很大一部分，例如老王遇到群集的问题，我的思路通常是先获取下群集节点投票，见证投票，看看见证资格当前是怎么样的，接着我会去看系统事件中筛选群集部分，看看网络和存储是否有报错，然后跟着自己的经验去分析判断问题
其实老王感觉对于一般的排错，事件管理器系统，应用程序日志中旳群集日志已经可以提供足够明确的信息，事实上微软在2008时代改变群集事件的时候就曾经有个愿景，希望可以让更多的管理员通过看事件管理器就能了解解决一部分问题，到了2012时代事件管理器中的日志确实也达到了微软的愿景，确实很多问题，日志已经提示的很明确
但是一旦遇到一些问题，事件管理器中给出的提示无法解决，这时我们仍需要直接看cluster log，来从群集的最底层去了解故障的彻底原因。
如果是需要进行一个综合性的排错，例如综合排查三个节点的群集错误和虚拟化错误，这时候你可以选择查看群集管理器中的群集事件，来进行一个综合性的排错
如果是需要进行群集的健康检查，看看还有那些最佳实践没有执行，可以执行群集验证报告，群集验证报告也会提供很多有用，底层的信息。