ノードが一定期間コントローラと通信していない場合、コントローラはそのノードを履歴ノードとして記録します。コントローラは、そのノードに関するルール評価などの一部の処理アクティビティを中断します。

ノードの削除期間が終了する前にノードがコントローラとの接続を再開した場合、コントローラはそのノードをアクティブな状態に戻します。それ以外の場合、ノードはコントローラから完全に削除され、ノードレベルのデータは UI でアクセスできなくなります。ノードが削除されても、ノードのティアとアプリケーションレベルの履歴メトリックデータは引き続き使用できます。

デフォルト設定では、約20日ノードのアクティビティが確認できない場合、コントローラはノードを履歴と見なし、30日後に削除します。ノードの作成および破棄が頻繁に行われる非常に動的なアプリケーション環境では、リサイクルされたノードがコントローラの場合と同様に処理されるように、AppDynamics でノードのアクティビティタイムアウト期間を短くすることをお勧めします。

ノードアクティビティのタイムアウト期間は、ノードの保持期間またはアクティビティの設定によって決定されます。

履歴ノードの名前を新しいノードに割り当てることができます。[Node name reuse] は Java エージェントのオプションで、有効にするとコントローラにノード名を再利用するよう指示するので、存続時間の短い複数のノードによって、指定されたティアで生成されたデータは単一の論理ノードに関連付けられます。

ノードアクティビティとエージェントのライセンス

ライセンシング目的のため、コントローラは直前の5分間にエージェントからデータを受信しなかった場合、そのエージェントのライセンスを解放します。このライセンスの可用性の動作は、履歴ノード状況やノード削除のタイムアウト設定の影響は受けません。

ノードアクティビティ設定の構成

ノードアクティビティ設定はアカウントレベルの設定で、ルート AppDynamics 管理者は管理コンソールから変更できます。

  • node.permanent.deletion.period：コントローラと通信できなくなったノードがシステムから完全に削除されるまでの時間（時間単位）。データは削除されます。この期間後にエージェントがレポートを再開する場合は、新しいノードとして開始します。したがって、ノードレベルでは履歴データは使用できません。ティアおよびアプリケーションレベルでは履歴データが表示され、クラスタのロールアップは通常どおりに行われます。
    デフォルトは、720 時間で、この設定の最小値は 6 時間、最大値に制限はありません。 
  • node.retention.period：コントローラと通信できなくなったノードが削除されるまでの時間（時間単位）。この場合、コントローラ UI にはノードが表示されませんが、システムには引き続き保持されます。これらの時間内にエージェントでレポートが再開されると、UIに再表示され、カウンタがリセットされます。デフォルト値は500時間、最小値は1時間です。
    この設定の最大値には制限がありません。
    ノードの保持期間に関する追加の備考は、次のとおりです。

    • マシンエージェントがノードに関連付けられている場合も、ノードはノード保持期間の影響を受けます。アプリケーション サーバ エージェントに関連付けられているマシンエージェントが実行されている場合も、ノードの保持期間は有効です。

    • マシンエージェントが次の状況でない限り、コントローラに表示されないバックグラウンドで実行されているマシンエージェントをいくつでも持つことができます。

      • シャットダウンされた、またはコントローラに接続できないホストマシンで実行されている。

      • インストゥルメント化されていないか、アンインストールされている。

      • 停止されている。

    • ノードをノードの保持期間対象として考慮する必要がある場合は、次のようにシャットダウン時に履歴としてマークを付ける必要があります。

      ‑Dappdynamics.jvm.shutdown.mark.node.as.historical=true
      CODE

コントローラから切断された時のエージェントの動作

ネットワークの問題またはエージェントのエラーがある場合、コントローラは到達不能になる可能性があります。コントローラサーバは、さまざまな理由でダウンしている場合もあります。

コントローラに1分間到達できない場合、

  • エージェントは待機状態になり、その間トランザクションを検出しません。
  • 収集されたスナップショットとイベントはすべてドロップされ、失われます。スナップショットやイベントがドロップされるのは、キャッシュするのにメモリを消費しすぎるからです。
  • コントローラに送信されていないメトリックはすべてメモリに保存されます。メトリックを保持することによるメモリへの影響は大きくありません。 
  • コントローラに送信されていない新規のビジネストランザクション登録は、メモリに保存されます。
  • エージェントは毎分コントローラへの接続を試み、完全な構成がダウンロードできると通常のアクティビティを再開します。

コントローラが次の1〜2分で到達可能になった場合、

  • メモリに保存されたメトリックはすべてコントローラに送信されます。 
  • メモリに保存されている新規のビジネストランザクション登録は、コントローラに送信されます。
  • 再接続の20秒前に収集されたスナップショットやイベントは、コントローラに送信されます。

1分間隔の試行を3回失敗した後コントローラに到達できない場合は、

  • エージェントはミュートされ、すべてのビジネストランザクションのインターセプタは無効になります。モニタ対象アプリケーション エントリ ポイントのメソッドが実行されるときもインターセプタは呼び出されますが、動作しません。新しいビジネストランザクションの検出や登録はされません。相関イグジットポイントは「notxdetect=true」などのヘッダーを設定します。これにより、ダウンストリームティアもこのトランザクションを無視するように指示します。 
  • JMX メトリックはアプリケーション サーバ メモリに格納され、再接続後にコントローラに送信されるので、メトリック履歴にギャップはありません。 
  • 過去 3 分間の定期的なメトリックはメモリに保存されます。3 分より古いメトリックは、メモリから消去されます。 
  • エージェント構成チャネルとメトリックチャネルは、引き続き毎分1回コントローラへの接続を試みます。

エージェントは、1 分間隔で 7 回、その後 5 分間隔でコントローラへの接続を試みます。5 分経ってもコントローラに再接続できない場合は、ライセンスは解放され他のエージェントが使用できます。 

接続が成功し、エージェントが完全な構成およびライセンスをダウンロードできる場合、

  • 過去 3 分間の JMX メトリックや Windows パフォーマンスカウンターなどの定期的なメトリックはすべて、コントローラに送信されます。コントローラは、ロールアップが完了しているなど、収集されてから時間がたっているメトリックをドロップします。
  • エージェントは再度アクティブになり、ビジネストランザクションインターセプタは再度有効化され、ビジネストランザクションはモニタリングされスナップショットを撮られる場合もあります。新しいビジネストランザクションが検知、登録され、ダウンストリーム相関は再度有効になります。