更新服务主体密钥后Azure DevOps自托管VMSS弹性代理池缩放停滞

我在Azure DevOps中有2个基于自托管VMSS的弹性代理池。今日早些时候，用于缩放VMSS的服务主体密钥过期。已更新服务主体生成新密钥，但缩放任务似乎已停止。

最新事件（日志中ID为22259的configurationJob）发生在更新服务主体连接之前。

看起来sizingJob在configurationJob失败后停止执行。查阅了Azure DevOps API和设置页面，但未找到重试方法。

configurationJob是否有延迟/调度机制？或有其他强制重试的方式？重建池是一种解决方案，但希望能避免。是否必须重建代理池才能恢复运行？

ElasticpoolLog API 输出 #

[
    {
        "id": 22259,
        "poolId": 16,
        "level": "error",
        "operation": "configurationJob",
        "message": "Failed to get scaleset from Azure with error: VS30063: You are not authorized to access https://management.azure.com.",
        "timestamp": "2023-10-25T10:04:59.9270943Z"
    },
    {
        "id": 22258,
        "poolId": 16,
        "level": "error",
        "operation": "sizingJob",
        "message": "VS30063: You are not authorized to access https://management.azure.com.",
        "timestamp": "2023-10-25T10:04:59.3096667Z"
    },
    {
        "id": 22255,
        "poolId": 16,
        "level": "error",
        "operation": "sizingJob",
        "message": "VS30063: You are not authorized to access https://management.azure.com.",
        "timestamp": "2023-10-25T10:02:29.5615836Z"
    }
]

解决方案建议 #

• 重新验证服务主体连接：在Azure DevOps代理池的弹性配置页面，找到对应的Azure服务连接，手动触发连接验证。验证通过后，系统会自动重新触发configurationJob和sizingJob。
• 触发配置刷新：通过Azure DevOps REST API发送PATCH请求到代理池接口（无需修改配置），请求体携带原池配置参数，强制系统重新加载池配置，进而触发相关任务。示例接口路径：https://dev.azure.com/{组织名}/{项目名}/_apis/distributedtask/pools/{池ID}?api-version=7.1-preview.1
• 确认服务主体权限：检查更新后的服务主体是否仍拥有VMSS的Microsoft.Compute/virtualMachineScaleSets/*权限及Azure资源管理器访问权限，避免因权限不足导致任务再次失败。
• 等待自动重试：configurationJob默认有自动重试机制，间隔约15-30分钟，若刚更新密钥，可先等待一段时间观察系统是否自动恢复。

若以上方法均无效，再考虑重建代理池，优先尝试上述步骤以降低重建成本。

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