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

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

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

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

ユーザーが「CEP管理」の読み取りアクセス許可を持っている場合、ストリーミング分析アプリケーションの下部から診断情報をダウンロードするための2つのリンクを使用できます。1つは基本的な診断情報(診断リンク)をダウンロードするためのリンクで、もう1つは拡張(より資源集約的な)診断情報(拡張リンク)をダウンロードするためのリンクです。これらのリンクは、ホーム画面の下部に表示されるほか、Analytics BuilderやEPL アプリのページに移動したときに表示されるページ（EPLアプリマネージャーやモデルマネージャー内）にも表示されます。

問題が発生したとき、またはEPLアプリをデバッグするときに、この診断情報が役立ちます。サポートチケットを申請する際にも、Things Cloud Supportへ提供いただくことで問題解決につながる可能性があります。リンクの横にバージョン番号が表示されます。

基本的な診断情報は、diagnostic-overview<timestamp>.zipという名前のzipファイルで提供され、次の情報が含まれます（通常は数メガバイトで、約5秒で生成されます）。

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

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

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

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

上記についてご不明点がある場合は Things Cloud Support にお問い合わせください。

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

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

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

RESTエンドポイントの監視

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

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

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

備考
Apama-ctrl自体の状態に関するアラームは、Analytics Builder 10.5.0およびEPL アプリ 10.5.0から入手できます。

アラームは、次の方法で閲覧できます。

  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をご覧ください。

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

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

Safe mode on startup

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

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

マイクロサービスのモード(通常モードまたはセーフモード)をチェックするには、レスポンスにsafe_modeフラグを含むservice/cep/diagnostics/apamaCtrlStatus (EPL アプリ 10.5.7およびAnalytics Builder 10.5.7から利用可能)にRESTリクエストを行います。

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

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

Deactivating models in the Apama-ctrl-starter microservice

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

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番目のバリエーション:

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

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

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

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

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

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

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 WARN
   }
}

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

1番目のアラーム:

2番目のアラーム:

3番目のアラーム:

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ログで確認できます。このタイプのアラームは、これらのキャッチされない例外によってそのモニターインスタンスの実行が終了するため、優先順位として固定する必要があります。これは通常、アプリケーションが正しく機能しないことを意味します。適切に処理しないと、コリレーターがクラッシュする可能性もあります。

An EPL file blocks the correlator context for too long

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

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

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

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

アラームで指定されたモニター名とコンテキスト名で問題を診断できます。

詳細については、テナントで「マイクロサービスホスティング」機能が有効になっているかどうかもApamaログで確認できます。これらのシナリオでは、マイクロサービスとコリレーターがメモリー不足になる可能性があるため、このタイプのアラームは優先順位として固定する必要があります。

EPL app restore timeout on restart of Apama-ctrl

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

以下の情報は、タイムアウトが一部のEPLアプリによるものであることをApama-ctrlマイクロサービスが検出した場合にのみ、アラームテキストに含まれます： “The following EPL apps may be the cause of this: <アプリケーション名のカンマ区切りリスト>.". そのようなアプリケーションが検出されない場合、この情報はアラーム テキストから省略されます。

Multiple extensions with the same name

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

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

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

Smart rule configuration failed

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

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

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

Smart rule restore failed

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

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

Connection to correlator lost

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

Apama-ctrlは自動的に再起動します。頻繁に発生する場合は、Things Cloud Supportに報告してください。

Performance alarms

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

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

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

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

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

Apama ドキュメントの コリレーターステータス統計のリスト もご覧ください。

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

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

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

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

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

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

Parent tenant not subscribed

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

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

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