Solucionar problemas e diagnosticar falhas de fluxo de trabalho nos Aplicativos Lógicos do Azure
Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Standard)
O fluxo de trabalho de seu aplicativo lógico gera informações que podem ajudar você a diagnosticar e depurar problemas nele. Você pode diagnosticar o fluxo de trabalho examinando as entradas, as saídas e outras informações para cada etapa no fluxo de trabalho usando o portal do Azure. Ou então, você pode adicionar algumas etapas a um fluxo de trabalho para depuração no runtime.
Ver o histórico de gatilho
Cada execução de fluxo de trabalho começa com um gatilho, que é acionado em um agendamento ou aguarda uma solicitação ou evento de entrada. Esse histórico de gatilhos relaciona todas as tentativas de disparo que o fluxo de trabalho realizou e informações sobre as entradas e saídas para cada tentativa de disparo. Se o gatilho não for disparado, tente as etapas a seguir.
Para verificar o status do gatilho em seu aplicativo lógico de consumo, examine o histórico de gatilhos. Para exibir mais informações sobre a tentativa do gatilho, selecione esse evento de gatilho, por exemplo:
Verifique as entradas do gatilho para confirmar se elas aparecem conforme o esperado. No painel Histórico, em Link de entradas, selecione o link, que mostra o painel de Entradas.
As entradas do gatilho incluem os dados que o gatilho espera e exigem para iniciar o fluxo de trabalho. A revisão dessas entradas pode ajudar a determinar se as entradas do gatilho estão corretas e se a condição foi atendida para que o fluxo de trabalho possa continuar.
Verifique as saídas de gatilhos, se houver, para confirmar que elas aparecem conforme o esperado. No painel histórico, em Link de saídas, selecione o link, que mostra o painel de Saídas.
As saídas de gatilho incluem os dados que o gatilho passa para a próxima etapa no fluxo de trabalho. A revisão dessas saídas pode ajudar você a determinar se os valores corretos ou esperados foram passados para a próxima etapa do fluxo de trabalho.
Por exemplo, uma mensagem de erro afirma que o feed RSS não foi encontrado:
Dica
Se você encontrar algum conteúdo que não reconheça, saiba mais sobre diferentes tipos de conteúdo em Aplicativos Lógicos do Azure.
Verificar o histórico de execuções do fluxo de trabalho
Sempre que o gatilho é disparado, os Aplicativos Lógicos do Azure criam uma instância de fluxo de trabalho e executam essa instância. Se uma execução falhar, tente as etapas a seguir para examinar o que aconteceu durante essa execução. Você pode examinar o status, as entradas e as saídas de cada etapa no fluxo de trabalho.
Para verificar o status de execução do fluxo de trabalho em seu aplicativo lógico de Consumo, examine o histórico de execuções. Para exibir mais informações sobre uma execução com falha, incluindo todas as etapas em que são executadas em seu status, selecione a execução com falha.
Depois que todas as etapas na execução aparecerem, selecione cada uma delas para expandir suas formas.
Examine as entradas, as saídas e as mensagens de erro para a etapa com falha.
Por exemplo, a captura de tela a seguir mostra as saídas da ação de RSS com falha.
Realizar depuração de runtime
Para ajudar na depuração, você pode adicionar etapas de diagnóstico a um fluxo de trabalho de aplicativo lógico, bem como examinar os históricos de gatilho e de execuções. Por exemplo, você pode adicionar etapas que usam o serviço Webhook Tester para poder inspecionar solicitações HTTP e determinar seu tamanho, forma e formato exatos.
Em um navegador, vá para o site do Webhook Tester e copie a URL exclusiva gerada.
No seu aplicativo lógico, adicione uma ação HTTP POST com o conteúdo do corpo que você deseja testar, como por exemplo, uma expressão ou outra saída da etapa.
Cole a URL do Webhook Tester na ação do HTTP POST.
Para examinar como os Aplicativos Lógicos do Azure geram e formam uma solicitação, execute o fluxo de trabalho do aplicativo lógico. Em seguida, você pode revisitar o site do Webhook Tester para obter mais informações.
Desempenho – FAQ (Perguntas frequentes)
Por que a duração da execução do fluxo de trabalho é maior do que a soma de todas as durações de ação do fluxo de trabalho?
A sobrecarga de agendamento existe ao executar ações, enquanto o tempo de espera entre as ações pode ocorrer devido à carga do sistema de back-end. Uma duração de execução de fluxo de trabalho inclui esses tempos de agendamento e tempos de espera, juntamente com a soma de todas as durações da ação.
Normalmente, meu fluxo de trabalho é concluído em até 10 segundos. Mas, às vezes, a conclusão pode levar muito mais tempo. Como posso garantir que o fluxo de trabalho sempre seja concluído em até 10 segundos?
Não existe nenhuma garantia de SLA sobre latência.
Os fluxos de trabalho de consumo são executados nos Aplicativos Lógicos do Azure multilocatários, portanto, as cargas de trabalho de outros clientes podem afetar negativamente o desempenho do fluxo de trabalho.
Para um desempenho mais previsível, você pode considerar a criação de fluxos de trabalho Standard, que são executados em Aplicativos Lógicos do Azure de locatário único. Você terá mais controle para escalar verticalmente ou para aprimorar o desempenho.
Minha ação atinge o tempo limite após 2 minutos. Como posso aumentar a duração do tempo limite?
A duração do tempo limite da ação não pode ser alterado e é fixado em 2 minutos. Se você estiver usando a ação HTTP e tiver o serviço chamado pela ação HTTP, poderá alterar o serviço para evitar o tempo limite de 2 minutos usando o padrão assíncrono. Para obter mais informações, examine Executar tarefas de longa duração com o padrão de ação de sondagem.
Problemas comuns – Aplicativos lógicos Standard
Artefatos inacessíveis na conta de armazenamento do Azure
Os aplicativos lógicos Standard armazenam todos os artefatos em uma conta de armazenamento do Azure. Você poderá receber os erros a seguir se esses artefatos não estiverem acessíveis. Por exemplo, a conta de armazenamento em si pode não estar acessível, ou pode estar por trás de um firewall, mas sem nenhum ponto de extremidade privado estar configurado para os serviços de armazenamento a serem usados.
Local do portal do Azure | Erro |
---|---|
Painel Visão Geral | - System.private.corelib: O acesso ao caminho 'C:\home\site\wwwroot\host.json' foi negado - Azure.Storage.Blobs: Esta solicitação não está autorizada a executar esta operação |
Painel de fluxos de trabalho | - Não é possível acessar o runtime do host. Detalhes do erro, Código: 'BadRequest', Mensagem: 'Encontrou um erro (InternalServerError) do runtime do host.' - Não é possível acessar o runtime do host. Detalhes do erro, Código: 'BadRequest', Mensagem: 'Encontrou um erro (ServiceUnavailable) do runtime do host.' - Não é possível acessar o runtime do host. Detalhes do erro, Código: 'BadRequest', Mensagem: 'Encontrou um erro (BadGateway) do runtime do host.' |
Durante a criação e a execução do fluxo de trabalho | - Falha ao salvar o fluxo de trabalho - Erro no designer: GetCallFailed. Operações de busca com falha - Falha na chamada ajaxExtended |
Opções de solução de problemas
A lista a seguir inclui possíveis causas para esses erros e etapas para ajudar a solucionar problemas.
Para uma conta de armazenamento pública, verifique o acesso à conta de armazenamento das seguintes maneiras:
Verifique a conectividade da conta de armazenamento usando o Gerenciador de Armazenamento do Azure.
Nas configurações de seu recurso de aplicativo lógico, confirme a cadeia de conexão da conta de armazenamento nas configurações do aplicativo, AzureWebJobsStorage e WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Para obter mais informações, consulte Configurações de host e aplicativo para aplicativos lógicos nos Aplicativos Lógicos do Azure de locatário único.
Se a conectividade falhar, verifique se a chave de SAS (Assinatura de Acesso Compartilhado) na cadeia de conexão é a mais recente.
Importante
Quando houver informações confidenciais, como cadeias de conexão que incluam nomes de usuário e senhas, certifique-se de usar o fluxo de autenticação mais seguro disponível. Por exemplo, nos fluxos de trabalho de aplicativo lógico Standard, não há suporte para tipos de dados seguros, como
securestring
esecureobject
. A Microsoft recomenda autenticar o acesso aos recursos do Azure com uma identidade gerenciada quando possível e atribuir uma função que tenha o privilégio mínimo necessário.Se essa funcionalidade não estiver disponível, certifique-se de proteger cadeias de conexão por meio de outras medidas, como
Azure Key Vault, que você pode usar com as configurações do aplicativo. Em seguida, você pode fazer referência direta a cadeias de caracteres seguras, como cadeias de conexão e chaves. De modo semelhante aos modelos do ARM, em que é possível definir variáveis de ambiente no momento da implantação, você pode definir as configurações de aplicativo na definição de fluxo de trabalho do aplicativo lógico. Em seguida, você pode capturar os valores da infraestrutura gerados dinamicamente, como pontos de extremidade de conexão, cadeias de caracteres de armazenamento, entre outros. Para obter mais informações, confira Tipos de aplicativo para a plataforma de identidade da Microsoft.
Para uma conta de armazenamento que está por trás de um firewall, verifique o acesso à conta de armazenamento das seguintes maneiras:
Se as restrições de firewall estiverem habilitadas na conta de armazenamento, verifique se os pontos de extremidade privados estão configurados para os serviços de Armazenamento de Blobs, Arquivos, Tabelas e Filas.
Verifique a conectividade da conta de armazenamento usando o Gerenciador de Armazenamento do Azure.
Se encontrar problemas de conectividade, prossiga com estas etapas:
Na mesma rede virtual integrada ao seu aplicativo lógico, crie uma máquina virtual do Azure, que você pode colocar em uma sub-rede diferente.
Em um prompt de comando, execute nslookup para verificar se os serviços de Armazenamento de Blobs, Arquivos, Tabelas e Filas são resolvidos para os endereços IP esperados.
Sintaxe:
nslookup [StorageaccountHostName] [OptionalDNSServer]
Blob:
nslookup {StorageaccountName}.blob.core.windows.net
Arquivo:
nslookup {StorageaccountName}.file.core.windows.net
Tabela:
nslookup {StorageaccountName}.table.core.windows.net
Fila:
nslookup {StorageaccountName}.queue.core.windows.net
Se o serviço de armazenamento tiver um Ponto de extremidade de serviço, o ele será resolvido para um endereço IP público.
Se o serviço de armazenamento tiver um ponto de extremidade privado, ele será resolvido para os endereços IP privados do respectivo NIC (controlador de adaptador de rede).
Se as consultas de DNS (servidor de nomes de domínio) anteriores forem resolvidas com êxito, execute os comandos psping ou tcpping para verificar a conectividade com a conta de armazenamento pela porta 443:
Sintaxe:
psping [StorageaccountHostName] [Port] [OptionalDNSServer]
Blob:
psping {StorageaccountName}.blob.core.windows.net:443
Arquivo:
psping {StorageaccountName}.file.core.windows.net:443
Tabela:
psping {StorageaccountName}.table.core.windows.net:443
Fila:
psping {StorageaccountName}.queue.core.windows.net:443
Se cada serviço de armazenamento puder ser resolvido em sua máquina virtual do Azure, localize o DNS usado pela máquina virtual para resolução.
Defina a configuração WEBSITE_DNS_SERVER do aplicativo lógico para o DNS e confirme se o DNS funciona com êxito.
Confirme se a integração da VNet está configurada corretamente com a rede virtual e a sub-rede apropriadas em seu aplicativo lógico Standard.
Se você usar zonas DNS do Azure privadas para ps serviços de ponto de extremidade privado da conta de armazenamento, verifique se um link de rede virtual foi criado para a rede virtual integrada do aplicativo lógico.
Para obter mais informações, examine Implantar um aplicativo lógico Standard em uma conta de armazenamento por trás de um firewall usando pontos de extremidade privados ou de serviço.