Partilhar via

Solucionar problemas de saídas do Azure Stream Analytics

  • Artigo

Este artigo descreve problemas comuns com conexões de saída do Azure Stream Analytics e como solucionar problemas de saída. Muitas etapas de solução de problemas exigem que os logs de diagnóstico e recursos sejam habilitados para seu trabalho do Stream Analytics. Se você não tiver logs de recursos habilitados, consulte Solucionar problemas do Azure Stream Analytics usando logs de recursos.

O trabalho não produz resultados

  1. Verifique a conectividade com as saídas usando o botão Testar conexão para cada saída.

  2. Veja o trabalho do Monitor Stream Analytics com o portal do Azure na guia Monitor. Como os valores são agregados, as métricas são atrasadas em alguns minutos.

    • Se o valor de Eventos de Entrada for maior que zero, o trabalho poderá ler os dados de entrada. Se o valor de Eventos de Entrada não for maior que zero, haverá um problema com a entrada do trabalho. Consulte Solucionar problemas de conexões de entrada para obter mais informações. Se o seu trabalho tiver entrada de dados de referência, aplique a divisão por nome lógico ao examinar a métrica Eventos de Entrada . Se não houver eventos de entrada apenas dos seus dados de referência, isso provavelmente significa que essa fonte de entrada não foi configurada corretamente para buscar o conjunto de dados de referência correto.
    • Se o valor de Erros de Conversão de Dados for maior que zero e estiver subindo, consulte Erros de dados do Azure Stream Analytics para obter informações detalhadas sobre erros de conversão de dados.
    • Se o valor de Erros de Tempo de Execução for maior que zero, seu trabalho receberá dados, mas gerará erros durante o processamento da consulta. Para localizar os erros, vá para os logs de auditoria e filtre o status Falha.
    • Se o valor de Eventos de Entrada for maior que zero e o valor de Eventos de Saída for igual a zero, uma das seguintes instruções será verdadeira:
      • O processamento da consulta resultou em zero eventos de saída.
      • Eventos ou campos podem estar malformados, resultando em uma saída zero após o processamento da consulta.
      • O trabalho não pôde enviar dados para o coletor de saída por motivos de conectividade ou autenticação.

    As mensagens do log de operações explicam detalhes adicionais, incluindo o que está acontecendo, exceto nos casos em que a lógica de consulta filtra todos os eventos. Se o processamento de vários eventos gerar erros, os erros serão agregados a cada 10 minutos.

A primeira saída está atrasada

Quando um trabalho do Stream Analytics é iniciado, os eventos de entrada são lidos. Mas, pode haver um atraso na saída, em certas circunstâncias.

Grandes valores de tempo em elementos de consulta temporal podem contribuir para o atraso de saída. Para produzir a saída correta em grandes janelas de tempo, o trabalho de streaming lê dados da última hora possível para preencher a janela de tempo. Os dados podem durar até sete dias. Nenhuma saída produz até que os eventos de entrada pendentes sejam lidos. Esse problema pode surgir quando o sistema atualiza os trabalhos de streaming. Quando ocorre uma atualização, o trabalho é reiniciado. Essas atualizações geralmente ocorrem uma vez a cada dois meses.

Use discrição ao projetar sua consulta do Stream Analytics. Se você usar uma grande janela de tempo para elementos temporais na sintaxe de consulta do trabalho, isso pode levar a um atraso na primeira saída quando o trabalho for iniciado ou reiniciado. Mais do que várias horas, até sete dias, é considerado uma grande janela de tempo.

Uma atenuação para esse tipo de atraso de primeira saída é usar técnicas de paralelização de consulta, como particionar os dados. Ou, você pode adicionar mais unidades de streaming para melhorar a taxa de transferência até que o trabalho se recupere. Para obter mais informações, consulte Considerações ao criar trabalhos do Stream Analytics.

Esses fatores afetam a pontualidade da primeira saída:

  • O uso de agregados com janelas, como uma cláusula GROUP BY de janelas de tombamento, salto e deslizamento:

    • Para agregados de janela de tombo ou salto, os resultados são gerados no final do período de tempo da janela.
    • Para uma janela deslizante, os resultados são gerados quando um evento entra ou sai da janela deslizante.
    • Se você estiver planejando usar uma janela grande, como mais de uma hora, é melhor escolher uma janela de salto ou deslizamento. Esses tipos de janela permitem que você veja a saída com mais frequência.

  • O uso de junções temporais, como JOIN com DATEDIFF:

    • As partidas são geradas assim que ambos os lados dos eventos combinados chegam.
    • Os dados que não possuem uma correspondência, como LEFT OUTER JOIN, são gerados no final da janela DATEDIFF, para cada evento do lado esquerdo.

  • O uso de funções analíticas temporais, como ISFIRST, LAST e LAG com LIMIT DURATION:

    • Para funções analíticas, a saída é gerada para cada evento. Não há atraso.

A produção fica para trás

Durante a operação normal de um trabalho, a saída pode ter períodos cada vez mais longos de latência. Se a saída ficar para trás assim, você pode identificar as causas raiz examinando os seguintes fatores:

  • Se o sumidouro a jusante está acelerado
  • Se a fonte a montante está limitada
  • Se a lógica de processamento na consulta é de computação intensiva

