1. GoldenGate Stream Analyticsのトラブルシューティング
  2. Oracle Stream Analyticsのトラブルシューティング

1 Oracle Stream Analyticsのトラブルシューティング

Oracle Stream Analyticsは、イベントのストリームをリアルタイムで分析およびモニターするために使用します。ストリーム処理ソリューションをモデル化するためのパイプラインを作成できます。通常、Oracle Stream Analyticsパイプラインは、明示的に停止されるか、障害が発生するまで、長時間継続的に実行されます。このドキュメントには、パイプラインの作成、実行またはデプロイ中に発生する可能性がある様々な問題をトラブルシューティングするために必要な情報が含まれています。

1.1 パイプラインのデバッグおよびモニタリング・メトリック

実行されているOracle Stream Analyticsパイプラインごとに、対応するSparkアプリケーションがSparkクラスタにデプロイされています。Oracle Stream Analyticsパイプラインがドラフト・モードまたはパブリッシュ・モードでデプロイおよび実行されている場合、ユーザーは、Oracle Stream Analyticsによって提供されるリアルタイム・メトリックを使用して、対応するSparkアプリケーションをモニターおよび分析できます。これらのメトリックにより、すべてのパイプライン・ステージに対する詳細な実行時インサイトが提供され、ユーザーは、演算子レベルの詳細までドリルダウンできます。これらのメトリックは、Sparkが提供するメトリックに対して追加されています。Oracle Stream Analyticsには、アプリケーションごとに詳細なモニタリング・メトリックが用意され、このメトリックを使用して、パイプラインが期待どおりに動作しているかどうかを分析できます。

次の各トピックでは、モニタリングおよびデバッグのメトリックにアクセスする方法について説明します。

1.1.1 Sparkスタンドアロン

Sparkスタンドアロンで実行している場合、Spark Master URLは、Spark REST URLフィールドのホスト名にSparkスタンドアロン・マスター・コンソール・ポート・フィールドを加えたものと同じです。Spark Master URLは、http://<Spark REST URL>:< Spark standalone master console port>です。「システム設定」ページからSpark Master URLを取得できます。

「Spark Master」ページには、実行中のアプリケーションのリストも表示されます。アプリケーションID、名前、所有者、現在のステータスなどの詳細を表示するには、アプリケーションをクリックします。

「パブリッシュ済」ステータスのパイプラインの場合、GGSAのカタログ・ページからメトリック・コンソールに移動できます(次のスクリーンショットを参照)。

アプリケーション・マスター・コンソール・アイコン
次のスクリーンショットに示すように、公開されたアプリケーションのステータスはカタログ・ページで確認できます:

アプリケーション・ステータス - 実行中

アプリケーション・ステータス - 停止済

1.1.2 Spark on YARN

パブリッシュ済のパイプラインの場合は、GoldenGate Stream Analyticsのカタログ・ページからアプリケーション・マスター・コンソールに移動する方が簡単です。

  1. ドラフト・パイプラインの場合、「システム設定」のYARNリソース・マネージャURLおよびYARNマスター・コンソール・ポートの値を使用して、YARNアプリケーション・ページに移動できます。

  2. アプリケーション・マスターURLは、http://<YARN Resource Manager URL>:<Yarn master Console Port>です。

    このページには、YARNで実行されているすべてのアプリケーションが表示されます:Yarnで実行中のアプリケーション

  3. リストからアプリケーションを特定した後で、「ApplicationMaster」リンクをクリックすると、Sparkアプリケーションの詳細ページが開きます。

    Sparkアプリケーションの詳細ページ

1.1.3 パイプライン詳細

「パイプライン」タブをクリックして、パイプラインの詳細ページを表示します。pipeline_details_page.pngの説明が続きます
図pipeline_details_page.pngの説明

このページには、パイプラインに関する次の情報が含まれます。

  • Pipeline ID: Sparkクラスタの一意のパイプラインID

  • Pipeline Name: Oracle Stream Analytics UIでユーザーが指定したOracle Stream Analyticsパイプラインの名前。

  • パイプライン・ステージ表: このセクションには、各パイプライン・ステージの詳細なランタイム・メトリックを含む表が表示されます。表の各エントリは、Oracle Stream Analytics UIのパイプライン・グラフのパイプライン・ステージに対応しています。

  • Pipeline DAG: これは、DAGの形式ですべてのステージをビジュアルに表現したもので、親子関係の様々なパイプライン・ステージが表示されます。この図には、各パイプライン・ステージ内での変換に関する情報も表示されます。

  • パイプライン・ステージ表には次の列があります。

  • Total Number of Transformations: この測定値は、各ステージの計算に適用されたSpark変換の数です。

    Oracle Stream Analyticsでは、問合せステージ、パターン・ステージ、カスタム・ステージなどの様々なタイプのステージがサポートされます。パイプライン・ステージごとに、Oracle Stream Analyticsによって、ステージの入力ストリームに適用される変換のリストが定義されます。最終変換からの出力が、ステージの出力になります。

  • Total Output Partitions: この測定値は、各ステージの出力ストリームに含まれるパーティションの合計数です。

    すべてのパイプライン・ステージには、ステージ構成によって決定される独自のパーティション化要件があります。たとえば、問合せステージでサマリー関数を定義して、グループ化基準列を定義しない場合、使用可能なパーティション化基準が存在しないため、問合せステージには1つのパーティションのみが含まれます。

  • Total Output Events: この測定値は、各ステージで発生した出力イベント(マイクロ・バッチ以外)の合計数です。

  • Average Output Rate: この測定値は、各ステージがこれまでに出力イベントを発生させた割合です。この割合は、これまでの出力イベントの合計数とアプリケーションの合計実行時間の比率です。

    割合が0 (ゼロ)の場合でも、常にステージ処理でのエラーを意味するわけではありません。ステージでレコードが1つも出力されないこともあります(問合せステージのフィルタを通過したイベントが1つもなかった場合など)。これは、出力イベントの割合が、1イベント/秒を下回る場合に発生することがあります。

  • Current Output Rate: この測定値は、各ステージが出力イベントを発生させている割合です。この割合は、メトリック・ページが最後にリフレッシュされて以降の、出力イベントの合計数とアプリケーションの合計実行時間の比率です。現在の出力率をより適切に把握するには、ページのリフレッシュ頻度を増やしてください。

