通过

排查自动化中基于代理的混合 Runbook 辅助角色问题

  • 项目

重要

Azure 自动化基于代理的用户混合 Runbook 辅助角色（Windows 和 Linux）将于 2024 年 8 月 31 日停用，在此日期之后不再受支持。 必须在 2024 年 8 月 31 日之前将现有基于代理的用户混合 Runbook 辅助角色迁移到基于扩展的辅助角色。 此外，从 2023 年 11 月 1 日开始，将无法创建新的基于代理的混合辅助角色。 了解详细信息

本文介绍如何排查和解决 Azure 自动化基于代理的混合 Runbook 辅助角色的问题。 有关如何排查基于扩展的辅助角色的问题，请参阅排查自动化中基于扩展的混合 Runbook 辅助角色问题。 如需常规信息，请参阅混合 Runbook 辅助角色概述。

常规

混合 Runbook 辅助角色依靠代理与 Azure 自动化帐户通信，以注册辅助角色、接收 Runbook 作业和报告状态。 对于 Windows，此代理是适用于 Windows 的 Log Analytics 代理。 对于 Linux，此代理是适用于 Linux 的 Log Analytics 代理。

使用混合辅助角色时无法更新 Az 模块

问题

混合 Runbook 辅助角色作业失败，因为它无法导入 Az 模块。

解决

一个变通方法是，按照以下步骤操作：

  1. 转到文件夹：C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0\HybridAgent
  2. 编辑名为 Orchestrator.Sandbox.exe.config 的文件
  3. 在 <assemblyBinding> 标记中添加以下行：
<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>

注意

如果通过启用解决方案或进行修补来重启 MMA/服务器，解决方法会将该文件替换为原始文件。 对于这两种情况，我们建议你替换这些内容。

场景：Runbook 执行失败

问题

Runbook 执行失败并出现以下错误消息：

The job action 'Activate' cannot be run, because the process stopped unexpectedly. The job action was attempted three times.

Runbook 在尝试执行三次后很快暂停。 在某些情况下，Runbook 可能会中断，无法正常完成。 相关错误消息可能不包括任何附加信息。

原因

下面是可能的原因：

  • Runbook 无法使用本地资源进行身份验证。
  • 混合辅助角色在代理或防火墙后面。
  • 配置为运行混合 Runbook 辅助角色的计算机不满足最低硬件要求。

解决方法

验证计算机在端口 443 上对 *.azure-automation.cn 是否有出站访问权限。

运行混合 Runbook 辅助角色的计算机应满足最低硬件要求，然后才能将辅助角色配置为托管此功能。 它们使用的 Runbook 和后台进程可能会导致系统过度使用，造成 Runbook 作业延迟或超时。

确认将要运行混合 Runbook 辅助角色功能的计算机满足最低硬件要求。 如果满足，请监视 CPU 和内存使用，以确定混合 Runbook 辅助角色进程的性能和 Windows 之间的任何关联。 出现内存或 CPU 压力可能意味着需要升级资源。 也可以选择其他支持最低要求的计算资源，并在工作负载需求指示需要增加时进行扩展。

在 Microsoft-SMA 事件日志中检查附带“Win32 Process Exited with code [4294967295]”说明的相应事件。 此错误的原因是尚未在 Runbook 中配置身份验证，或者未为混合 Runbook 辅助角色组指定运行方式凭据。 在在混合 Runbook 辅助角色上运行 Runbook 中查看 Runbook 权限，确认是否已正确配置 Runbook 的身份验证。

场景：Runbook 失败并出现网关错误

问题

通过 Log Analytics 网关服务器进行通信时，混合 Runbook 辅助角色作业刷新失败，并返回的错误类似如下错误：Spool operation id does not exist (spool ID): see attachment for job details and exact exception messages.

解决方法

验证 Log Analytics 网关服务器是否联机并且可从托管混合 Runbook 辅助角色的计算机访问。 如需了解更多故障排除信息，请参阅 Log Analytics 网关故障排除。

场景：作业无法启动，因为计划作业启动时混合辅助角色不可用

