Partilhar via

Resolver problemas da Função de Trabalho de Runbook Híbrida baseada numa extensão da VM na Automatização

  • Artigo

Importante

O Runbook Worker Híbrido de Usuário baseado no Azure Automation Agent (Windows e Linux) foi desativado em 31 de agosto de 2024 e não é mais suportado. Siga as diretrizes sobre como migrar de um Runbook Workers Híbrido de Usuário baseado em Agente existente para Trabalhadores Híbridos baseados em Extensão.

Este artigo fornece informações sobre como solucionar problemas com Runbook Workers híbridos baseados em agente de Automação do Azure. Para solucionar problemas de trabalhadores baseados em extensão, consulte Solucionar problemas do Runbook Worker híbrido baseado em extensão na automação. Para obter informações gerais, consulte Visão geral do Hybrid Runbook Worker.

Geral

O Runbook Worker Híbrido depende de um agente para se comunicar com sua conta de Automação do Azure para registrar o trabalhador, receber trabalhos de runbook e relatar o status. Para Windows, esse agente é o agente do Log Analytics para Windows. Para Linux, é o agente do Log Analytics para Linux.

Não é possível atualizar módulos Az ao usar o Hybrid Worker

Problema

Os trabalhos do Hybrid Runbook Worker falharam, pois não foi possível importar módulos Az.

Resolução

Como solução alternativa, você pode seguir estas etapas:

  1. Vá para a pasta : C:\Program Files\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.1722.0\HybridAgent
  2. Edite o arquivo com o nome Orchestrator.Sandbox.exe.config
  3. Adicione as seguintes linhas dentro das <assemblyBinding> tags :
<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>

Nota

A solução alternativa substitui o arquivo pelo original se você reiniciar o MMA/servidor habilitando a solução ou a aplicação de patches. Para ambos os cenários, recomendamos que você substitua o conteúdo.

Cenário: Falha na execução do runbook

Problema

A execução do runbook falha e você recebe a seguinte mensagem de erro:

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

Seu runbook é suspenso logo após tentar executar três vezes. Há condições que podem interromper a conclusão do runbook. A mensagem de erro relacionada pode não incluir informações adicionais.

Motivo

A seguir são indicadas causas possíveis:

  • Os runbooks não podem ser autenticados com recursos locais.
  • O trabalhador híbrido está atrás de um proxy ou firewall.
  • O computador configurado para executar o Hybrid Runbook Worker não atende aos requisitos mínimos de hardware.

Resolução

Verifique se o computador tem acesso de saída a *.azure-automation.net na porta 443.

Os computadores que executam o Hybrid Runbook Worker devem atender aos requisitos mínimos de hardware antes que o trabalhador seja configurado para hospedar esse recurso. Os runbooks e o processo em segundo plano que eles usam podem fazer com que o sistema seja usado em excesso e causar atrasos ou tempos limite de trabalho do runbook.

Confirme se o computador para executar o recurso Hybrid Runbook Worker atende aos requisitos mínimos de hardware. Se isso acontecer, monitore o uso da CPU e da memória para determinar qualquer correlação entre o desempenho dos processos do Hybrid Runbook Worker e o Windows. Qualquer pressão de memória ou CPU pode indicar a necessidade de atualizar recursos. Você também pode selecionar um recurso de computação diferente que ofereça suporte aos requisitos mínimos e dimensionar quando as demandas de carga de trabalho indicarem que um aumento é necessário.

Verifique o log de eventos do Microsoft-SMA para obter um evento correspondente com a descrição Win32 Process Exited with code [4294967295]. A causa desse erro é que você não configurou a autenticação em seus runbooks ou especificou as credenciais Run As para o grupo Hybrid Runbook Worker. Revise as permissões de runbook em Executando runbooks em um Runbook Worker híbrido para confirmar que você configurou corretamente a autenticação para seus runbooks.

Cenário: Runbooks falham com erro de gateway

Problema

Os trabalhos do Hybrid Runbook Worker falharam ao se comunicar por meio de um servidor Gateway do Log Analytics e o erro retornado é semelhante a: Spool operation id does not exist (spool ID): see attachment for job details and exact exception messages.

Resolução