1.1.4 ステージ詳細

パイプライン・ステージ表の「名前」列の名前をクリックして、ステージの詳細ページに移動します。ステージ詳細ページ

このページには、特定のステージ内でのすべての変換に関する詳細が表示されます。

  • Pipeline ID: Sparkクラスタの一意のパイプラインID

  • Pipeline Name: Oracle Stream Analytics UIでユーザーが指定したOracle Stream Analyticsパイプラインの名前。

  • Stage ID: Oracle Stream AnalyticsパイプラインのステージのDAGにおける一意のステージID。

  • ステージDAG: これは、DAGの形式ですべての変換をビジュアルに表現したもので、親子関係の様々なパイプライン変換が表示されます。

    Oracle Stream Analyticsではビジネス・ルールを含む様々な変換タイプを使用できますが、ドリルダウンできるのはCQLDStream変換のみです。CQLDStream変換内で、入力データは、CQLエンジンの継続実行問合せ(CQL)を使用して変換されます。1つのCQLエンジンは、1つのエグゼキュータに関連付けられます。

  • ステージ変換表: この表には、特定のステージで実行されているすべての変換に関する詳細が表示されます。表の各エントリは、ステージの計算に使用される変換操作に対応しています。すべてのステージの最終変換がMonitorDStreamであることを確認できます。その理由は、MonitorDStreamがステージの出力をOracle Stream Analytics UIのライブ表にパイプしているためです。

    • Transformation Name: 変換の出力DStreamの名前。Sparkのすべての変換は、出力DStreamに取得されます。

    • Transformation Type: これは、ステージ実行で使用されている各変換のカテゴリ情報です。変換タイプが「Oracle」の場合、これはオラクル社固有の変換アルゴリズムに基づきます。変換タイプが「Native」の場合、変換はApache Spark実装により提供されます。

CQLDStream変換は、さらにドリルダウンできます(「問合せ詳細」を参照)。

1.1.5 問合せ詳細

ステージ変換表で、CQLDStream変換をクリックし、問合せ固有の詳細を表示するCQLエンジン・サマリー・ページを開きます。

CQLエンジン・サマリー・ページ

問合せのCQLエンジン・サマリー・ページには、問合せテキスト、問合せをフィードするストリーム・ソース、外部ソース(ある場合)、問合せを登録するすべてのCQLエンジンなどの詳細が表示されます。

1.1.6 実行およびHA統計

CQLエンジン・サマリー・ページで、問合せをクリックします。CQLエンジン・サマリー・ページ

表示されるCQLエンジン問合せの詳細ページで、実行およびHA統計を確認できます。CQLエンジン問合せの詳細ページ

  1. 次に、このページに表示される詳細を示します。

    • Query ID: 問合せのシステム生成の識別子

    • Query Text: 問合せ文字列

    • パーティション数: このフィールドには、問合せの並列度が表示されます。並列度は、問合せで処理される入力パーティションの合計数によって定義されます。

      並列度は、問合せ構文、入力Kafkaパーティションの数、アプリケーションに割り当てられたエグゼキュータの数など、多くの要因に応じて変化します。

    • 実行統計表: このセクションには、各演算子の詳細な実行統計が表示されます。

      • Partition ID: パーティションの順序ID

      • CQL Engine ID: パーティションが処理されているCQLエンジンの順序ID。

      • Total Output Events: 各パーティションのCQL問合せで発生した出力イベントの数。

      • Total Output Heartbeats: 各パーティションのCQL問合せで発生したハートビート・イベントの数。ハートビートは、Oracle Stream Analyticsパイプラインのタイムスタンプの連続を保証する特別なイベントであることに注意してください。

      • Throughput: 処理されたイベントの合計数と、各パーティションでの処理に要した合計時間の比率。

      • Latency: ストリームのパーティションを処理するためにかかった平均所要時間。

    • HA Statistics: この表には、問合せのHA操作に関するリアルタイム統計が表示されます。時間の単位は、ミリ秒であることに注意してください。

      • Partition ID: パーティションの順序ID

      • CQL Engine ID: パーティションが処理されているCQLエンジンの順序ID。

      • Total Full Snapshots Created: 問合せの完全な状態がシリアライズされて保存された合計回数。

      • Avg Full Snapshot Creation Time: 問合せの完全な状態がシリアライズされて保存されるのに要した平均時間。

      • Total Full Snapshots Loaded: 問合せの完全な状態がデシリアライズされて問合せ計画にロードされた合計回数。

      • Avg Full Snapshot Load Time: 問合せの完全な状態がデシリアライズされてロードされるのに要した平均時間。

      • Total Journal Snapshots Created: 問合せのジャーナル化状態がシリアライズされて保存された合計回数。

      • Avg Journal Snapshot Creation Time: 問合せのジャーナル化状態がシリアライズされて保存されるのに要した平均時間。

      • Total Journal Snapshots Loaded: 問合せのジャーナル化状態がデシリアライズされて問合せ計画にロードされた合計回数。

      • Avg Journal Snapshot Load Time: 問合せのジャーナル化状態がデシリアライズされてロードされるのに要した平均時間。

        完全スナップショットは、問合せの完全な状態です。問合せの状態は、問合せ計画の各演算子の内部データ構造および状態を表します。ジャーナル・スナップショットは、開始時間と終了時間のある部分的かつ増分的なスナップショットです。Oracle Stream Analyticsは、可能であればジャーナル・スナップショットを使用して状態の保存を最適化します。

