トラブルシューティングと診断

Apama-ctrl-smartrules または Apama-ctrl-smartrulesmt マイクロサービスがある場合、このトピックで説明されている機能のほとんどは適用されません。

診断とログのダウンロード

備考
診断情報は、Apama-ctrl-smartrules および Apama-ctrl-smartrulesmt マイクロサービスでは利用できません。

診断情報をダウンロードするには、「CEP 管理」の読み取り権限が必要です。詳細については、権限の管理 を参照してください。

備考
「CEP 管理」に対する管理者権限には、読み取り権限は含まれません。

「CEP 管理」の読み取り権限がある場合、ストリーミング分析アプリケーションの ユーザー ボタンをクリックすると、診断情報をダウンロードするためのリンクが表示されます。 右側のドロワーが開き、診断 セクションに次のリンクがあります。

  • 基本診断（zip） リンク：基本的な診断情報をダウンロードします。通常、数メガバイトのサイズで、生成には約 5 秒かかります。
  • 拡張診断（zip） リンク：より高度な、より多くのリソースを必要とする診断情報をダウンロードします。

問題が発生したとき、または EPL アプリをデバッグするときに、この診断情報が役立ちます。サポートチケットを発行する際にも、製品サポート へ提供いただくことで問題解決につながる可能性があります。テナントIDは、右側のドロワーの プラットフォーム情報 セクションで確認できます。テナント上のさまざまなコンポーネントのバージョン番号を確認するには、プラットフォーム情報 セクションの プラットフォームの詳細をダウンロード ボタンをクリックし、ダウンロードした JSON ファイルを開いてください。詳細については、ユーザーオプションと設定 を参照してください。

基本的な診断情報は、diagnostic-overview<timestamp>.zip という名前の ZIP ファイルで提供され、次の情報が含まれています。

  • マイクロサービス ログファイルの内容（使用可能な場合）、コリレーターの起動ログの記録と、過去 1 時間または最大 20,000 行のログが含まれます。

    備考

    Things Cloud Edge Appliance VM の場合、Apama-ctrl は VM ベースの配布でマイクロサービスとしてデプロイされないため、診断ユーティリティを使用して Apama ログを取得できます。

  • Apama 内部診断情報（Apama で提供されている engine_watch および engine_inspect コマンドラインツールに類似）

  • すべての EPL アプリ、スマートルール、分析モデルのコピー

  • Apama-ctrl マイクロサービスが発生したアラームのコピー

  • CPU プロファイリング（5 秒間）

  • EPL メモリ プロファイラのスナップショット

  • 環境のいくつかの情報（テナントの詳細、環境変数）

  • コンポーネントのバージョン情報

拡張診断情報は、diagnostic-enhanced<timestamp>.zip という名前のZIPファイルで提供され、次の情報が含まれています。

  • 上記の diagnostic-overview<timestamp>.zip ファイルの内容が含まれています。
  • キューの内容、CPU 使用率など、リソースを大量に消費し、コリレーターの処理速度を大幅に低下させる可能性のあるリクエストが含まれます。

ユーザーが表示または実行できる内容は、アクセス権限によって異なります。

  • 「CEP管理」の読み取り権限のみを持つユーザーは、EPL アプリと分析モデルへの読み取り専用アクセス権があり、診断情報にアクセスできます。
  • 「CEP管理」の管理者権限がないと、ユーザーは EPL アプリまたは分析モデルをアクティブ化または編集できません。
  • ユーザーが「CEP管理」の読み取りと管理者の両方のアクセス権限を持っている場合、ユーザーは読み取り／書き込みアクセス権を持ち、診断情報にアクセスできます
  • ユーザーが「CEP管理」の管理者権限のみを持ち、読み取り権限を持っていない場合、ユーザーは EPL アプリと分析モデルをロード、編集、デプロイできますが、診断情報を表示またはアクセスすることはできません。

Apama-ctrl マイクロサービスのログファイル