问题

作业无法在混合辅助角色上启动，出现以下错误：

无法启动，因为混合辅助角色在计划作业启动时不可用。混合辅助角色最后处于活动状态的时间是 mm/dd/yyyy。

原因

存在以下原因时，可能会出现此错误：

  • 计算机不再存在。
  • 计算机已关闭，不可访问。
  • 计算机存在网络连接问题。
  • 已从计算机中卸载混合 Runbook 辅助角色扩展。

解决方法

  • 确保计算机存在，并在其上安装混合 Runbook 辅助角色扩展。 混合辅助角色应正常运行，并且应提供检测信号。 通过检查混合 Runbook 辅助角色组中尝试运行此作业的辅助角色上的 Microsoft-SMA 事件日志来排查任何网络问题。
  • 还可以监视 HybridWorkerPing 指标，该指标提供混合辅助角色发出的 ping 的次数，有助于检查 ping 相关问题。

场景：作业因超出混合辅助角色的作业限制而暂停

问题

作业暂停并显示以下错误消息：

作业因超出混合辅助角色的作业限制而暂停。 向混合辅助角色组添加更多混合辅助角色以解决此问题。

原因

作业可能因以下任一原因而暂停：

  • 组中每个活动的混合辅助角色每 30 秒轮询一次作业，以查看是否有可用的作业。 辅助角色按照先到先得的原则选取作业。 由混合辅助角色组中先 ping 自动化服务的混合辅助角色选取作业，具体取决于作业推送时间。 通常，一个混合辅助角色在每次执行 ping 操作时（即每隔 30 秒）可提取四个作业。 如果推送作业的频率高于每 30 秒 4 次且没有其他辅助角色选取该作业，则该作业可能会暂停。
  • 混合辅助角色可能不会按预期每 30 秒轮询 1 次。 如果辅助角色不正常或存在网络问题，则可能会出现这种情况。

解决方法

  • 如果混合辅助角色的作业限制超出每 30 秒 4 个作业，则可将更多混合辅助角色添加到混合辅助角色组，以实现高可用性和负载均衡。 还可以计划作业，使其不超出每 30 秒 4 个作业的限制。 作业队列的处理时间取决于混合辅助角色硬件配置文件和负载。 确保混合辅助角色正常运行并发出检测信号。
  • 通过检查混合 Runbook 辅助角色组中尝试运行此作业的辅助角色上的 Microsoft-SMA 事件日志来排查任何网络问题。
  • 还可以监视 HybridWorkerPing 指标，该指标提供混合辅助角色发出的 ping 的次数，有助于检查 ping 相关问题。

场景：混合 Runbook 辅助角色中发生事件 15011

问题

混合 Runbook 辅助角色收到表示查询结果无效的事件 15011。 当辅助角色尝试与 SignalR 服务器建立连接时出现以下错误。

[AccountId={c7d22bd3-47b2-4144-bf88-97940102f6ca}] [Uri=https://cc-jobruntimedata-prod-su1.azure-automation.cn/notifications/hub][Exception=System.TimeoutException: Transport timed out trying to connect​ at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()​ at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)​ at JobRuntimeData.NotificationsClient.JobRuntimeDataServiceSignalRClient.<Start>d__45.MoveNext()​

原因

未为自动化功能部署（例如更新管理）正确配置混合 Runbook 辅助角色。 部署包含的某个部件会将 VM 连接到 Log Analytics 工作区。 PowerShell 脚本将在订阅中查找具有所提供名称的工作区。 在此示例中，该 Log Analytics 工作区位于其他订阅中。 脚本找不到该工作区，因此尝试创建一个工作区，但该名称已被占用。 因此，部署失败。

解决方法

可以采用两种做法来解决此问题：

  • 修改 PowerShell 脚本，以在另一个订阅中查找 Log Analytics 工作区。 如果你将来打算部署许多混合 Runbook 辅助角色计算机，则非常适合使用此解决方法。

  • 手动将辅助角色计算机配置为在业务流程协调程序沙盒中运行。 然后在该辅助角色上运行在 Azure 自动化帐户中创建的 Runbook，以测试功能。

场景：Azure VM 被从混合辅助角色组中自动删除

问题

当辅助角色计算机长期关闭时，看不到混合 Runbook 辅助角色或 VM。

原因

混合 Runbook 辅助角色计算机有 30 天以上无法 ping 通 Azure 自动化。 因此，自动化清除了混合 Runbook 辅助角色组或系统辅助角色组。

解决方法

启动辅助角色计算机，然后将其重新注册到 Azure 自动化。 有关如何安装 Runbook 环境和连接到 Azure 自动化的说明，请参阅部署 Windows 混合 Runbook 辅助角色。

场景：在混合 Runbook 辅助角色上的证书存储中找不到证书

问题

混合 Runbook 辅助角色上运行的 runbook 失败并显示以下错误消息：

Connect-AzAccount : No certificate was found in the certificate store with thumbprint 0000000000000000000000000000000000000000 At line:3 char:1 + Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID -Appl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Connect-AzAccount],ArgumentException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.ConnectAzAccountCommand