1.1.7 詳細な問合せ分析

「実行統計」表で特定のパーティションをクリックすると、CQLエンジンの詳細な問合せ分析ページが表示されます。CQLエンジンの詳細な問合せ分析

このページには、パイプラインのステージの特定のパーティションに対するCQL問合せの各実行演算子に関する詳細が含まれます。

  • Query ID: 問合せのシステム生成の識別子

  • Query Text: 問合せ文字列

  • Partition ID: すべての演算子の詳細は、このパーティションIDに対応しています。

  • 演算子の統計:

    • Operator ID: システム生成の識別子

    • Total Input Events: 各演算子が受信した入力イベントの合計数。

    • Total Output Events: 各演算子が生成した出力イベントの合計数。

    • Total Input Heartbeats: 各演算子が受信したハートビート・イベントの合計数。

    • Total Output Heartbeats: 各演算子が生成したハートビート・イベントの合計数。

    • Throughput(events/second): 処理された入力イベントの合計と、各演算子での処理に要した合計時間の比率。

    • Latency(ms): 各演算子のイベントを処理するためにかかった合計所要時間。

  • Operator DAG: これは、問合せ計画をビジュアルに表現したものです。DAGには、各演算子の親子の詳細が表示されます。演算子の実行統計をさらにドリルダウンできます。演算子をクリックして、「CQL Operator Details」ページを開いてください。

1.1.8 詳細なCQLエンジン統計

CQLエンジンタブをクリックすると、パイプライン内のすべてのステージおよびすべての問合せに関する完全なCQLエンジン統計が表示されます。CQLエンジンタブ

このページには、CQLエンジン問合せの詳細ページとは別に、各実行演算子に関する追加情報が含まれ、各演算子のすべての必須メトリックが表示されます。

Pipeline ID: Sparkクラスタの一意のパイプラインID

Pipeline Name: Oracle Stream Analytics UIでユーザーが指定したOracle Stream Analyticsパイプラインの名前。

ステージID: Oracle Stream AnalyticsパイプラインのステージのDAGにおける一意のステージID。

Running Queries: このセクションには、ステージのCQL変換を計算するために実行されているCQL問合せのリストが表示されます。この表には、システム生成の問合せIDと問合せテキストが表示されます。CQL問合せの構文とセマンティクスについては、Oracle連続問合せ言語リファレンスを参照してください。問合せの詳細を参照するには、表エントリの問合せIDのハイパーリンクをクリックして、「CQL Engine Query Details」ページを開きます。

Registered Sources: このセクションには、問合せの基盤となるすべての入力ソースに関する内部CQLメタデータが表示されます。ステージの入力ストリームごとに、1つのエントリがこの表に表示されます。

各エントリには、ソース名、ソース・タイプ、タイムスタンプ・タイプおよびストリーム属性が含まれます。タイムスタンプ・タイプには、PROCESSINGまたはEVENTのタイムスタンプがあります。ストリームがPROCESSINGのタイムスタンプの場合、各イベントのタイムスタンプは、システムによって定義されます。ストリームがEVENTのタイムスタンプの場合、各イベントのタイムスタンプは、ストリーム属性自体のいずれかによって定義されます。ソースは、ストリームまたはリレーションです。

External Sources: このセクションには、入力ストリームが結合されるすべての外部ソースの詳細が表示されます。外部ソースは、データベース表またはCoherenceキャッシュです。

CQL Engines: このセクションには、パイプラインによって使用されるCQLエンジンのすべてのインスタンスの詳細を含む表が表示されます。次に、表の各フィールドの詳細を示します。

  • CQLEngine Id: CQLエンジン・インスタンスのシステム生成のID。
  • ExecutorId: CQLエンジンが関連付けられているエグゼキュータID。
  • Executor Host: このCQLエンジンが実行されているクラスタ・ノードのアドレス。
  • Status: CQLエンジンの現在のステータス。ステータスは、ACTIVEまたはINACTIVEのいずれかです。ACTIVEの場合、CQLエンジン・インスタンスは起動して実行中であり、それ以外の場合、CQLエンジンは明示的に停止されています。

1.1.9 内部Kafkaトピック

GGSAで使用される内部KafkaトピックおよびグループIDは、次のネーミング規則に従って標準化されます:

Kafkaトピック

トピック リソース 操作

sx_backend_notification_<UUID>

 トピック CREATE、DELETE、DESCRIBE、READ、WRITE

sx_messages_<UUID>

トピック CREATE、DELETE、DESCRIBE、READ、WRITE

sx_<application_name>_<stage_name>_public

 トピック CREATE、DELETE、DESCRIBE、READ、WRITE

sx_<application_name>_<stage_name>_draft

 トピック CREATE、DELETE、DESCRIBE、READ、WRITE

sx_<application_name>_public_<offset_number>_<stage_name>_offset

 トピック CREATE、DELETE、DESCRIBE、READ、WRITE

グループID

グループID リソース 操作

sx_<UUID>_receiver

 グループ DESCRIBE、READ

sx_<UUID>

 グループ DESCRIBE、READ

