When the going get’s tough the tough get going. But that doesn’t mean we don’t like and edge or won’t take advantage of tools and features that make our job easier.
In Windows Server 2016 Failover clustering Microsoft added some features to do just that when it comes to troubleshooting.
This is what Get-CusterLog does for you: it writes the FailoverClustering/Diagnostics events to a cluster.log file on every member node of that cluster. Collecting them all form there is tedious so they gave us the –destination parameter to set a common target folder on the host where we run the command.
So unless you get paid by the hour you’d normally you’d run Get-ClusterLog with the –Destination parameter so all the cluster logs from all cluster members are dumped into the destination folder for your. But in Windows Server 2016 they went the extra mile. More often than not other event logs are asked and needed. So a great improvement here is that this command now dumps all the relevant other channels into the cluster.log files generated and separates them out via a “header” [===LOGINQUESTION ===]
We now find following logs included:
[=== Microsoft-Windows-ClusterAwareUpdating-Management/Admin logs ===]
[=== Microsoft-Windows-ClusterAwareUpdating/Admin logs ===]
[=== Microsoft-Windows-FailoverClustering/DiagnosticVerbose ===]
[=== System ===]
This saves a lot of time as more often than not those are asked for and needed to troubleshoot. Note the DiagnosticVerbose log. This is a permanent parallel event channel that logs the verbose information. This avoids the overhead of having to set the logging level of the normal Diagnostic log to verbose and trying to reproduce the issue. Pretty cool, the info is there and it doesn’t cause the standard logging to roll over faster as that logs at the default level.
We also get the cluster objects listed in the log now to help with diagnosing issues.
[=== Resources ===]
[=== Groups ===]
[=== Resource Types ===]
[=== Nodes ===]
[=== Networks ===]
[=== Network Interfaces ===]
[=== Volume ===]
[=== Volume Logs ===]
Another improvement is that the log now indicates the offset against UTC or allows you to specify the –UseLocalTime parameter to get you the log in the time settings of the server. Both these options can be handy correlating events.
I’m happy with these efforts to gather the information needed to diagnose an issue easier and faster. It’s not about perfection but making progress and that what’s happening.