原因

尝试在混合 Runbook 辅助角色上运行的 Runbook 中使用运行方式帐户时，如果运行方式帐户证书不存在，则会发生此错误。 默认情况下，混合 Runbook 辅助角色在本地没有证书资产。 运行方式帐户需要此资产才能正常运行。

解决方法

如果混合 Runbook 辅助角色是 Azure VM，则可改用使用托管标识的 Runbook 身份验证。 此方案允许使用 Azure VM 的托管标识而非运行方式帐户向 Azure 资源进行身份验证，从而简化了身份验证。 如果混合 Runbook 辅助角色是本地计算机，需要在此计算机上安装运行方式帐户证书。 若要了解如何安装证书，请参阅在混合 Runbook 辅助角色上运行 Runbook 中有关如何运行 PowerShell Runbook Export-RunAsCertificateToHybridWorker 的步骤。

场景：在注册混合 Runbook 辅助角色期间发生错误 403

问题

辅助角色的初始注册阶段失败并出现以下错误 (403)：

Forbidden: You don't have permission to access / on this server.

原因

以下问题是可能的原因：

  • 在代理设置中错误键入了工作区 ID 或工作区密钥（主密钥）。
  • 混合 Runbook 辅助角色无法下载配置，导致帐户链接错误。 当 Azure 在计算机上启用功能时，它仅支持特定的区域链接 Log Analytics 工作区和自动化帐户。 此外，还可能在计算机上设置了错误的日期或时间。 如果时间比当前时间快/慢 15 分钟，则功能部署会失败。
  • Log Analytics 网关未配置为支持混合 Runbook 辅助角色。

解决方法

错误键入了工作区 ID 或密钥

若要验证是否错误键入了代理的工作区 ID 或工作区密钥，请参阅添加或删除工作区 – Windows 代理（适用于 Windows 代理）或者添加或删除工作区 – Linux 代理（适用于 Linux 代理）。 确保从 Azure 门户中选择完整字符串，然后小心复制并粘贴该字符串。

未下载配置

Log Analytics 工作区和自动化帐户必须位于链接的区域中。 这是更新管理使用的 System Hybrid Runbook Worker 的建议解决方案。 有关支持的区域列表，请参阅 Azure 自动化和 Log Analytics 工作区映射。

可能还需要更新计算机的日期或时区。 如果选择自定义时间范围，请确保该范围采用 UTC，它可能与你的本地时区不同。

未配置 Log Analytics 网关

按照此处提到的步骤将混合 Runbook 辅助角色终结点添加到 Log Analytics 网关。

场景：Set-AzStorageBlobContent 在混合 Runbook 辅助角色上失败

Linux

Linux 混合 Runbook 辅助角色依靠适用于 Linux 的 Log Analytics 代理与自动化帐户通信，以注册辅助角色、接收 Runbook 作业和报告状态。 如果辅助角色注册失败，以下是一些可能导致此错误的原因。

场景：Linux 混合 Runbook 辅助角色在为 Runbook 签名时收到密码提示