sx_<application_name>_public_<offset_number>_<stage_name>

 グループ DESCRIBE、READ

1.2 一般的な問題および処置

この項では、パイプラインが正常に実行されていないかどうかを確認する項目の包括的なリストを提供します。

1.2.1 システム設定

この項では、システム設定で発生する一般的な問題をリストします。

1.2.1.1 SQL問合せ構成

「システム設定」のSQL問合せ構成からカスタム問合せを作成して参照する表にアクセスすると、表名を使用してシノニムを作成しないかぎり、パイプラインが失敗します。

たとえば、ユーザーOSA1から表OSA2.REF_TBLにアクセスするには、次を使用してユーザーOSA1からシノニムを作成します
Create synonym REF_TBL for OSA2.REF_TBL
1.2.1.2 YarnクラスタでのVMメモリーの問題

Igniteサーバーをyarnクラスタで正常に起動できない場合は、yarnクラスタにVMメモリーの問題があるかどうかを確認します。

この問題を修正するには、yarn-site.xmlに次のプロパティを追加し、yarnクラスタを再起動します。
<property>
         <name>yarn.nodemanager.vmem-check-enabled</name>
         <value>false</value>
</property>

1.2.2 Web層のロギング

この項では、Web層の一般的なロギングの問題を示します。

1.2.2.1 Jettyログ・レベルの変更
jettyログ・レベルはデフォルトでErrorに設定されています。ログ・レベルを変更するには、構成ファイル<osa installation>/osa-base/resources/log4j2.xmlでErrorをInfoに変更します。

1.2.3 パイプライン

この項では、パイプラインのデプロイ時に発生する一般的な問題をリストします。

1.2.3.1 17を超えるパイプラインをデプロイできない

デフォルトのSpark設定は、最大16個のパイプラインに設定されています。

この制限は変更できます:
  1. GGSAインスタンスでSSHターミナルを開きます
  2. mysql -uroot -pを実行します
  3. /home/opc/README.txtに記載されているパスワードを入力します
  4. mysql> use OSADB
  5. mysql> insert into osa_system_property (mkey,value) values('spark.port.maxRetries','40');
  6. sudo systemctl restart osaを実行してGGSAを再起動します

ご使用の環境で、必要な数のパイプラインに対して十分なコアおよびメモリー・リソースがSparkにあることを確認します。

1.2.3.2パイプラインが期待どおりに実行されない

パイプラインが期待どおりに実行されない場合は、次のことを確認します:

パイプラインが正常にデプロイされていることを確認する

Sparkクラスタに基づくApache Sparkインストール環境へのパイプライン・デプロイメントを確認するには:

  1. Spark Masterコンソール・ユーザー・インタフェースを開きます。

  2. ステータスが「Running」と表示されている場合、パイプラインは、現在正常にデプロイされて実行されています。

入力ストリームがパイプラインにイベントの連続的なストリームを供給していることを確認する

入力ストリームからイベントの連続供給をチェックするには:

  1. 「カタログ」に移動します。

  2. トラブルシューティングするストリームを特定してクリックします。

  3. ソース・タイプ・パラメータ・セクションのtopicNameプロパティの値を確認します。

  4. このトピックはKafka APIを使用して作成されるため、REST APIを使用してこのトピックを消費することはできません。

    標準のApache Kafkaインストール環境でホストされているKafkaトピックをリスニングします。

    Kafkaインストール環境でユーティリティを使用してKafkaトピックをリスニングできます。kafka-console-consumer.shは、任意のKafkaインストール環境の一部として使用できるユーティリティ・スクリプトです。

    次のステップを使用して、Kafkaトピックをリスニングします。

    1. クラスタに基づくApache Kafkaインストール環境でのZookeeperアドレスを特定します。

    2. 次のコマンドを使用してKafkaトピックをリスニングします。
      ./kafka-console-consumer.sh --zookeeper IPAddress:2181 --topicName

出力ストリームがモニター・トピックで使用可能であることを確認する

モニター・トピックで出力ストリームを使用できるかどうかを確認するには:

  1. 「カタログ」に移動します。

  2. 必要なパイプラインを開きます。

  3. パイプライン・エディタが開いたままであることを確認して、「完了」はクリックしないでください。そうしないと、パイプラインがアンデプロイされます。

  4. ブラウザ内の任意の場所を右クリックし、「インスペクト」を選択します。

  5. 「ネットワーク」タブの下の「WS」タブに移動します。

  6. ブラウザをリフレッシュします。

    新しいWebsocket接続が作成されます。

  7. URLにtopicという名前の入ったパラメータが含まれるWebsocketを見つけます。

    トピックparamの値は、このステージの出力(問合せまたはパターン)がプッシュされるKafkaトピックの名前です。

    ws_network.pngの説明が続きます
    図ws_network.pngの説明

    トピック名は、AppName_StageIdです。パイプライン名は、トピック名から_StageIDを削除することで、トピック名から導出できます。前のスナップショットでは、パイプライン名はsx_2_49_12_pipe1_draftです。