Verifique se o servidor do Log Analytics Gateway está online e acessível a partir da máquina que hospeda a função Hybrid Runbook Worker. Para obter informações adicionais sobre solução de problemas, consulte Solucionar problemas do Log Analytics Gateway.

Cenário: Falha ao iniciar o trabalho, pois o Trabalhador Híbrido não estava disponível quando o trabalho agendado foi iniciado

Problema

O trabalho falha ao iniciar em um trabalhador híbrido e você vê o seguinte erro:

Falha ao iniciar, como o trabalhador híbrido não estava disponível quando o trabalho agendado foi iniciado, o trabalhador híbrido estava ativo pela última vez em mm/dd/aa.

Motivo

Este erro pode ocorrer devido aos seguintes motivos:

  • As máquinas não existem mais.
  • A máquina está desligada e está inacessível.
  • A máquina tem um problema de conectividade de rede.
  • A extensão Hybrid Runbook Worker foi desinstalada da máquina.

Resolução

  • Verifique se a máquina existe e se a extensão Hybrid Runbook Worker está instalada nela. O Trabalhador Híbrido deve ser saudável e deve dar um batimento cardíaco. Solucione quaisquer problemas de rede verificando os logs de eventos Microsoft-SMA nos Trabalhadores no Grupo de Trabalho de Runbook Híbrido que tentou executar esse trabalho.
  • Você também pode monitorar a métrica HybridWorkerPing que fornece o número de pings de um Trabalhador Híbrido e pode ajudar a verificar problemas relacionados a ping.

Cenário: O trabalho foi suspenso por exceder o limite de trabalho para um trabalhador híbrido

Problema

O trabalho é suspenso com a seguinte mensagem de erro:

O trabalho foi suspenso por exceder o limite de trabalho para um trabalhador híbrido. Adicione mais Trabalhadores Híbridos ao grupo de Trabalhadores Híbridos para superar esse problema.

Motivo

Os trabalhos podem ser suspensos devido a qualquer um dos seguintes motivos:

  • Cada Função de Trabalho Híbrida ativa no grupo irá consultar os trabalhos a cada 30 segundos para verificar se existem trabalhos disponíveis. O Trabalhador escolhe trabalhos por ordem de chegada. Dependendo de quando um trabalho foi enviado, qualquer Trabalhador Híbrido dentro do Grupo de Trabalhadores Híbridos pingar o serviço de Automação primeiro pega o trabalho. Um único trabalhador híbrido geralmente pode pegar quatro trabalhos por ping (ou seja, a cada 30 segundos). Se a sua taxa de envio de trabalhos for superior a quatro por 30 segundos e nenhum outro Trabalhador pegar o trabalho, o trabalho poderá ser suspenso.
  • O Trabalhador Híbrido pode não estar pesquisando como esperado a cada 30 segundos. Isso pode acontecer se o trabalhador não estiver íntegro ou se houver problemas de rede.

Resolução

  • Se o limite de trabalho para um Trabalhador Híbrido exceder quatro trabalhos por 30 segundos, você poderá adicionar mais Trabalhadores Híbridos ao grupo de Trabalhadores Híbridos para alta disponibilidade e balanceamento de carga. Você também pode agendar trabalhos para que eles não excedam o limite de quatro trabalhos a cada 30 segundos. O tempo de processamento da fila de trabalhos depende do perfil de hardware do trabalhador híbrido e da carga. Certifique-se de que o Trabalhador Híbrido está saudável e dá um batimento cardíaco.
  • Solucione quaisquer problemas de rede verificando os logs de eventos Microsoft-SMA nos Trabalhadores no Grupo de Trabalho de Runbook Híbrido que tentou executar esse trabalho.
  • Você também pode monitorar a métrica HybridWorkerPing que fornece o número de pings de um Trabalhador Híbrido e pode ajudar a verificar problemas relacionados a ping.

Cenário: Evento 15011 no Runbook Worker híbrido

Problema

O Hybrid Runbook Worker recebe o evento 15011, indicando que um resultado de consulta não é válido. O seguinte erro aparece quando o trabalhador tenta abrir uma conexão com o servidor SignalR.