问题

针对 Linux 混合 Runbook 辅助角色运行 sudo 命令时检索到意外的密码提示。

原因

未在 sudoers 文件中正确配置适用于 Linux 的 Log Analytics 代理的 nxautomationuser 帐户 。 需要为混合 Runbook 辅助角色适当配置帐户权限和其他数据，才能让它为 Linux Runbook 辅助角色中的 Runbook 签名。

解决方法

场景：适用于 Linux 的 Log Analytics 代理未运行

问题

适用于 Linux 的 Log Analytics 代理未运行。

原因

如果该代理未运行，会导致 Linux 混合 Runbook 辅助角色无法与 Azure 自动化通信。 该代理可能会出于各种原因而未运行。

解决方法

输入命令 ps -ef | grep python 以验证该代理是否正在运行。 应该会看到与下面类似的输出。 使用 nxautomation 用户帐户的 Python 进程。 如果未启用 Azure 自动化功能，则以下任何进程都不会运行。

nxautom+   8567      1  0 14:45 ?        00:00:00 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/main.py /var/opt/microsoft/omsagent/state/automationworker/oms.conf rworkspace:<workspaceId> <Linux hybrid worker version>
nxautom+   8593      1  0 14:45 ?        00:00:02 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/hybridworker.py /var/opt/microsoft/omsagent/state/automationworker/worker.conf managed rworkspace:<workspaceId> rversion:<Linux hybrid worker version>
nxautom+   8595      1  0 14:45 ?        00:00:02 python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/worker/hybridworker.py /var/opt/microsoft/omsagent/<workspaceId>/state/automationworker/diy/worker.conf managed rworkspace:<workspaceId> rversion:<Linux hybrid worker version>

以下列表显示针对 Linux 混合 Runbook 辅助角色启动的进程。 这些进程全部位于 /var/opt/microsoft/omsagent/state/automationworker/ 目录中。

  • oms.conf：辅助角色管理器进程。 它直接从 DSC 启动。
  • worker.conf：自动注册的混合辅助角色进程。 它由辅助角色管理器启动。 此进程由更新管理使用且对用户而言是透明的。 如果未在计算机上启用更新管理，则不会显示此进程。
  • diy/worker.conf：DIY 混合辅助角色进程。 DIY 混合辅助角色进程用于执行混合 Runbook 辅助角色的用户 Runbook。 它仅与使用不同配置的自动注册混合辅助角色进程在主要细节上有所不同。 如果禁用 Azure 自动化，并且 DIY Linux 混合辅助角色未注册，则不会显示此进程。

如果该代理未运行，请运行以下命令以启动该服务：sudo /opt/microsoft/omsagent/bin/service_control restart。

场景：指定的类不存在

如果在 /var/opt/microsoft/omsconfig/omsconfig.log 中看到错误消息 The specified class does not exist..，则需要更新适用于 Linux 的 Log Analytics 代理。 运行以下命令以重新安装该代理。

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <WorkspaceID> -s <WorkspaceKey>

Windows

Windows 混合 Runbook 辅助角色依靠适用于 Windows 的 Log Analytics 代理与自动化帐户通信，以注册辅助角色、接收 Runbook 作业和报告状态。 如果辅助角色注册失败，请参考本部分所述的一些可能原因。

场景：适用于 Windows 的 Log Analytics 代理未运行。

问题

healthservice 未在混合 Runbook 辅助角色计算机上运行。

原因

如果适用于 Windows 的 Log Analytics 服务未运行，则混合 Runbook 辅助角色无法与 Azure 自动化通信。

解决方法

在 PowerShell 中输入以下命令，验证代理是否正在运行：Get-Service healthservice。 如果该服务已停止，请在 PowerShell 中输入以下命令启动该服务：Start-Service healthservice。

场景：Operations Manager 日志中出现事件 4502

问题

在 Application and Service Logs\Operations Manager 事件日志中看到事件 4502，以及包含 Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent 并附带以下说明的事件消息：
The certificate presented by the service \<wsid\>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Please contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