パイプラインがストリームと参照を関連付けている場合にキャッシングが動作していることを確認する

  1. Spark Application Master UIに移動します。

  2. 「Pipeline」タブをクリックしてから「Pipeline Summary」ページを開きます。「Pipeline Summary」ページには、様々なメトリックとともにステージの表が表示されます。

  3. ストリームと参照を関連付けているパイプラインの問合せステージに対応するステージIDをクリックします。

  4. パイプライン・ステージ詳細ページで、「CQLDStream」ステージをクリックしてCQLエンジン・サマリー・ページを開きます。

  5. 「CQL Engine Summary」ページで、「External Sources」セクションを見つけます。ステージで使用されている参照のソースIDを書き留めてください。

  6. 「CQL Engine Detailed Query Analysis」ページを開きます。

  7. ソースIDと同じ演算子IDを持つ演算子をクリックして、「CQL Engine Detailed Operator Analysis」ページを開きます。演算子に対応するエントリをクリックします。

  8. 「Cache Statistics」セクションを見つけます。そのようなセクションが存在しない場合、キャッシングはステージで有効化されていません。「Cache Hits」および「Cache Misses」に0 (ゼロ)以外のエントリが表示されている場合、キャッシングは、パイプライン・ステージに対して有効化され、アクティブになっています。

1.2.3.3 GGSAパイプラインの終了

GGSAパイプラインは、パイプラインで使用されるターゲットおよび参照にアクセスできない場合、またはリソースが使用できない場合に終了することがあります。ログに次の例外が表示されることがあります:

com.tangosol.net.messaging.ConnectionException

SQLException in the Spark logs.

Kafkaソースの場合は、パイプラインを再パブリッシュして、終了する前に処理されていないところからレコードを読み取ります。

1.2.3.4 ライブ表で表のイベントがない状態でListening Eventsが表示される

パイプラインのステータスがStarting PipelineからListening Events に変更されない理由は、複数考えられます。次に、このシナリオをトラブルシューティングするステップを示します。

  1. ライブ表には、現在選択されているステージのみの出力イベントが表示されます。常に、1つのステージのみが選択されます。別のステージに切り替えてみてください。別のステージのライブ表で出力を確認できる場合、問題は、そのステージに関連している可能性があります。さらにデバッグするには、ステップ5に進んでください。

    どのステージでも出力が存在しない場合、ステップ2に進んでください。

  2. パイプラインが現在もSparkクラスタで実行されていることを確認します。「パイプラインが正常にデプロイされていることを確認する」を参照してください

  3. パイプラインのSparkアプリケーションが中断または強制終了した場合、パイプラインがクラッシュしたことが示唆されます。さらにトラブルシューティングを行うには、アプリケーション・ログを調査することが必要な場合があります。

  4. アプリケーションは、ACCEPTED、NEWまたはSUBMITTED状態の場合、クラスタ・リソースを待機しており、まだ開始していません。十分なリソースがない場合、Big Data Cloud Service Spark YarnクラスタのVCORESの数を確認してください。パイプラインの場合、Stream Analyticsでは、少なくとも3つのVCORESが必要です。

  5. アプリケーションがRUNNING状態の場合、次のステップを使用してさらにトラブルシューティングを行います。

    1. 入力ストリームが連続的にイベントをパイプラインにプッシュしていることを確認します。

    2. 入力ストリームがイベントをプッシュしている場合、各パイプライン・ステージがイベントを処理し、出力を提供していることを確認します。

    3. 前述の両方のステップの確認に成功した場合、パイプラインが、その対応するモニター・トピックに各ステージの出力イベントをプッシュできることを確認します:

      1. ステージの出力のプッシュ先であるステージのモニター・トピックを特定します。「パイプライン・ステージの出力が伝播されているトピックの名前を特定する」を参照してください。

      2. モニター・トピックをリスニングして、イベントがトピックに継続的にプッシュされていることを確認します。Kafkaトピックをリスニングするには、トピックが作成されるKafkaクラスタにアクセスできる必要があります。Kafkaインストール環境でユーティリティを使用してKafkaトピックをリスニングできます。kafka-console-consumer.shは、任意のKafkaインストール環境の一部として使用できるユーティリティ・スクリプトです。

      3. トピックにイベントが1つも表示されない場合、この問題は、ステージからモニター・トピックに対する出力イベントの書込みに関連している可能性があります。サーバー・ログを確認して例外を検索し、管理者に報告してください。

      4. モニター・トピックに出力イベントが表示される場合、この問題は、Webブラウザでの出力イベントの読取りに関連している可能性があります。

パイプライン・ステージの出力が伝播されているトピックの名前を特定する

次に、ステージのトピック名を見つけるステップを示します。

  1. パイプラインの「Pipeline Summary」ページを開きます。このパイプラインに対応するアプリケーション名がわからない場合は、「出力ストリームがモニター・トピックで使用可能であることを確認する」を参照してください。

  2. このページでは、パイプライン名と様々なステージIDが提供されます。パイプライン・ステージごとに、表のエントリが表示されます。

  3. すべてのステージで、出力トピックIDはPipelineName_StageIDです。

  4. パイプライン・エディタで「Done」をクリックし、カタログに戻ってパイプラインを再度開きます。

1.2.3.5 ライブ表に現在もStarting Pipelineと表示される

パイプラインのステータスがStarting PipelineからListening Events に変更されない理由は、複数考えられます。次に、このシナリオをトラブルシューティングするステップを示します。

  1. パイプラインがSparkクラスタに正常にデプロイされていることを確認します。詳細は、「パイプラインが正常にデプロイされていることを確認する」 を参照してください。Sparkクラスタが停止しておらず、使用できることも確認します。

  2. デプロイメントに失敗した場合、Jettyログを確認してデプロイメントの失敗に関連する例外を参照し、問題を修正します。

  3. デプロイメントに成功している場合、OSA Web層がSparkからパイプライン・デプロイメントを受信していることを確認します。

  4. パイプライン・エディタで「Done」をクリックし、カタログに戻ってパイプラインを再度開きます。

パイプライン・ステージが現在もイベントを処理していることを確認する