Apama-ctrl マイクロサービスのログを取得するには、2 つの方法があります。

  • 診断とログのダウンロード の説明に従って、ストリーミング分析アプリケーションから診断情報をダウンロードできます。

  • 場合によっては、Things Cloud を使用して Apama-ctrl マイクロサービスのログファイルを閲覧すると便利です。ログファイルは、管理アプリケーションからアクセスできます。Apama-ctrl マイクロサービスの ログ タブにあります。ログを表示するには、マイクロサービスをサブスクライブする必要があります。マイクロサービスとログファイルの詳細については、マイクロサービスの管理 および マイクロサービスの監視 を参照してください。

    備考

    Things Cloud Edge Applicance VM の場合、Apama-ctrl は VM ベースの配布ではマイクロサービスとしてデプロイされないため、診断ユーティリティを使用してログファイルを取得できます。

コリレーターログは、Apama-ctrl マイクロサービスのログファイルに埋め込まれます。Apama ドキュメントのコリレーターステータス ログフィールドの説明 を参照してください。

上記についてご不明点がある場合は、製品サポートにお問い合わせください。

ストリーミング分析の監査ログ

分析モデルと EPL アプリの有効化および無効化は、監査ログに表示されます。監査ログは、管理 アプリケーションおよび Audit API からアクセスできます。
監査ログへのアクセス方法の詳細については、監査ログ と Things Cloud OpenAPI仕様 の Audit API を参照してください。

監査ログエントリには、現在のアクションとそのアクションを実行したユーザー名が含まれます。

例:

ストリーミング分析の監査ログエントリ

RESTエンドポイントを診断する

備考
これらのエンドポイントは、Apama-ctrl-smartrules および Apama-ctrl-smartrulesmt マイクロサービスでは利用できません。

REST リクエストでは、次の診断エンドポイントを使用できます。これらには、「CEP管理」に対する読み取り権限を持つユーザーとして認証が必要です。

  • /service/cep/diagnostics/metrics
    GET のみ。プレーンテキスト形式
    コリレーターからの Prometheus メトリクス。詳細については、Apama ドキュメントの Prometheus による監視 を参照してください。
  • /service/cep/diagnostics/overview
    GET のみ。zip ファイルのダウンロード
    上記のように diagnostic-overview<timestamp>.zip ファイルを取得します。
  • /service/cep/diagnostics/enhanced
    GET のみ。zip ファイルのダウンロード
    上記のように diagnostic-enhanced<timestamp>.zip ファイルを取得します。
  • /service/cep/diagnostics/request
    PUT のみ。JSON コレレータに対する一般的なマネージメント リクエストへのアクセスを提供します。詳細については、Apama ドキュメントの コンポーネントのシャットダウンと管理 を参照してください。
  • /service/cep/diagnostics/correlator/info
    GET のみ。JSON
    engine_inspect 情報を取得します。

REST エンドポイントの監視

REST リクエストには次の監視エンドポイントを使用できます。 これらには有効なユーザーとしての認証が必要ですが、特別なロールは必要ありません。

  • /service/cep/health
    GET のみ。JSON
    Apama-ctrl マイクロサービスが稼働しているかどうかの情報を取得します。

    備考
    Apama-ctrl-smartrulesmt（Apama-ctrl-smartrules マイクロサービスのマルチテナント版）については、基本的なマイクロサービス ステータス値のみが提供されます。

  • /service/cep/prometheus
    GET のみ。プレーンテキスト形式
    コリレーターおよびマイクロサービスからの Prometheus メトリクス。詳細については、Apamaドキュメントの Prometheus による監視 を参照してください。

Apama-ctrlマイクロサービスによって生成されるアラーム

アラームは、Things Cloudテナント（例えば、分析モデル、アクティブ化されたEPLファイル、スマートルールなど）のユーザーアプリケーションによって作成されます。アラーム全般については、アラームの操作 を参照してください。Apama-ctrl マイクロサービスも、何らかの問題が発生するとアラームを生成し、ユーザーに状況を通知します。以下の情報は、Apama-ctrl マイクロサービスによって生成されるアラーム、その原因、結果、およびそれらを解決する可能性のある方法についての内容です。

アラームは次の方法で表示できます。

  1. コックピット アプリケーション。詳細については、コックピット を参照してください。
  2. 管理 アプリケーションの エコシステム > マイクロサービス にあります。Apama-ctrl マイクロサービスをクリックし、ステータス をクリックしてください。詳細については、マイクロサービスの監視 を参照してください。
  3. ストリーミング分析 アプリケーション。ユーザー ボタンをクリックして右のドロワーを表示し、診断 セクションのリンクのいずれかをクリックして、/alarm/alarms_apama-ctrl-object.json にアラーム情報を含む zip ファイルをダウンロードします。詳細については、診断とログのダウンロード を参照してください。

