トリガー

ポリシーとしきい値は異常な状態を検出してVMデータビューに表示しますが、それ自体ではアクションを実行できません。トリガーを使用すると、ポリシー違反としきい値違反に反応し、設定可能なアクションのリストを実行できます。

仕組み

トリガーは、ポリシーやしきい値とは異なるレベルで動作します。後者は、単一のVMまたはVMグループに適用される設定オプションです。一方、トリガーは単一のポリシー違反やしきい値違反に直接結び付けられていません。むしろ、VMグループ内のすべての監視対象VMに由来するそのようなイベントのシーケンスに反応します。

この仕組みは、特定のアクションを必要とする状態を何と見なすかを決定する際の柔軟性を高めることを目的としています。例えば、キャッシュが再構築されるときに最大1回の低速なURL呼び出しを予期することがあります。ただし、1時間あたり5回以上の低速なURL呼び出しがある場合は、何かが間違っています。何が許容でき何が許容できないかの定義は、アプリケーションのタイプと実装に強く依存します。

設定

記録設定で、VMグループごとにトリガーを編集できます。トリガーは、再帰的に含まれるすべてのVMで動作します。VMグループと祖先のVMグループに異なるトリガーを定義することが可能で、両方のトリガーセットは個別に処理されます。

場合によっては、トリガーが頻繁に発火しすぎることがあります。その場合、jvmguardでは、基礎となる設定を変更する方法を考える時間ができるまで、トリガーを無効にできます。

トランザクション定義やjvmguardの他のエンティティと同様に、トリガーはトリガーセットに保存およびロードできます。これにより、トリガー定義を複数のVMグループへの開始点としてコピーアンドペーストできます。

トリガータイプ

トリガーには3つのタイプがあります。

ポリシートリガー: ポリシートリガーは、トランザクションのセットのポリシー違反が、指定された期間中に定義された数を超えたときに発火します。フィルターテキストフィールドは、ワイルドカード式または正規表現のトランザクション名パターンを取ります。

また、ポリシートリガーは特定のポリシー違反タイプに対して設定されます。それぞれ異なるトランザクション名に一致する複数のポリシートリガーを持つことができます。トランザクション定義とは異なり、ポリシートリガーには最初に一致したエントリのみが使用されるという名前マッチングはありません。同じトランザクション名に複数のトリガーを追加する場合、異なるイベントレートを設定することになるでしょう。そうしないと、両方のトリガーが同時に発火します。

トリガー条件は、ポリシー違反の実際の条件から切り離されています。さまざまなトランザクションで、トランザクションが「非常に低速」と特徴付けられるまでの異なる時間を定義でき、ポリシートリガーはこれらのイベントをカウントします。
しきい値違反トリガー: しきい値違反トリガーは、選択したテレメトリのしきい値違反のレートが設定値を超えたときに発火します。これには、同じVMグループに少なくとも1つのしきい値が設定されている必要があります。ポリシートリガーと同様に、トリガー条件は実際のしきい値を定義しません。しきい値は異なる子孫VMグループで異なる定義が可能で、しきい値違反トリガーはしきい値違反をカウントします。

例として、2つのマシングループ、高性能マシンとレガシーマシンがあるとします。高性能マシンでは、スレッド数が1000を超えてはならず、レガシーマシンではそのしきい値はわずか500です。「Powerful」と「Legacy」という名前のVMグループを作成し、各グループの記録設定に対応するしきい値を定義し、「すべてのJVM」グループにデフォルトのしきい値を定義します。次に、「すべてのJVM」グループで、スレッド数テレメトリのしきい値違反トリガーを定義します。そのトリガーは両方のVMグループを同時に処理します。
接続数トリガー: 接続中のVM数は、監視対象VMではなくjvmguardコレクターに由来するスカラー値です。接続数トリガーは、実行中のVMが少なすぎる場合にアクションを実行することを目的としています。設定された最小数はjvmguardサーバーの起動時にすぐには達成されないため、最小数に初めて達した後、または一定時間が経過した後にのみトリガーを有効にするオプションがあります。

トリガーアクション

各トリガーは、任意のアクションのリストを持つことができます。

トリガーに追加できるアクションのタイプは、2つのカテゴリに分類できます。

通知アクション: 通知はjvmguard内での消費のために作成できます。イベントログまたは受信トレイにエントリを書き込むことができます。受信トレイはユーザーごとに維持され、ユーザーごとに「未読ステータス」があります。外部的には、メールを送信したりWebhookを呼び出したりできます。

メールを送信するには、一般設定のSMTP設定が有効である必要があります。メールには、どのVMがトリガーを発火させたかを示す件名が付き、Webhookアクションでは文字シーケンス@TRIGGER@を使用して、このメッセージをヘッダー、クエリパラメータ、JSONリクエストボディに挿入できます。

データ収集アクション: 異常な状態への反応として、詳細な分析のためにより多くのデータを記録することを決定できます。これらのデータ記録オプションの中には、通常のjvmguard記録よりも侵襲的なものがあります。

例えば、HPROFヒープスナップショットの保存は定期的に行うべきではありませんが、メモリが少ない場合、メモリリークを見つけるのに役立ちます。HPROFスナップショットはJVMによって直接書き込まれ、ネイティブJVMTIプロファイリングエージェントのロードを必要としません。そのため、スナップショットが保存されるまでVMは停止しますが、これは低リスクの操作です。JProfilerやその他のJavaプロファイラーはHPROFスナップショットを開くことができます。

スレッドダンプは、JVMで現在何が起こっているかを調査する基本的な低オーバーヘッドの方法です。イベントタイプ「期限超過」のポリシートリガーはスレッドダンプを保存できるため、トランザクションがどのメソッドでハングしているかをすぐに確認できます。

JProfilerスナップショットの記録は、ネイティブJVMTIエージェントのロードを必要とするデータ収集のエスカレーションです。このトピックの詳細については、本番環境でのプロファイリングの章を参照してください。データ収集アクションは、接続中のVMの横の「アクション」リンクをクリックすると、「VM」ビューでも利用できます。

アクションのリストは順番に実行されます。1つのアクションが失敗した場合、jvmguardは次のアクションにジャンプし、トリガーアクションの実行を終了しません。