特定のパイプライン・ステージがまだイベントを処理しているかどうかを確認するには:

  1. Spark Application Master UIに移動します。

  2. 「Pipeline」タブをクリックしてから「Pipeline Summary」ページを開きます。「Pipeline Summary」ページには、様々なメトリックとともにステージの表が表示されます。

  3. 合計出力イベントが0 (ゼロ)以外の値であるかどうかを確認します。ページをリフレッシュして、値が増加するか、同じままであるかを確認します。値が同じままで、長時間変化がない場合、ステージの詳細にドリルダウンします。

1.2.3.6 パイプラインのパブリッシュの取消し時のSparkログでのタイムアウト例外

Jettyのログで次のメッセージを確認します:

OsaSparkMessageQueue:182 - received: oracle.wlevs.strex.spark.client.spi.messaging.AcknowledgeMessage Undeployment Ack: oracle.wlevs.strex.spark.client.spi.messaging.AcknowledgeMessage

アプリケーションの停止中に、パイプラインのパブリッシュが完全に取り消されるまで数分かかることがあります。

したがって、前述のメッセージが表示されない場合は、対応するようにosa.spark.undeploy.timeoutの値を増やす必要があります。

また、高可用性モードでは、パイプラインのパブリッシュを取り消すときに、スナップショット・フォルダが削除されます。

HAモードで、前述のエラー・メッセージがすぐに発生せず、次のエラーが表示されることがあります:

Undeployment couldn't be complete within 60000 the snapshot folder may not be completely cleaned.

これが意味するのは、処理に影響はないが、一部のディスク領域が使用されるということだけです。

1.2.3.7 HAモードでのキューに入れられたバッチの停滞
GGSAパイプラインがSparkスタンドアロン・クラスタに高可用性モードでデプロイされている場合、ターゲットまたは参照の障害が発生するたびに、Sparkによって新しいドライバが作成されます。これらのターゲットと参照がリカバリできない場合、キューに入れられたバッチのループが発生します。
この問題を解決するには、アプリケーションのパブリッシュを手動で取り消す必要があります。
1.2.3.8 問合せステージのサマリーのNullレコード

いずれかの問合せステージのサマリーを使用してパイプラインを初めてパブリッシュした場合、すべての列で最初のレコードがnullになります。これが原因で、キーが必要なターゲットがある場合、パイプラインが失敗します。

この問題を解決するには、ターゲット・ステージの前にサマリー・ステージが追加されているかどうかを確認し、キャッシュ・キーのnull値をチェックするフィルタ付きで問合せステージを追加します。

1.2.4 ストリーム

この項では、ストリームで発生する一般的な問題をリストします。

1.2.4.1 トピックのリストで任意のKafkaトピックまたは特定のトピックを参照できない

次のステップを使用して、トラブルシューティングを行います。

  1. カタログに移動して、ストリームの作成に使用しているKafka接続を選択します。

  2. 「次」をクリックして「接続の詳細」タブに移動します。

  3. 「接続のテスト」をクリックして、接続が現在もアクティブであることを確認します。

  4. Kafkaクラスタに1つ以上のトピックが存在することを確認します。トピックが作成されるKafkaクラスタにアクセスできる必要があります。Kafkaインストール環境でユーティリティを使用してKafkaトピックをリストできます。kafka-console-consumer.shは、任意のKafkaインストール環境の一部として使用できるユーティリティ・スクリプトです。

  5. 前述のコマンドを使用してもトピックを参照できない場合、トピックが作成されていることを確認します。

  6. テスト接続に失敗し、「OSA-01266 ZooKeeperサーバーに接続できません」などのエラー・メッセージが表示された場合、Kafkaクラスタは使用不可です。Kafkaクラスタが起動して実行中であることを確認します。

1.2.4.2 入力Kafkaトピックはデータを送信しているのにライブ表にイベントが表示されない

これは、受信イベントがストリームの予期される形状に準拠していない場合に発生する可能性があります。形状の不一致によってイベントが削除されたかどうかを確認するため、次のステップを使用してトラブルシューティングを行います。

  1. ストリームのソース・タイプ・プロパティでlenientパラメータが選択されているかどうかを確認します。これがFALSEの場合、イベントは、形状の不一致によって削除された可能性があります。これを確認するには、実行中のアプリケーションのアプリケーション・ログを確認します。

  2. プロパティがTRUEに設定されている場合、さらにデバッグを行います。

    1. Kafkaクラスタが起動して実行中であることを確認します。Sparkクラスタは、Kafkaクラスタにアクセスできる必要があります。

    2. Kafkaクラスタが起動して実行中である場合、アプリケーション・ログを取得してさらにデバッグを行います。

1.2.5 接続

この項では、接続で発生する一般的な問題をリストします。

1.2.5.1 データベース接続の失敗

データベース接続をテストするには:

  1. 「カタログ」ページから、テストするデータベース接続を選択します。

  2. 「次」をクリックします。

  3. 「接続の詳細」タブで、「接続のテスト」をクリックします。
    • テストに成功すると、接続がアクティブであることが示されます。

    • テストが失敗すると、次のエラー・メッセージが表示されます:

      • OSA-01260: データベースへの接続に失敗しました。IOエラー: ネットワーク・アダプタは接続を確立できませんでした: このエラー・メッセージは、GGSAデザイン・タイムからDBホストにアクセスできないことを示します。

      • OSA-01260: データベースへの接続に失敗しました。ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました: このエラー・メッセージは、ログイン資格証明が不適切であることを示します。

1.2.5.2 Druid接続の失敗