アラームの重大度

重大度 説明
クリティカル Apama-ctrl はユーザーのアプリケーションの実行を続行できなかったため、修正処理が必要になります
メジャー Apama-ctrl で、サービスの一部が失われる状況が発生しました（例えば、再起動など）
マイナー Apama-ctrl に、修正が必要な問題があります。
警告 警告があります。

Apama-ctrl マイクロサービスによって作成されたアラーム

Apama-ctrl は、コリレーターのメモリ不足、アクティブ化された EPL ファイルでキャッチされていない例外などのシナリオで、ユーザーに通知するアラームを作成できます。Things Cloud テナントでアラームを確認したら、発生したアラームの重大度に応じて診断し、解決する必要があります。各アラームには、タイトル、テキスト、タイプ、日付、カウント（アラームの発生回数）などの詳細情報があります。

アラームの一覧を次に示します。以下の情報では、これらのアラームがいつ発生するか、その結果、および解決方法について説明します。

アラームの原因が解決されると、Things Cloud テナント内でアラームを認識しクリアする必要があります。それ以外の場合は、Apama-ctrl マイクロサービスが再起動するまでアラームが表示され続けます。

備考
次のアラームのアラームテキストは、今後変更される可能性があります。

Change in tenant options and restart of Apama-ctrl

このアラームは、テナントオプションがanalytics.builderまたはstreaminganalyticsカテゴリで変更された場合に発生します。テナントオプションの詳細については、Things Cloud OpenAPI仕様 仕様のTenant API を参照してください。

  • アラーム タイプ： tenant_option_change
  • アラームテキスト： Detected changes in tenant option. Apama-ctrl will restart in order to use it.
  • アラームの重大度： メジャー

分析ビルダーでは、numWorkerThreads や status_device_nameなどのキー名を使用してテナントオプションを変更することで、その設定を構成できます。例えば、並列に処理したい場合は、Things Cloud にテナントオプションを更新するRESTリクエストを送信することで、numWorkerThreadsを 3 に設定できます。このような変更により、Apama-ctrl マイクロサービスが自動的に再起動されます。ユーザーに再起動を通知するため、Apama-ctrl はテナントオプションの変更が検出され、そのオプションを使用するために Apama-ctrl が再起動することを知らせるアラームを生成します。

このアラームが表示されたら、変更が有効であることを確認できます。

Safe mode on startup

このアラームは、Apama-ctrl マイクロサービスがセーフモードに切り替わるたびに発生します。

  • アラーム タイプ： apama_safe_mode
  • アラームテキスト： Apama-ctrl appears to be repeatedly restarting. As a precaution, user-provided EPL, Analytics Builder models and extensions that might have caused this have been disabled. Refer to the audit log for more details. Please check any recent alarms, or contact support or your administrator.
  • アラームの重大度： クリティカル

Apama-ctrl は、繰り返し再起動が行われているかどうか、およびユーザーアセット（EPL アプリ、分析モデル、拡張機能）が最近変更されたかどうかを検出します。 Apama-ctrl は、予防措置としてすべてのユーザーアセットを無効にします。考えられる原因としては、利用可能なメモリーを超えるメモリを消費する EPL アプリやバグを含む拡張機能などが挙げられます。

service/cep/diagnostics/apamaCtrlStatus への REST リクエストを実行することで、マイクロサービスのモード（通常モードまたはセーフモード）を確認できます。レスポンスには safe_mode フラグが含まれます。

予期しない再起動の原因を診断するには、次の操作を実行します。

  • /service/cep/diagnostics/eplMemoryProfiler に REST リクエストを送信し、EPL アプリのメモリプロファイラでメモリリークがないか確認します。
    Apama-ctrl マイクロサービスは、セーフモードで再起動すると前のマイクロサービス インスタンスに関する情報を失うため、以前にアクティブだった EPL アプリを再アクティブ化する必要があることを注意してください。前述のシナリオを再現するには、EPL アプリを実行し、リークをトリガーするいくつかのイベントを処理してから、メモリ プロファイラを使用してメモリリークをチェックします。

  • 診断とログのダウンロード の説明に従って基本診断 zip ファイルをダウンロードし、マイクロサービス ログで例外を確認します。ダウンロードした zip ファイルでは、/diagnostics/ の下にログがあります。

    前述のように、以前にアクティブだったEPLアプリと分析モデルを再度アクティブにして、ログを確認します。

  • 監査ログを確認してください。監査ログには、管理アプリケーションおよび監査 API を介してアクセスできます。監査ログへのアクセスの詳細については、監査ログ および Audit API を参照してください。