Para ver os detalhes de saída, selecione o trabalho de streaming no portal do Azure e, em seguida, selecione Diagrama de trabalho. Para cada entrada, há uma métrica de evento de lista de pendências por partição. Se a métrica continuar aumentando, é um indicador de que os recursos do sistema estão limitados. O aumento é potencialmente devido à limitação do coletor de saída ou ao alto uso da CPU. Para obter mais informações, consulte Depuração controlada por dados usando o diagrama de trabalho.

Aviso de violação de chave com saída do Banco de Dados SQL do Azure

Quando você configura um banco de dados SQL do Azure como saída para um trabalho do Stream Analytics, ele insere registros em massa na tabela de destino. Em geral, o Azure Stream Analytics garante pelo menos uma entrega no coletor de saída. Você ainda pode obter a entrega exata uma vez para uma saída SQL quando uma tabela SQL tem uma restrição exclusiva definida.

Quando você configura restrições de chave exclusivas na tabela SQL, o Azure Stream Analytics remove registros duplicados. Ele divide os dados em lotes e insere recursivamente os lotes até que um único registro duplicado seja encontrado. O processo de divisão e inserção ignora as duplicatas uma de cada vez. Para um trabalho de streaming que tem muitas linhas duplicadas, o processo é ineficiente e demorado. Se você vir várias mensagens de aviso de violação de chave em seu log de atividades da hora anterior, é provável que sua saída SQL esteja atrasando todo o trabalho.

Para resolver esse problema, configure o índice que está causando a violação de chave habilitando a opção IGNORE_DUP_KEY. Essa opção permite que o SQL ignore valores duplicados durante inserções em massa. O Banco de Dados SQL do Azure simplesmente produz uma mensagem de aviso em vez de um erro. Como resultado, o Azure Stream Analytics não produz mais erros de violação de chave primária.

Observe as seguintes observações ao configurar IGNORE_DUP_KEY para vários tipos de índices:

  • Não é possível definir IGNORE_DUP_KEY em uma chave primária ou uma restrição exclusiva que use ALTER INDEX. Você precisa soltar o índice e recriá-lo.
  • Você pode definir IGNORE_DUP_KEY usando ALTER INDEX para um índice exclusivo. Esta instância é diferente de uma restrição PRIMARY KEY/UNIQUE e é criada usando uma definição CREATE INDEX ou INDEX.
  • A opção IGNORE_DUP_KEY não se aplica a índices de armazenamento de colunas porque você não pode impor exclusividade a eles.

Lógica de repetição de saída SQL

Quando um trabalho do Stream Analytics com saída SQL recebe o primeiro lote de eventos, as seguintes etapas ocorrem:

  1. O trabalho tenta se conectar ao SQL.
  2. O trabalho busca o esquema da tabela de destino.
  3. O trabalho valida nomes e tipos de coluna em relação ao esquema da tabela de destino.
  4. O trabalho prepara uma tabela de dados na memória a partir dos registros de saída no lote.
  5. O trabalho grava a tabela de dados no SQL usando a API BulkCopy.

Durante essas etapas, a saída SQL pode enfrentar os seguintes tipos de erros:

  • Erros transitórios que são repetidos usando uma estratégia de repetição de backoff exponencial. O intervalo mínimo de repetição depende do código de erro individual, mas os intervalos são normalmente inferiores a 60 segundos. O limite máximo pode ser de, no máximo, cinco minutos.

    Falhas de login e problemas de firewall são repetidos pelo menos 5 minutos após a tentativa anterior e são repetidos até que sejam bem-sucedidos.

  • Os erros de dados, como erros de transmissão e violações de restrição de esquema, são tratados com a política de erro de saída. Esses erros são tratados tentando novamente lotes binários divididos até que o registro individual que causa o erro seja tratado ignorando ou repetindo. A violação de restrição de chave exclusiva primária é sempre tratada.

  • Erros não transitórios podem acontecer quando há problemas de serviço SQL ou defeitos de código interno. Por exemplo, quando erros como (Código 1132) Elastic Pool atingem seu limite de armazenamento, novas tentativas não resolvem o erro. Nesses cenários, o trabalho do Stream Analytics sofre degradação.

  • BulkCopy os tempos limite podem acontecer durante BulkCopy o Passo 5. BulkCopy pode experimentar tempos limite de operação ocasionalmente. O tempo limite mínimo configurado padrão é de cinco minutos e é dobrado quando atingido consecutivamente. Quando o tempo limite estiver acima de 15 minutos, a dica de tamanho máximo do lote é BulkCopy reduzida para metade até que restem 100 eventos por lote.

    Importante

    Para trabalhos ASA não injetados na rede, não confie no endereço IP de origem das conexões provenientes do ASA de forma alguma. Eles podem ser IPs públicos ou privados, dependendo das operações de infraestrutura de serviço que acontecem de tempos em tempos.

Os nomes das colunas são minúsculos no Azure Stream Analytics (1.0)

Ao usar o nível de compatibilidade original (1.0), o Azure Stream Analytics altera os nomes das colunas para minúsculas. Esse comportamento foi corrigido em níveis de compatibilidade posteriores. Para preservar o caso, passe para o nível de compatibilidade 1.1 ou posterior. Para obter mais informações, consulte Nível de compatibilidade para trabalhos do Stream Analytics.

Obter ajuda

Para obter mais assistência, experimente a nossa página de perguntas e respostas da Microsoft para o Azure Stream Analytics.

Próximos passos