Druid接続をテストするには:

  1. 「カタログ」ページから、テストするDruid接続を選択します。

  2. 「次」をクリックします。

  3. 「接続の詳細」タブで、「接続のテスト」をクリックします。
    • テストに成功すると、接続がアクティブであることが示されます。

    • テストが失敗すると、次のエラー・メッセージが表示されます:

      OSA-01460: zooKeeperサーバーでdruidサービスへの接続に失敗しました: このエラーは、druid zookeeperが使用不可であることを示します。druidサービスとZookeeperクラスタが起動して実行中であることを確認します。

1.2.5.3 Coherence接続の失敗

GGSAでは、Coherenceクラスタに「接続のテスト」オプションは提供されません。Coherence接続をテストするには、Oracle Coherenceのドキュメントを参照してユーティリティおよびツールを見つけてください。

1.2.5.4 JNDI接続の失敗

JNDI接続をテストするには:

  1. 「カタログ」ページから、テストするJNDI接続を選択します。

  2. 「次」をクリックします。

  3. 「接続の詳細」タブで、「接続のテスト」をクリックします。
    • テストに成功すると、接続がアクティブであることが示されます。

    • テストが失敗すると、次のエラー・メッセージが表示されます:

      • OSA-01707: サーバーとの通信に失敗しました。サーバーが起動しており、サーバーURLが適切に指定されていることを確認してください: このエラーは、サーバーが停止しているか、サーバーURLが間違って指定されていることを示します。サーバーURLは、host1:port1,host2:port2の形式にする必要があります。

      • OSA-01706: JNDI接続が失敗しました。ユーザー: weblogic、認証に失敗しました: このエラーは、ログイン資格証明が正しくないことを示します。

1.2.6 ターゲット

この項では、ターゲットで発生する一般的な問題をリストします。

1.2.6.1 ターゲットでイベントを表示できない

パイプラインがドラフト・モードの場合、ターゲットにイベントをプッシュできません。公開されたパイプラインのみがターゲットにイベントをプッシュできます。

1.2.7 ジオフェンス

この項では、ジオフェンスで発生する一般的な問題をリストします。

1.2.7.1 DBベース・ジオフェンスの「「名前」と「説明」フィールドが表示されない

データベース・ベース・ジオフェンスの名前と説明のフィールドが表示されない場合、次に記載された確認ステップを実行します。

  1. カタログに移動して、必要なデータベース・ベース・ジオフェンスの「編集」をクリックします。

  2. ソース・タイプ・プロパティの「編集」をクリックし、「次」をクリックします。

  3. 「形状」セクションで名前と説明のマッピングが定義されていることを確認します。

  4. これらのマッピングを定義すると、ジオフェンスの名前と説明が表示されます。

1.2.7.2 DBベース・ジオフェンスが動作しない

データベース・ベース・ジオフェンスが動作していることを確認するには:

  1. カタログに移動して、必要なデータベース・ベース・ジオフェンスを開きます。

  2. データベース接続ウィザードの「テスト」ボタンをクリックして、ジオフェンスで使用されている接続がアクティブであることを確認します。

  3. ジオフェンスで使用されている表が、現在も有効で、DBに存在することを確認します。

  4. ジオフェンス・ページに移動して、問題が解決されたことを確認します。

1.2.8 キューブ

この項では、キューブで発生する一般的な問題をリストします。

1.2.8.1 以前動作していたキューブを探索できない

以前動作していたキューブを探索できない場合、次に記載されたステップを実行します。

  1. druid Zookeeperまたはインデクサ、ブローカ、中間マネージャ、オーバーロードの関連サービスが停止しているかどうかを確認します。

  2. Druid接続をクリックして次のページに移動します。

  3. 接続をテストします。このステップにより、サービスが停止して調査が必要かどうかがわかります。

1.2.8.2 キューブに「データソースの準備ができていません」と表示される

キューブの探索時に「データソースの準備ができていません」というメッセージが表示され続ける場合、次に記載されたステップを実行します。

  1. druidインデクサ・ログに移動します。通常、これはhttp:/DRUID_HOST:3090/console.htmlです。

  2. 実行中のタスクでindex_kafka_<cube-name>_<somehash>というエントリを検索します。実行中のタスクにエントリがない場合、保留中のタスクまたは完了済タスクで同じエントリを検索します。

  3. エントリが保留中のタスクに存在する場合、ワーカーは容量を使いはたし、データソースは索引付けに使用可能になるとすぐに取得されることを意味します。

  4. このような場合、待機するかワーカーの容量を増やし、druidサービスを再起動するか、既存のデータソース索引付けタスクのいくつかを中断します(それらはしばらくして再起動されます)。

  5. エントリが完了済タスクに「失敗」ステータスで存在する場合、索引付けが不適切な収集指定またはリソースの問題のために失敗したことを意味します。

  6. 「ログ(すべて)」リンクをクリックして例外に移動すると、正確な理由を確認できます。

  7. 収集が理由の場合は、タイムスタンプ書式の変更を試行してください。(Druidが索引付けに失敗するのは、タイムスタンプがJODA時間フォーマットではない場合、または指定された時間フォーマットがタイムスタンプ値のフォーマットに一致しない場合です)。

1.2.9 ダッシュボード

この項では、ダッシュボードで発生する一般的な問題をリストします。

1.2.9.1 以前表示されていたビジュアライゼーションがダッシュボードで使用できなくなる

次のステップを使用して、トラブルシューティングを行います。

  1. ストリーミング・ビジュアライゼーションが欠落した場合、次の理由が考えられます。

    1. 欠落したビジュアライゼーションに対応するパイプライン/ステージがすでに存在しない

    2. ビジュアライゼーションそれ自体がカタログまたはパイプライン・エディタから削除された

  2. (キューブから作成された)探索ビジュアライゼーションが欠落した場合、キューブまたはビジュアライゼーションがすでに削除されている可能性があります。