セーフモードでは、以前にアクティブだったすべての分析モデルと EPL アプリが無効になり、手動で再度アクティブにする必要があります。

Deactivating models in the Apama-ctrl-starter microservice

このアラームは、Apama-ctrl が完全に機能するマイクロサービスからアクティブなモデルが、3 つ以上の Apama-ctrl-starter microservice に切り替わったときに発生します。

  • アラーム タイプ： apama_ctrl_starter
  • アラームテキスト： The following models were de-activated as Analytics Builder is restricted to <activate limit> active models: (<models>).
  • アラームの重大度： マイナー

Apama-ctrl-starter microservice では、ユーザーは最大 3 つのアクティブモデルを持つことができます。例えば、完全に機能する Apama-ctrl マイクロサービスを使用しており、5 つのアクティブモデルがある場合、Apama-ctrl-starter に切り替えます。Apama-ctrl-starter は 3 つ以上のアクティブモデルを許可しないため、5 つすべてのアクティブモデルを非アクティブにし、アラームを発生させてユーザーに通知します。

High memory usage

このアラームは、 Apama-ctrl マイクロサービスがマイクロサービス コンテナに許可されている最大メモリの 90% を消費するたびに発生します。この間に、Apama-ctrl マイクロサービスは、メモリ消費の最も可能性の高い原因を識別するために使用される診断情報を含む基本診断 zip ファイルを自動的に生成します。

生成された基本診断 zip ファイルの時間とカウントの制限に応じて、このアラームには 3 つのバリエーションがあります。

1 番目のバリエーション：

  • アラームタイプ： apama_highmemoryusage
  • アラームテキスト： Streaming Analytics is using 90% of available memory (<totalMemory>). Your apps will be in danger of crashing. Diagnostics file is located at <URL-to-ZIP-file> You can also download the file by navigating to Administration > Management > Files Repository
  • アラームの重大度： 警告

2 番目のバリエーション：

  • アラームタイプ： apama_highmemoryusage
  • アラームテキスト： Streaming Analytics is using 90% of available memory (<totalMemory>). Your apps will be in danger of crashing. Have recently created diagnostics snapshot (within last hour).
  • アラームの重大度： 警告

3 番目のバリエーション：

  • アラームタイプ： apama_highmemoryusage
  • アラームテキスト： Streaming Analytics is using 90% of available memory (<totalMemory>). Your apps will be in danger of crashing. Have created 5 diagnostics snapshots, not creating any more, refer to past alarms.
  • アラームの重大度： 警告

EPL アプリ（より少ない範囲では、スマートルールと分析モデル）を実行するとメモリを消費しますが、その量は実行するアプリケーションの性質に大きく依存します。メモリ使用量は、特定のアプリ群に対してほぼ一定であるべきですが、特に EPL ファイルやカスタムブロックに「メモリリーク」を作成することは可能です。Apama-ctrl マイクロサービスはメモリを監視し、基本診断 zip ファイルとともにメモリ制限の 90% に達すると、重大度が警告のアラームを生成してファイルリポジトリ（アラームテキストで述べられているように）に保存します。

Apama-ctrl は、次の条件で基本診断 zip ファイルを生成します。

  • 過去 1 時間以内に生成されていない場合のみ
  • 開始時から停止するまでの最大 5 つの診断概要 zip ファイル
  • 全体として、Things Cloud テナントごとに最大 20 の zip ファイルを生成でき、それを超えると、起動プロセス中に最も古い zip ファイルを削除し続けます。

