Azure Stream Analytics のクエリのトラブルシューティング

  • [アーティクル]

この記事では、Stream Analytics のクエリの開発に関する一般的な問題と、そのトラブルシューティングの方法について説明します。

この記事では、Azure Stream Analytics クエリの開発に関する一般的な問題、クエリの問題のトラブルシューティングの方法、および問題を修正する方法について説明します。 多くのトラブルシューティングの手順では、Stream Analytics ジョブに対してリソース ログを有効にする必要があります。 リソース ログが有効になっていない場合は、「リソース ログを使用した Azure Stream Analytics のトラブルシューティング」を参照してください。

クエリが予想される出力を生成しない

  1. ローカルでテストしてエラーを調査します。

    • Azure portal の [クエリ] タブで [テスト] を選択します。 ダウンロードしたサンプル データを使用してクエリをテストします。 すべてのエラーを調査し、修正を試みます。
    • また、Visual Studio の Azure Stream Analytics ツール、または Visual Studio Code を使用して、クエリをローカルでテストすることもできます。

  2. Visual Studio Code の Azure Stream Analytics ツールで、ジョブ ダイアグラムを使用して段階を追ってローカルでクエリをデバッグします。 ジョブ ダイアグラムには、入力ソース (イベント ハブ、IoT Hub など) のデータが複数のクエリ手順を介して最終的に出力シンクまでどのように流れるかが示されます。 各クエリ ステップは、WITH ステートメントを使用してスクリプトに定義された一時的結果セットにマップされます。 各中間結果セット内のデータとメトリックを表示して、問題の原因を見つけることができます。

    Job diagram preview result

  3. Timestamp By を使用する場合は、イベントのタイムスタンプがジョブの開始時刻より後であることを確認します。

  4. よくある次のような問題を解消する。

    • クエリ内の WHERE 句がイベントをすべて除外してしまっている。この場合、出力が生成されません。
    • CAST 関数が失敗したため、ジョブが失敗する。 型キャスト エラーを回避するには、代わりに TRY_CAST を使用します。
    • ウィンドウ関数を使用している場合に、ウィンドウ時間が終わっていない。ウィンドウ時間が完了し、クエリの出力が表示されるのを待つ必要があります。
    • イベントのタイムスタンプがジョブの開始時刻よりも前になっている。イベントがドロップされてしまいます。
    • JOIN 条件が一致しない。 どれとも一致しない場合は、出力は 0 個になります。

  5. イベント順序ポリシーが期待どおりに構成されていることを確認します。 [設定] に移動し、[イベント順序] を選択します。 このポリシーは、 [テスト] ボタンを使用してクエリをテストする場合には適用 "されません"。 この結果が、ブラウザーでテストする場合と、運用環境でジョブを実行する場合の相違点の 1 つです。

  6. アクティビティとリソース ログを使用したデバッグ:

リソース使用率が高い

Azure Stream Analytics で並列処理を活用していることを確認します。 入力パーティションの構成と分析クエリ定義のチューニングによって、Stream Analytics ジョブのクエリ並列処理を使用してスケーリングすることをお勧めします。

リソース使用率が常に 80% を超え、透かしの遅延が増加し、バックログされたイベントの数が増加している場合は、ストリーミング ユニットを増やすことを検討してください。 使用率が高い場合は、最大数に近い割り当てリソースがジョブによって使用されていることを示します。

クエリを段階的にデバッグする

リアルタイムのデータ処理では、クエリの実行中にデータの状況を把握することが役に立つ場合があります。 これは、Visual Studio のジョブ ダイアグラムを使用して確認できます。 Visual Studio がない場合は、中間データを出力するための追加の手順を実行できます。

Azure Stream Analytics ジョブの入力またはステップは複数回読み取ることができるため、追加の SELECT INTO ステートメントを記述することができます。 これを実行すると、中間データがストレージに出力され、データの正確性を確認できるようになります。これは、プログラムをデバッグする際に "watch 変数" によって行われる確認とまったく同じです。

Azure Stream Analytics ジョブの次のサンプル クエリには、1 つのストリーム入力と 2 つの参照データ入力があり、Azure Table Storage に出力が行われます。 このクエリはイベント ハブと 2 つの参照 BLOB からのデータを結合し、名前とカテゴリの情報を取得します。

Example Stream Analytics SELECT INTO query

ジョブが実行中なのに出力でイベントが生成されていないことに注意してください。 次に示す [監視] タイルでは、入力からデータが生成中であることがわかります。しかし、JOIN のどのステップが原因ですべてのイベントが欠落したのかはわかりません。

The Stream Analytics Monitoring tile

この状況では、いくつかの SELECT INTO ステートメントを追加して、JOIN の中間結果と入力から読み取られたデータの "ログを記録" することができます。

この例では、2 つの "一時的な出力" を新しく追加しました。これらの出力には任意のシンクを使用してかまいません。 ここでは例として Azure Storage を使用します。

Adding extra SELECT INTO statements to Stream Analytics query

クエリは次のように書き換えることができます。

Rewritten SELECT INTO Stream Analytics query

もう一度ジョブを開始して、数分間実行します。 temp1 と temp2 の各クエリによって、Visual Studio Cloud Explorer で次のテーブルが生成されます。

temp1 テーブルSELECT INTO temp1 table Stream Analytics query

temp2 テーブルSELECT INTO temp2 table Stream Analytics query

ご覧のとおり、temp1 と temp2 のどちらにもデータがあり、temp2 では名前列が正しく入力されています。 しかし出力には依然としてデータがなく、何らかの問題が発生していることがわかります。

SELECT INTO output1 table with no data Stream Analytics query

データをサンプリングすることで、2 番目の JOIN に問題があることがほぼ確実にわかります。 BLOB から参照データをダウンロードして確認できます。

SELECT INTO ref table Stream Analytics query

ご覧のとおり、この参照データの GUID の形式が temp2 の "from" 列の形式と異なります。 これが、データが想定どおりに output1 に届かなかった原因です。

データ形式を修正して参照 BLOB にアップロードし、やり直すことができます。

SELECT INTO temp table Stream Analytics query

今度は、出力のデータが想定どおりに書式設定されて入力されます。

SELECT INTO final table Stream Analytics query

ヘルプを参照する

詳細については、Azure Stream Analytics に関する Microsoft Q&A 質問ページを参照してください。

次のステップ