[AccountId={c7d22bd3-47b2-4144-bf88-97940102f6ca}] [Uri=https://cc-jobruntimedata-prod-su1.azure-automation.net/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()​

Motivo

O Hybrid Runbook Worker não foi configurado corretamente para a implantação automatizada de recursos, por exemplo, para o Gerenciamento de Atualizações. A implantação contém uma parte que conecta a VM ao espaço de trabalho do Log Analytics. O script do PowerShell procura a área de trabalho na subscrição com o nome indicado. Neste caso, a área de trabalho do Log Analytics está numa subscrição diferente. O script não consegue encontrar a área de trabalho e tenta criar uma, mas o nome já está a ser utilizado. Como resultado, a implementação falha.

Resolução

Tem duas opções para resolver este problema:

  • Modifique o script do PowerShell para procurar a área de trabalho do Log Analytics noutra subscrição. Esta é uma boa resolução para usar se você planeja implantar muitas máquinas Hybrid Runbook Worker no futuro.

  • Configure manualmente o computador com a função de trabalho para ser executado num sandbox do Orchestrator. Em seguida, execute um runbook criado na conta da Automatização do Azure na função de trabalho para testar a funcionalidade.

Cenário: VMs do Microsoft Azure automaticamente descartadas de um grupo de trabalhadores híbrido

Problema

Não pode ver a Função de Trabalho de Runbook Híbrida ou as VMs quando a máquina virtual da função de trabalho está desativada há muito tempo.

Motivo

A máquina Hybrid Runbook Worker não executa ping na Automação do Azure há mais de 30 dias. Como resultado, a Automatização removeu o grupo de Funções de Trabalho de Runbook Híbridas ou o grupo de Funções de Trabalho do Sistema.

Resolução

Inicie a máquina de trabalho e registre-a novamente com a Automação do Azure. Para obter instruções sobre como instalar o ambiente runbook e conectar-se à Automação do Azure, consulte Implantar um Runbook Worker Híbrido do Windows.

Cenário: Nenhum certificado foi encontrado no armazenamento de certificados no Hybrid Runbook Worker

Problema

Um runbook em execução em um Hybrid Runbook Worker falha com a seguinte mensagem de erro:

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

Motivo

Este erro ocorre quando você tenta usar uma conta Run As em um runbook que é executado em um Hybrid Runbook Worker onde o certificado de conta Run As não está presente. Por predefinição, as Funções de Trabalho de Runbook Híbridas não têm o recurso de certificado localmente. A conta Run As requer que este recurso funcione corretamente.

Resolução

Se o Runbook Worker Híbrido for uma VM do Azure, você poderá usar a autenticação de runbook com identidades gerenciadas. Este cenário simplifica a autenticação ao permitir-lhe fazer a autenticação nos recursos do Azure com a identidade gerida da VM do Azure em vez da conta Run As. Quando a Função de Trabalho de Runbook Híbrida está numa máquina virtual no local, tem de instalar o certificado da conta Run As na mesma. Para saber como instalar o certificado, consulte as etapas para executar o runbook do PowerShell Export-RunAsCertificateToHybridWorker em Run runbooks on a Hybrid Runbook Worker.

Cenário: Erro 403 durante o registro de um Hybrid Runbook Worker

Problema

A fase de registo inicial da função de trabalho falha e recebe o seguinte erro (403):

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

Motivo

Os seguintes problemas são causas possíveis:

  • Um ID da área de trabalho ou uma chave da área de trabalho (principal) estão escritos incorretamente nas definições do agente.
  • O Hybrid Runbook Worker não pode baixar a configuração, o que causa um erro de vinculação de conta. Quando o Azure ativa funcionalidades em computadores, suporta apenas determinadas regiões para ligar uma área de trabalho do Log Analytics e uma conta de Automatização. Também é possível que estejam definidas uma data ou uma hora incorretas no computador. Se a hora tiver uma diferença de +/- 15 minutos em relação à hora atual, a implementação de funcionalidades falha.
  • O Log Analytics Gateway não está configurado para suportar o Hybrid Runbook Worker.

Resolução

ID ou chave da área de trabalho escritos incorretamente

Para verificar se o ID da área de trabalho ou a chave da área de trabalho do agente foram escritos incorretamente, veja Adicionar ou remover uma área de trabalho – Agente do Windows para o agente do Windows ou Adicionar ou remover uma área de trabalho – Agente do Linux para o agente do Linux. Confirme que seleciona a cadeia (de carateres) completa no portal do Azure e copie-a e cole-a cuidadosamente.

Configuração não transferida

A área de trabalho do Log Analytics e a conta de Automatização têm de estar numa região ligada. Esta é a solução sugerida para o System Hybrid Runbook Worker usado pelo Gerenciamento de Atualizações. Para obter uma lista das regiões suportadas, veja Mapeamentos de áreas de trabalho do Log Analytics e da Automatização do Azure.

Também pode ter de atualizar a data ou o fuso horário do computador. Se selecionar um intervalo de tempo personalizado, confirme que o intervalo está em UTC, que pode ser diferente do fuso horário local.

Gateway do Log Analytics não configurado

Siga as etapas mencionadas aqui para adicionar pontos de extremidade do Hybrid Runbook Worker ao Log Analytics Gateway.

Cenário: Set-AzStorageBlobContent falha em um Runbook Worker híbrido

Problema

Runbook falha quando tenta executar Set-AzStorageBlobContente você recebe a seguinte mensagem de erro:

Set-AzStorageBlobContent : Failed to open file xxxxxxxxxxxxxxxx: Illegal characters in path

Motivo

Este erro é causado pelo comportamento de nome de arquivo longo de chamadas para [System.IO.Path]::GetFullPath(), que adiciona caminhos UNC.

Resolução

Como solução alternativa, você pode criar um arquivo de configuração nomeado OrchestratorSandbox.exe.config com o seguinte conteúdo:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
  </runtime>
</configuration>

Coloque este ficheiro na mesma pasta que o ficheiro OrchestratorSandbox.exeexecutável. Por exemplo,

%ProgramFiles%\Microsoft Monitoring Agent\Agent\AzureAutomation\7.3.702.0\HybridAgent

Nota

Se você atualizar o agente, esse arquivo de configuração será excluído e precisará ser recriado.

Linux

O Linux Hybrid Runbook Worker depende do agente do Log Analytics para Linux para se comunicar com sua conta de automação para registrar o trabalhador, receber trabalhos de runbook e relatar o status. Se o registro do trabalhador falhar, aqui estão algumas causas possíveis para o erro.

Cenário: Linux Hybrid Runbook Worker recebe solicitação de uma senha ao assinar um runbook

Problema

A execução do sudo comando para um Linux Hybrid Runbook Worker recupera um prompt inesperado para uma senha.

Motivo

A conta nxautomationuser para o agente do Log Analytics para Linux não está configurada corretamente no arquivo sudoers . O Hybrid Runbook Worker precisa da configuração apropriada de permissões de conta e outros dados para que possa assinar runbooks no Linux Runbook Worker.

Resolução

  • Certifique-se de que o Hybrid Runbook Worker tenha o executável GnuPG (GPG) na máquina.

  • Verifique a configuração da conta nxautomationuser no arquivo sudoers . Consulte Executando runbooks em um Runbook Worker híbrido.

Cenário: O agente do Log Analytics para Linux não está em execução

Problema

O Log Analytics do Linux não está a ser executado.

Motivo

Se o agente não estiver em execução, ele impedirá que o Linux Hybrid Runbook Worker se comunique com a Automação do Azure. O agente pode não estar em execução por vários motivos.

Resolução

Verifique se o agente está em execução inserindo o comando ps -ef | grep python. Deverá ver um resultado semelhante ao seguinte. O Python processa com a conta de usuário nxautomation . Se o recurso de Automação do Azure não estiver habilitado, nenhum dos processos a seguir estará em execução.

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>

A lista a seguir mostra os processos que são iniciados para um Linux Hybrid Runbook Worker. Todos eles estão localizados no diretório /var/opt/microsoft/omsagent/state/automationworker/.

  • oms.conf: O processo do gestor do trabalhador. Começou diretamente do DSC.
  • worker.conf: O processo de trabalho híbrido Auto-Registered. É iniciado pelo gerente do trabalhador. Esse processo é usado pelo Gerenciamento de Atualizações e é transparente para o usuário. Esse processo não estará presente se o Gerenciamento de Atualizações não estiver habilitado no computador.
  • diy/worker.conf: O processo de trabalho híbrido DIY. O processo de trabalho híbrido DIY é usado para executar runbooks de usuário no Hybrid Runbook Worker. Ele só difere do processo de trabalho híbrido registrado automaticamente no detalhe principal de que ele usa uma configuração diferente. Esse processo não estará presente se a Automação do Azure estiver desabilitada e o DIY Linux Hybrid Worker não estiver registrado.

Se o agente não estiver em execução, execute o seguinte comando para iniciar o serviço: sudo /opt/microsoft/omsagent/bin/service_control restart.

Cenário: A classe especificada não existe

Se você vir a mensagem The specified class does not exist.. de erro em /var/opt/microsoft/omsconfig/omsconfig.log, o agente do Log Analytics para Linux precisa ser atualizado. Execute o seguinte comando para reinstalar o agente.

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

O Windows Hybrid Runbook Worker depende do agente do Log Analytics para Windows para se comunicar com sua conta de Automação para registrar o trabalhador, receber trabalhos de runbook e relatar o status. Se o registro do trabalhador falhar, esta seção inclui alguns motivos possíveis.

Cenário: O agente do Log Analytics para Windows não está em execução

Problema

O healthservice não está em execução no computador da Função de Trabalho de Runbook Híbrida.

Motivo

Se o serviço Log Analytics para Windows não estiver em execução, o Hybrid Runbook Worker não poderá se comunicar com a Automação do Azure.

Resolução

Verifique se o agente está em execução inserindo o seguinte comando no PowerShell: Get-Service healthservice. Se o serviço for interrompido, digite o seguinte comando no PowerShell para iniciar o serviço: Start-Service healthservice.

Cenário: Evento 4502 no log do Operations Manager

Problema

No log de eventos Logs de Aplicativos e Serviços\Operations Manager, você verá o evento 4502 e uma mensagem de evento que contém Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent a seguinte descrição:
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.

Motivo

Esse problema pode ser causado pelo proxy ou firewall de rede bloqueando a comunicação com o Microsoft Azure. Verifique se o computador tem acesso de saída a *.azure-automation.net na porta 443.

Resolução

Os logs são armazenados localmente em cada trabalhador híbrido em C:\ProgramData\Microsoft\System Center\Orchestrator\7.2\SMA\Sandboxes. Você pode verificar se há algum evento de aviso ou erro nos logs de eventos de Logs de Aplicativos e Serviços\Microsoft-SMA\Operations e Logs de Aplicativos e Serviços\Operations Manager . Esses logs indicam uma conectividade ou outro tipo de problema que afeta a habilitação da função para a Automação do Azure ou um problema encontrado em operações normais. Para obter mais ajuda na solução de problemas com o agente do Log Analytics, consulte Solucionar problemas com o agente do Windows do Log Analytics.

Os trabalhadores híbridos enviam saída e mensagens do Runbook para a Automação do Azure da mesma forma que os trabalhos de runbook executados na nuvem enviam saída e mensagens. Você pode habilitar os fluxos Verbose e Progress da mesma forma que faz para runbooks.

Cenário: Orchestrator.Sandbox.exe não pode se conectar ao Microsoft 365 através de proxy

Problema

Um script executado numa Função de Trabalho de Runbook Híbrida do Windows não consegue ligar-se como esperado ao Microsoft 365 numa sandbox do Orchestrator. O script está usando Connect-MgGraph para conexão.

Se você ajustar o Orchestrator.Sandbox.exe.config para definir o proxy e a lista de bypass, a área restrita ainda não se conecta corretamente. Um arquivo Powershell_ise.exe.config com as mesmas configurações de proxy e lista de bypass parece funcionar como você espera. Os logs do SMA (Service Management Automation) e os logs do PowerShell não fornecem informações sobre proxy.

Motivo

A conexão com os Serviços de Federação do Ative Directory (AD FS) no servidor não pode ignorar o proxy. Lembre-se de que uma área restrita do PowerShell é executada como o usuário registrado. No entanto, uma área restrita do Orchestrator é altamente personalizada e pode ignorar as configurações do arquivo Orchestrator.Sandbox.exe.config . Ele tem código especial para lidar com configurações de proxy de máquina ou agente do Log Analytics, mas não para lidar com outras configurações de proxy personalizadas.

Resolução

Você pode resolver o problema da área restrita do Orchestrator migrando seu script para usar os módulos do Microsoft Entra em vez dos cmdlets do PowerShell. Para obter mais informações, consulte Migrando do Orchestrator para a Automação do Azure (Beta).

Se quiser continuar a usar os cmdlets do módulo, altere o script para usar Invoke-Command. Especifique valores para os ComputerName parâmetros e Credential .

$Credential = Get-AutomationPSCredential -Name MyProxyAccessibleCredential​
Invoke-Command -ComputerName $env:COMPUTERNAME -Credential $Credential
{ Connect-MgGraph … }​

Essa alteração de código inicia uma sessão do PowerShell totalmente nova no contexto das credenciais especificadas. Ele deve permitir que o tráfego flua através de um servidor proxy que está autenticando o usuário ativo.

Nota

Essa resolução torna desnecessário manipular o arquivo de configuração da área restrita. Mesmo que você consiga fazer o arquivo de configuração funcionar com seu script, o arquivo é apagado cada vez que o agente Hybrid Runbook Worker é atualizado.

Cenário: Runbook Worker híbrido não relatando

Problema

O computador da Função de Trabalho de Runbook Híbrida está em execução, mas não vê dados do heartbeat para o computador na área de trabalho.

A consulta de exemplo a seguir mostra as máquinas em um espaço de trabalho e sua última pulsação:

Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer

Motivo

Esse problema pode ser causado por um cache corrompido no Hybrid Runbook Worker.

Resolução

Para resolver esse problema, entre no Hybrid Runbook Worker e execute o script a seguir. Esse script interrompe o agente do Log Analytics para Windows, remove seu cache e reinicia o serviço. Essa ação força o Runbook Worker híbrido a baixar novamente sua configuração da Automação do Azure.

Stop-Service -Name HealthService

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

Start-Service -Name HealthService

Cenário: Não é possível adicionar um Windows Hybrid Runbook Worker

Problema

Você recebe a seguinte mensagem quando tenta adicionar um Hybrid Runbook Worker usando o Add-HybridRunbookWorker cmdlet:

Machine is already registered

Motivo

Esse problema pode ser causado se a máquina já estiver registrada com uma conta de automação diferente ou se você tentar adicionar novamente o Hybrid Runbook Worker depois de removê-lo de uma máquina.

Resolução

Para resolver esse problema, remova a seguinte chave do Registro, reinicie HealthServicee tente o Add-HybridRunbookWorker cmdlet novamente.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker

Cenário: Não é possível adicionar um Linux Hybrid Runbook Worker

Problema

Você recebe a seguinte mensagem quando tenta adicionar um Hybrid Runbook Worker usando o sudo python /opt/microsoft/omsconfig/.../onboarding.py --register script Python:

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

Além disso, tentando cancelar o registro de um Hybrid Runbook Worker usando o sudo python /opt/microsoft/omsconfig/.../onboarding.py --deregister script Python:

Failed to deregister worker. [response_status=404]

Motivo

Esse problema pode ocorrer se a máquina já estiver registrada com uma conta de automação diferente, se o Grupo de Trabalho Híbrido do Azure foi excluído ou se você tentar adicionar novamente o Runbook Worker híbrido depois de removê-lo de uma máquina.

Resolução

Para resolver este problema:

  1. Remova o agente sudo sh onboard_agent.sh --purge.

  2. Execute estes comandos:

    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. Reintegre o agente sudo sh onboard_agent.sh -w <workspace id> -s <workspace key> -d opinsights.azure.com.

  4. Aguarde até que a pasta /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker seja preenchida.

  5. Tente o sudo python /opt/microsoft/omsconfig/.../onboarding.py --register script Python novamente.

Próximos passos

Se não vir o problema aqui ou não conseguir resolvê-lo, experimente um dos seguintes canais para obter mais suporte:

  • Obtenha respostas de especialistas do Azure através dos Fóruns do Azure.
  • Conecte-se com @AzureSupport, a conta oficial do Microsoft Azure para melhorar a experiência do cliente. O Suporte do Azure conecta a comunidade do Azure a respostas, suporte e especialistas.
  • Registre um incidente de suporte do Azure. Vá para o site de suporte do Azure e selecione Obter Suporte.