メモリを大量に消費するモデルや EPL アプリを診断するには、以下を試すことができます（リスナーリーク、過剰な状態の保存、生成されたモニターのリークなどが考えられます）。

  • 自動生成された基本診断 zip ファイルをダウンロードし（場所はアラームテキストを参照）、correlator/inspect.json と correlator/status.json でリスナーの数を確認してください。リスナーリークが発生した場合、この数値は大きくなる可能性があります。この zip ファイルには、EPL メモリプロファイラのスナップショットが含まれています。

  • ストリーミング分析アプリケーションから診断情報をダウンロードします。ユーザー ボタンをクリックして右側のドロワーを表示し、診断 セクションのリンクのいずれかをクリックします（診断とログのダウンロード の説明に従ってください）。/diagnostics/eplMemoryProfiler.csv の 基本診断 (zip) リンクからダウンロードできる EPL メモリ プロファイラでは、各モニターのメモリ消費量に加え、リスナー数や、次のスニペットに示すように実行中のモニター インスタンス数などの詳細情報も表示されます。これにより、どのモニターがより多くのメモリを消費しているかを把握し、そのメモリ消費量を削減することができます。

    モニター インスタンスの監視 EPL オブジェクト リスナー バイト オーバーヘッドバイト
    mon1 1 5384 4 1073908 383240
    mon2 1 2 2 696 2280
    mon3 1 4 1 840 752

  • ストリーミング分析アプリケーションの 拡張診断 (zip) リンクを使用すると、基本診断 (zip) リンクで取得できる情報に加えて、リソースを大量に消費し、コリレーターの速度を大幅に低下させる可能性のあるリクエストも診断情報に含まれます。これにはキューの内容も含まれます。そのため、初めて原因を診断する場合、追加情報が必要な場合を除き、基本診断 (zip) リンクの zip ファイルを使用することをお勧めします。

  • /diagnostics/toStringQueues.txt の 拡張診断 (zip) リンクから入手できるすべての入力および出力キューのメモリ使用量をチェックします。

メモリが増え続け上限に達すると、コリレーターのメモリが不足し、Apama-ctrl がシャットダウンします。マイクロサービスがダウンしないようにするには、これを優先的に修正する必要があります。

Things Cloud の Apama 診断ツール も参照してください。

Warning or higher level logging from an EPL file

このアラームは、特定のログレベル（CRITICAL、FATAL、ERROR、WARNINGを含む）を持つ EPLファイルによってメッセージが記録されるたびに発生します。

ストリーミング分析アプリケーションを使用すると、EPL ファイルをコリレーターにデプロイできます。Apama-ctrl マイクロサービスは、EPL ファイルに記録されたコンテンツを分析し、ログレベルに基づいて、モニター名、ログテキスト、アラームタイプ（警告またはメジャーのいずれか）などの詳細を含む特定のログレベルのアラームを生成します。

例えば、次はシーケンスを表示し、いくつかのテキストを異なる EPL ログレベルで記録する単純なモニターです。

monitor Sample{
   action onload() {
      log "Info"; // default log level is now INFO
      log "Fatal Error" at FATAL; // log level is FATAL
      log "Critical Error" at CRIT; // log level is CRITICAL
      log "Warning" at WARN; // log level is WARNING
   }
}

Apama-ctrl はすべてのログメッセージを分析し、特定のログメッセージのみを除外し、識別されたログメッセージに対してアラームを生成します。したがって、Apama-ctrl は、上記の例に対して次の 3 つのアラームを生成します。

1 番目のアラーム：

  • アラームタイプ： APAMA_CTRL_FATAL_<HASHCODE>
  • アラームテキスト： <Monitor name>-Fatal Error.
  • アラームの重大度： メジャー

2 番目のアラーム：

  • アラームタイプ： APAMA_CTRL_CRIT_<HASHCODE>
  • アラームテキスト： <Monitor name>-Critical Error.
  • アラームの重大度： メジャー

3 番目のアラーム：

  • アラームタイプ： APAMA_CTRL_WARN_<HASHCODE>
  • アラームテキスト： <Monitor name>-Warning.
  • アラームの重大度： 警告

An EPL file throws an uncaught exception

Apama-ctrl マイクロサービスが、ログに記録されたメッセージに対してアラームを生成することを確認しました。また、（実行時に）キャッチされない例外もあります。Apama-ctrl はこのような例外を識別し、アラームを生成するため、問題を特定して修正できます。

例えば、次のモニターは、実行時に IndexOutOfBoundsException をスローします。

monitor Sample{
   sequence<string> values := ["10", "20", "30"];
   action onload() {
      // IndexOutOfBoundsException (runtime error)
      log "Value = " + values[10] at ERROR;
   }
}