原因

此问题可能是由于代理或网络防火墙阻止与 Azure 的通信造成的。 验证计算机在端口 443 上对 *.azure-automation.cn 是否有出站访问权限。

解决方法

日志存储在每个混合辅助角色本地的 C:\ProgramData\Microsoft\System Center\Orchestrator\7.2\SMA\Sandboxes 中。 可以在 Application and Services Logs\Microsoft-SMA\Operations 和 Application and Services Logs\Operations Manager 事件日志中验证是否出现了任何警告或错误事件。 这些日志会指出发生影响了在 Azure 自动化中启用角色的连接问题或其他类型的问题，或者在正常操作时遇到的问题。 在排查 Log Analytics 代理问题时如需更多帮助，请参阅排查 Log Analytics Windows 代理的问题。

混合辅助角色将 Runbook 输出和消息发送到 Azure 自动化，其发送方式与云中运行的 Runbook 作业发送输出和消息的方式相同。 可以像使用 Runbook 时一样启用“详细”流和“进度”流。

场景：混合 Runbook 辅助角色未提供报告

问题

混合 Runbook 辅助角色计算机在运行，但是在工作区中未看到该计算机的检测信号数据。

以下示例查询显示了工作区中的计算机及其上次检测信号：

Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer

原因

此问题可能是由于混合 Runbook 辅助角色上的高速缓存损坏导致的。

解决方法

若要解决此问题，请登录到混合 Runbook 辅助角色并运行以下脚本。 此脚本将停止适用于 Windows 的 Log Analytics 代理，删除其缓存，并重启服务。 此操作会强制混合 Runbook 辅助角色从 Azure 自动化重新下载其配置。

Stop-Service -Name HealthService

Remove-Item -Path 'C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State' -Recurse

Start-Service -Name HealthService

场景：无法添加 Windows 混合 Runbook 辅助角色

问题

尝试使用 Add-HybridRunbookWorker cmdlet 添加混合 Runbook 辅助角色时收到以下消息：

Machine is already registered

原因

如果计算机已注册到一个不同的自动化帐户，或者在将混合 Runbook 辅助角色从计算机中删除后尝试重新添加它，则可能会导致此问题。

解决方法

若要解决此问题，请删除以下注册表项，重启 HealthService，然后再次尝试运行 Add-HybridRunbookWorker cmdlet。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker

场景：无法添加 Linux 混合 Runbook 辅助角色

问题

尝试使用 sudo python /opt/microsoft/omsconfig/.../onboarding.py --register Python 脚本添加混合 Runbook 辅助角色时会收到以下消息：

Unable to register, an existing worker was found. Please deregister any existing worker and try again.

此外，尝试使用 sudo python /opt/microsoft/omsconfig/.../onboarding.py --deregister Python 脚本取消注册混合 Runbook 辅助角色：

Failed to deregister worker. [response_status=404]

原因

如果计算机已注册到一个不同的自动化帐户，并且 Azure 混合辅助角色组已被删除，或者在将混合 Runbook 辅助角色从计算机中删除后尝试重新添加它，则可能会出现此问题。

解决方法

若要解决此问题，请执行下列操作：

  1. 删除代理 sudo sh onboard_agent.sh --purge。

  2. 运行以下命令：

    sudo mv -f /home/nxautomation/state/worker.conf /home/nxautomation/state/worker.conf_old
sudo mv -f /home/nxautomation/state/worker_diy.crt /home/nxautomation/state/worker_diy.crt_old
sudo mv -f /home/nxautomation/state/worker_diy.key /home/nxautomation/state/worker_diy.key_old

  3. 重新载入代理 sudo sh onboard_agent.sh -w <workspace id> -s <workspace key> -d opinsights.azure.cn。

  4. 等待文件夹 /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker 填充。

  5. 重新尝试 sudo python /opt/microsoft/omsconfig/.../onboarding.py --register Python 脚本。

后续步骤

如果你的问题未在本文中列出，或者无法解决你遇到的问题，请尝试通过以下途径之一获取更多支持：