1.2.9.2 ビジュアライゼーションのサイズ変更または移動後にダッシュボード・レイアウトがリセットされる

次のステップを使用して、トラブルシューティングを行います。

  1. これは、ビジュアライゼーションの移動またサイズ変更の後にダッシュボードを保存し忘れた場合に発生する可能性があります。

  2. レイアウトを変更した後に、必ず「保存」をクリックします。

1.2.9.3 ストリーミング・ビジュアライゼーションにデータが表示されない

次のステップを使用して、トラブルシューティングを行います。

  1. パイプライン・エディタでビジュアライゼーションに移動して、ライブ出力表にデータが表示されていることを確認します。

  2. 出力が存在しない場合、パイプラインがクラスタにデプロイされて実行中であることを確認します。ライブ出力表にデータが表示されると、それがストリーミング・ビジュアライゼーションに表示されます。

1.2.10 ライブ出力

この項では、ライブ出力で発生する一般的な問題をリストします。

1.2.10.1 ライブ出力の問題

パイプラインごとに、Sparkクラスタ上で1つのSparkストリーミング・パイプラインが実行されます。Stream Analyticsパイプラインで1つ以上の問合せステージまたはパターン・ステージを使用する場合、パイプラインでは、それらのステージごとに1つ以上の連続問合せが実行されます。

連続問合せの詳細は、「Oracle CQLの理解」を参照してください。

問合せステージまたはパターン・ステージのライブ出力表に出力イベントが存在しない場合、次のステップを使用して問題を特定するか、絞り込みます。

各問合せステージのCQL問合せが出力を発生させていることを確認する

CQL問合せが出力イベントを発生させているかどうかを確認し、CQLエンジン・メトリックを使用したCQL問合せをモニターするには:

  1. 「CQL Engine Query Details」ページを開きます。詳細は、「CQLエンジン・メトリックへのアクセス」を参照してください。

  2. 少なくとも1つのパーティションで、「Execution Statistics」セクションに0 (ゼロ)より大きい「Total Output Events」があることを確認します。

    cql_engine_query_details.pngの説明が続きます
    図cql_engine_query_details.pngの説明

    問合せがエラーなしで実行され、入力データが継続的に受信される場合、「Total Output Events」は増加し続けます。

ステージの出力が使用できることを確認する

  1. パイプライン・エディタが開いたままであることを確認して、「完了」はクリックしないでください。そうしないと、パイプラインがアンデプロイされます。

  2. ブラウザ内の任意の場所を右クリックし、「インスペクト」をクリックします。

  3. 最上位タブから「ネットワーク」を選択し、「WS」を選択します。

  4. ブラウザをリフレッシュします。

    新しいWebsocket接続が作成されます。

  5. URLにtopicという名前の入ったパラメータが含まれるWebsocketを見つけます。

    トピックparamの値は、このステージの出力がプッシュされるKafkaトピックの名前です。

    websocket_network.pngの説明が続きます
    図websocket_network.pngの説明

  6. ステージの出力がプッシュされるKafkaトピックをリスニングします。

    このトピックはKafka APIを使用して作成されるため、REST APIを使用してこのトピックを消費することはできません。次のステップを使用して、Kafkaトピックをリスニングします。

    1. 標準のApache Kafkaインストール環境でホストされているKafkaトピックをリスニングします。

      Kafkaインストール環境でユーティリティを使用してKafkaトピックをリスニングできます。kafka-console-consumer.shは、任意のKafkaインストール環境の一部として使用できるユーティリティ・スクリプトです。

      Kafkaのトピックをリスニングするには:

      1. クラスタに基づくApache Kafkaインストール環境でのZookeeperアドレスを特定します。

      2. 次のコマンドを使用してKafkaトピックをリスニングします。
        ./kafka-console-consumer.sh --zookeeper IPAddress:2181 --topic sx_2_49_12_pipe1_draft_st60
1.2.10.2 無効データによる欠落イベント

CQLEngineがユーザー定義関数で無効データを検出した場合、無効データを含むイベントの例外がエグゼキュータ・ログに記録され、処理は中断せずに続行されます。

削除されたイベントと例外のログの例:

20/04/02 14:41:42 ERROR spark: Fault in CQL query processing. 
Detailed Fault Information [Exception=user defined function(oracle.cep.extensibility.functions.builtin.math.Sqrt@74a5e306) 
runtime error while execution,
 Service-Name=SparkCQLProcessor, Context=phyOpt:1; queries:sx_SquareRootPipeline_osaadmin_draft1
20/04/02 14:41:42 ERROR spark: Continue on exception by dropping faulty event.
20/04/02 14:41:42 ERROR spark: Dropped event details <TupleValue><ObjectName>sx_SquareRootPipeline_osaadmin_draft_1</ObjectName><Timestamp>1585838502000000000</Timestamp>
<TupleKind>PLUS</TupleKind><IntAttribute name="squareNumber"><Value>-2</Value></IntAttribute><IsTotalOrderGuarantee>true</IsTotalOrderGuarantee></TupleValue>:

1.2.11 パイプライン・デプロイメントの失敗

パイプライン・デプロイメントは、次の例外とともに失敗することがあります。

Sparkパイプラインは、60000ミリ秒後に正常に開始されませんでした。

この例外は、通常、クラスタに空きリソースがない場合に発生します。

回避策:

外部Sparkクラスタを使用するか、高性能なマシンを入手してより多くのリソースでクラスタを構成します。