本地Azure Service Fabric集群升级失败且无明显错误

一、获取详细升级日志 #

本地集群的升级相关日志主要集中在以下几个位置，直接去这些地方找细节：

• Service Fabric核心日志：每个节点的 C:\ProgramData\SF\Log\Traces 目录下，重点看这两个文件：
  • FabricTraces.*：里面记录了集群升级全流程、健康检查触发、回滚启动的详细信息，搜 UpgradeDomain、HealthCheckFailed、RollbackStarted 关键词能快速定位问题。
  • FabricHost.*：记录节点启动、Service Fabric服务初始化过程，排查第二个节点启动时的异常。
• Windows事件日志（针对性查看）：别只看表面，去这些路径找：
  1. 打开事件查看器，定位到 应用程序和服务日志 > Microsoft > Service Fabric，查看 Admin 和 Operational 日志，筛选事件ID：19001（升级开始）、19002（升级完成）、19003（回滚启动）相关的记录，可能藏着健康检查失败的具体原因。
  2. 检查 系统日志 里和VM启动、依赖组件（比如.NET Runtime、IIS）相关的警告或错误，说不定是底层组件启动慢导致健康检查超时。
• 导出升级状态详情：用PowerShell命令直接拉取升级的完整状态：

  Get-ServiceFabricUpgrade | Format-List *
  

  这个命令会返回升级当前阶段、健康检查失败的具体对象（哪个节点/服务不达标）、超时设置等关键数据，比日志更直接。

二、分步调试排查 #

1. 检查健康检查策略是否过严 #

升级时的健康检查阈值可能默认太严格，先看当前集群的健康策略：

Get-ServiceFabricClusterHealthPolicy

如果发现 MaxPercentUnhealthyNodes 或 MaxPercentUnhealthyApplications 阈值太低，试试临时放宽后重新升级，验证是不是阈值问题：

Start-ServiceFabricClusterUpgrade -Code -ClusterManifestVersion <你的9.1版本号> -HealthPolicy @{MaxPercentUnhealthyNodes=100; MaxPercentUnhealthyApplications=100} -UpgradeTimeoutSec 1200 -HealthCheckStableDurationSec 300

注意：这只是调试用，排查完记得改回原配置。

2. 手动验证第二个节点的预升级状态 #

回滚完成后，直接登录第二个节点VM做检查：

• 执行 Get-ServiceFabricNode 确认节点状态是不是 Up。
• 打开 services.msc 看 FabricHostSvc、FabricSetup 这些Service Fabric相关服务是不是正常运行。
• 用 Test-NetConnection 测试该节点和另外两个节点的19000、19001等Service Fabric端口能不能正常通信，排除网络问题。

3. 检查版本依赖兼容性 #

9.0到9.1可能有底层依赖变化，确认这些点：

• 所有节点的Windows Server版本是不是符合要求（9.1需要Windows Server 2016及以上）。
• 节点上有没有装9.1需要的.NET runtime，执行 dotnet --list-runtimes 查看，缺的话补上对应版本。

4. 手动单节点升级模拟流程 #

暂停自动升级后，手动升级第二个节点，实时看日志抓问题：

1. 先停掉当前升级：Stop-ServiceFabricClusterUpgrade
2. 手动升级第二个节点：Start-ServiceFabricNodeConfigurationUpgrade -NodeName <你的节点名> -CodePackageVersion 9.1.1883.9590
3. 实时监控该节点的 FabricTraces 日志，记录从启动到健康检查失败的每一步，能精准定位卡壳的地方。

内容的提问来源于stack exchange，提问作者Richard Fennell