上記の例では、Apama-ctrl によって次のアラームが生成されます。

  • アラームタイプ： APAMA_CTRL_ERROR_<HASHCODE>
  • アラームテキスト： <Monitor name>-Error on line <x> of monitor : IndexOutOfBoundsException - Out of bounds index passed
  • アラームの重大度： メジャー

アラームに表示されるモニター名と行番号で問題を診断できます。

詳細については、テナントで「マイクロサービスホスティング」機能が有効になっている場合、Apama-ctrl マイクロサービスのログファイルもご確認ください。このタイプのアラームは、キャッチされていない例外によってモニター インスタンスの実行が終了し、通常、アプリが正常に動作しなくなるため、優先的に修正する必要があります。適切に処理されない場合、コリレーターのクラッシュにつながる可能性もあります。Apama-ctrl マイクロサービスのログファイル も参照してください。

An EPL app is running in an infinite or long-running loop

EPL アプリに無限ループや長時間ループが発生すると、コリレーター コンテキストが長時間ブロックされ、他のアプリが同じコンテキストで実行できなくなる可能性があります。さらに悪いことに、コリレータがガベージコレクション サイクルを実行できないため、メモリ使用量が過剰になり、アプリのメモリ不足につながる可能性があります。Apama-ctrl マイクロサービスは、このようなシナリオを識別し（アプリがコンテキストを長時間ブロックしている場合、コリレーターは警告メッセージをログに記録します）、アラームを発することで、ユーザーが問題を特定して修正できるようにします。

例えば、次のモニターは、コリレーターのメイン コンテキストをブロックします。

event MyEvent {
}

monitor Sample{
    action onload() {
        while true {
            // do something
            send MyEvent() to "foo";
        }
    }
}

上記の例では、Apama-ctrl によって次のアラームが生成されます。

  • アラームタイプ： APAMA_CTRL_WARN_<HASHCODE>
  • アラームテキスト： <EPLAppName>.<monitorName> - This EPL app is probably in an infinite or long-running loop and impedes the operation of your other apps. It is recommended that you deactivate and diagnose this app.
  • アラームの重大度： 警告

アラームで指定されたモニター名で問題を診断できます。

詳細については、テナントで「マイクロサービス ホスティング」機能が有効になっている場合、Apama-ctrl マイクロサービスのログファイルで確認できます。このタイプのアラームは、マイクロサービスとコリレーターのメモリ不足につながる可能性があるため、優先的に修正する必要があります。Apama-ctrl マイクロサービスのログファイル も参照してください。

EPL app restore timeout on restart of Apama-ctrl

Apama-ctrl マイクロサービスの再起動時に EPL アプリを復元するのに時間がかかり制限時間を超える場合、recovery.timeoutSecsテナントオプション（streaminganalyticsカテゴリ内）、またはデフォルトの60秒を超える場合、Apama -ctrl マイクロサービスがタイムアウトになりアラームが発生し、再起動して EPL アプリの復元を再試行することが示されます。アラームテキストには、タイムアウトの原因と考えられる EPL アプリの名前が含まれます。

  • アラームタイプ： eplapp_restore_timeout
  • アラームテキスト: Restoring EPL apps after Apama-ctrl microservice restart has timed out. The EPL app <app name> could not be restored. The following EPL apps may be the cause of this: <comma-separated list of app names>. The Apama-ctrl microservice will restart now, and restoring will be reattempted. If this continues to fail, the Apama-ctrl microservice will enter safe mode, disabling all EPL apps.
  • アラームの重大度: メジャー

Apama-ctrl マイクロサービスが、タイムアウトの原因が EPL アプリにあることを検出した場合にのみ、アラームテキストに次の情報が含まれます。
「The following EPL apps may be the cause of this： <アプリ名のカンマ区切りリスト>」
該当するアプリが検出されない場合、この情報はアラームテキストから省略されます。

Multiple extensions with the same name

このアラームは、Apama-ctrl マイクロサービスが起動プロセス中にデプロイされた拡張をアクティブにしようとし、同じ名前の拡張が複数ある場合に発生します。

  • アラームタイプ： extension_error
  • アラームテキスト： Multiple extensions with the same name have been found: <list of all duplicate extension names>
  • アラームの重大度： クリティカル

これにより、Apama-ctrl にデプロイされたすべての拡張機能が無効になります。デプロイされた拡張機能を使用するには、ユーザーは保持する拡張機能を決定し、重複する拡張機能を削除する必要があります。

備考
複数の重複がある場合、このアラームは一度だけ表示されます。

Smart rule configuration failed

このアラームは、スマートルールに無効な設定が含まれている場合に発生します。

  • アラームタイプ： smartrule_configuration_error
  • アラームテキスト： <Smart rule identifier>: Smart rule create/edit failed. One or more fields are invalid, please check smart rule configuration.
  • アラームの重大度： メジャー

原因を診断するには、診断とログのダウンロード で説明されているように、基本診断 zip ファイルをダウンロードしてください。ダウンロードに失敗した場合、管理者としてログオンし、/service/smartrule/smartrules?withPrivateRules=true への GET リクエストの結果を見てください。スマートルールの JSON を確認し、無効なスマートルール構成を探します。このようなスマートルールは修正する必要があります。

Apama マイクロサービスのログには、スマートルール構成の失敗の理由に関する詳細が含まれています。例えば、存在しないデータポイントで「計測のしきい値の場合、アラームを作成」スマートルールを構成することは無効です。

Smart rule restore failed

このアラームは、壊れたスマートルールがインベントリに存在し、コリレーターが起動時にそれを正しく回復できない場合に発生します。

  • アラームタイプ： smartrule_restore_failed
  • アラームテキスト： Smart rule restore failed. Contact support.
  • アラームの重大度： メジャー

原因を診断するには、診断とログのダウンロード で説明されているように、基本診断 zip ファイルをダウンロードしてください。ダウンロードに失敗した場合、管理者としてログオンし、/service/smartrule/smartrules?withPrivateRules=true への GET リクエストの結果を見てください。スマートルールの JSON を確認し、無効なスマートルール構成を探します。このようなスマートルールは、削除または修正する必要になる可能性があります。

Connection to correlator lost

このアラームは、Apama-ctrlマイクロサービスとコリレーター間の接続が失われた場合に発生します。これは発生してはなりませんが、高負荷状態によってトリガーする可能性があります。

  • アラームタイプ： lost_correlator_connection
  • アラームテキスト： Unable to ping correlator: <message>, Apama-ctrl will restart.
  • アラームの重大度： メジャー

Apama-ctrlは自動的に再起動します。頻繁に発生する場合は、製品サポート に報告してください。

Performance alarms

入力キューまたは出力キューが一杯になることは、重大なパフォーマンス低下の症状です。これは、イベントまたはリクエストが Apama または Things Cloud によって処理されるよりも速く、Apama または Things Cloudによって生成されていることを示唆しています。

コリレーターの入力キューと出力キューのパフォーマンスは定期的に監視されます。さまざまなタイプのアラームを発生させることができます。アラームテキストには、アラーム発生時のコリレーターステータスのスナップショットが含まれています。

このアラームは入力キューに対して発生します。

  • アラームタイプ： input_queues_filling
  • アラームテキスト： Correlator input queues are filling. If this alarm is being regularly raised, there is a chance that the correlator cannot process the requests at the rate at which they are arriving.
    Slowest receiver name: <name>,
    Slowest receiver queue size: <size>,
    Slowest context name: <name>,
    Slowest context queue size: <size>.
  • アラームの重大度： 警告

このアラームは出力キューに対して発生します。

  • アラームタイプ： output_queues_filling
  • アラームテキスト： Correlator output queues are filling. If this alarm is being regularly raised, there is a chance that Things Cloud is not able to process the requests at the rate the correlator is sending them.
    Slowest receiver name: <name>,
    Slowest receiver queue size: <size>,
    Slowest context name: <name>,
    Slowest context queue size: <size>.
  • アラームの重大度： 警告

このアラームは、入力キューと出力キューの両方に対して発生します。

  • アラームタイプ： input_output_queues_filling
  • アラームテキスト： Correlator input and output queues are filling. If this alarm is being regularly raised, there is a chance that Things Cloud is not able to process the requests at the rate the correlator is sending them, causing the slowest output queue to fill up.
    This might have also caused the slowest input queue to fill up.
    Slowest receiver name: <name>,
    Slowest receiver queue size: <size>,
    Slowest context name: <name>,
    Slowest context queue size: <size>.
  • アラームの重大度: メジャー

Apama ドキュメントの コリレーター ステータス統計のリスト も参照してください。

上記のアラームのテキストを確認して、どのキューがブロックされているかを確認してください。問題が発生すると、次のアラームがトリガーされ、その後に次のアラームが続く可能性があります。

  • アラームテキスト： Real-time event processing is currently overloaded and may stop processing your events. Please contact support.
  • アラームの重大度： クリティカル

このアラームは、各テナントの CEP キューが一杯になるたびに生成されます。
これは Things Cloud コアからのものですが、Apama-ctrl に関係します。

CEP エンジンにイベントを送信する Karaf ノードは、受信イベントのテナントごとのキューを維持します。このデータは、ホストされた CEP ルールの CEP エンジンによって処理されます。さまざまな理由により、これらのキューは満杯になり、新しく到着するデータに対応できなくなります。この場合、プラットフォームにアラームが送信され、エンドユーザーに状況が通知されます。

CEP キューが満杯になると、新しい受信イベントを処理するために古いイベントが削除されます。これを回避するには、キューが満杯になった原因を診断し、できるだけ早く解決しなければなりません。

CEP キューサイズは、バイト数ではなく、CEP イベントの数に基づきます。

原因を診断するには、次の操作を行います。Apama-ctrl マイクロサービスの実行速度が遅いのは、時間のかかるスマートルール、分析モデル、EPL アプリが原因である可能性があります。また、マイクロサービスがリソース不足に陥っている、コードが最適化されていないなどの理由も考えられます。上記のアラーム（またはマイクロサービス ログ、あるいは /correlator/status.json にある基本診断 zip ファイル）から、コリレーターの入力キューと出力キューを確認します。

  • 入力キューと出力キューの両方が満杯になっている場合、受信側の速度が遅く、おそらく EPL が Things Cloud に大量のリクエスト（またはコストが高すぎるリクエスト）を送信している可能性があります。
  • それ以外の場合、入力キューのみが満杯であれば、EPL は短時間で何度も実行されている可能性があります。基本診断 zip ファイルの cpuProfile.csv 出力、特にモニター名と CPU 時間を分析してみてください。プロファイラで収集されたデータは、他のボトルネックの特定にも役立つ場合があります。詳細については、Apama マニュアルの CPU プロファイラの使用 を参照してください。
  • それ以外の場合、接続や Things Cloud コアの問題が原因である可能性があります。

Parent tenant not subscribed

このアラームは、親テナントがサブスクライブされる前にサブスクライブされたサブテナントに対して発生します。

  • アラームタイプ： parent_tenant_not_subscribed
  • アラームテキスト： The microservice cannot function fully until the parent tenant is also subscribed to the microservice. Please contact the administrator.
  • アラームの重大度： メジャー

Apama-ctrl マイクロサービスを使用すると、任意の順序でテナントをサブスクライブできます。
ただし、親テナントがサブスクライブされていない限り、マイクロサービス機能はサブテナントでは機能しません。

このアラームは、親テナントがサブスクライブされるとクリアされます。

Analytics Builder dropped events

このアラームは、Analytics Builderモデルが入れ替えバッファの期間を超えて遅延したために、イベントをドロップする場合に発生します。

  • アラームタイプ： analyticsbuilder_dropped_events
  • アラームテキスト： Analytics Builder dropped <number> events because they were delayed beyond the reorder buffer duration. The last dropped event was received at <system time> (<number> seconds old): ‘<last dropped event string>’.
  • アラームの重大度： 警告

分析ビルダー モデルは、バッファを使用して受信イベントをソースタイム スタンプ順に並べ替え、順番に処理します。デフォルトでは、入力ブロックは、最大 1 秒の遅れでイベントを入れ替えます。イベントが入れ替えバッファの期間を超えて遅延して受信されると、処理されることなくドロップされる可能性があります。詳細については、入力ブロックとイベントタイミング を参照してください。

この問題を解決するには、入力イベントの入れ替えを無効にするか、入れ替えバッファの期間を長くします。入力ブロックの タイムスタンプを無視 パラメーターを有効にすると、入力イベントの入れ替えを無効にできます。タイムスタンプを無視 パラメーターを有効にすると、入力イベントは入れ替えずにできるだけ早く処理されます。入れ替えバッファの期間を長くするには、analytics.builder カテゴリの timedelay_secs テナントオプションを変更します。timedelay_secs の詳細については、モデルタイムアウトのキーを参照してください。