backend健全性は従来のロードバランシングの世界では常にプロトコルレイヤーから監視されます。ADCはサーバーにHTTPリクエストを送り、200 OKを受け取り、サーバーをプールに追加します。あるいはTCPプローブを行い、ポートが開いていれば健全とみなします。さらにはコンテンツ検証を行うこともあります：『応答にこの単語が含まれているか？』
このアプローチは外殻から見ています。内部からは見ていません。サーバーのディスク使用率が98%に達したこと、RAMがswapに落ちてパフォーマンスが崩壊したこと、GCサイクルが長くなったこと、データベース接続上限が埋まったことを見ません。サーバーは依然としてHTTP 200を返します — しかしユーザーリクエストに対して数秒の待機が発生します。
さらに悪いことに：プロトコルプローブはローカルとみなされ、サーバー自身の状態を報告しません。ADCはプローブが見たものしか見ません。サーバー上の蓄積したリソース圧迫や重要なプロセスの再起動ループはルーティング判断に影響しません。
ETM サーバーテレメトリーはこのギャップを埋めます。サーバー上のエージェントが自身の内部状態を継続的にADCに伝送します。ルーティングの判断は外部のプロトコルプローブではなく、内部から来るライブなデータに基づいて行われます。
TR7 ETMは、サーバー健全性をADCルーティングレイヤーのライブな入力としてモデル化します。このアプローチはクライアントセキュリティとサーバーobservabilityを同じプラットフォームで統合します。
サーバー上のエージェントがCPU負荷、メモリ使用率、swap圧迫、ディスクIOの飽和、ネットワークインターフェースのスループットをリアルタイムで測定します。データはADCに定期的な間隔で — 秒単位で — 伝送され、ルーティングの判断がこの最新データから供給されます。
重要なアプリケーションプロセスの健全性、再起動サイクル、garbage collection時間、開いているファイルディスクリプタ数、スレッドプール状態、アプリケーション固有のメトリクス（例：データベース接続上限）が監視されます。アプリケーションが健全でなければ、トラフィックはそのサーバーへ流れません。
ADCのロードバランシングアルゴリズムはETMテレメトリーから得られる健全性スコアに応じて動作できます。CPUの高いサーバーはトラフィックを少なく受け取り、IO飽和のあるサーバーは新規接続から外され、swapに落ちたサーバーはプールから自動的に除外されます。
クライアントセキュリティに使われる同じETMエージェントがサーバー上でも動作します。運用チームは単一のエージェント、単一の管理レイヤー、単一のテレメトリーモデルを使用します。backendのobservabilityのために別のツールを展開する必要はありません。
サーバーテレメトリーは単なるobservabilityではなく、ADCルーティング判断のライブなデータ源です。
単一CPU数、継続的な負荷平均、瞬間使用率、thermal状態がリアルタイムで測定されます。コアごとの負荷の異常やthermal throttleによるパフォーマンス低下がルーティング判断に反映されます。
総メモリと利用可能メモリ、swap使用率、page fault率、OOM killerのアクティビティが監視されます。swapに落ちたサーバーは自動的に低優先度プールに移せます。OOMリスクが顕著になったサーバーはトラフィックから外せます。
ディスク使用率、IO待機時間、IOPS数、キュー内リクエスト数、SMARTエラー数が監視されます。ディスク使用率のしきい値を超えたとき、またはIO飽和が高いときにサーバーがトラフィックから引き上げられます。
定義された重要プロセスが稼働しているか、最後の再起動時刻、再起動サイクル数が監視されます。継続的に再起動されているアプリケーションはトラフィックから引き上げられ、プールがオペレーター対応のためにマークされます。
サーバー上のアプリケーション固有のメトリクス — アプリケーションランタイムメトリクス（GC時間、event loop遅延）、データベース接続上限の飽和、キューの深さ — がエージェントを通じて取得できます。ADCはこれらのメトリクスをルーティング判断に取り込めます。
サーバーネットワークインターフェースのスループット、パケットロス率、retransmit数、アクティブなTCP接続数が監視されます。ネットワーク飽和のあるサーバーは自動的に低い重みでマークされます。
サーバー上のTLS証明書の有効期限、重要な構成ファイルのhash整合性、証明書ストアの変更が監視されます。期限が近づいた証明書はオペレーターに警告を出すとともに、ルーティングポリシーに取り込めます。
サーバー構成のベースラインからの逸脱が即座に捉えられます。未承認の構成変更、予期しないユーザーアカウント、新しいサービスの起動がイベントとしてETMに届きます。このシグナルはセキュリティと運用の両方の判断に反映されます。
ETMテレメトリーはサーバー単位の0〜100の健全性スコアに変換できます。ADCのロードバランシングアルゴリズム（round-robin、least-conn、weighted least-conn）はこのスコアを重みとして利用できます。スコアの低いサーバーはトラフィックを少なく受け取り、しきい値を下回ったサーバーはプールから外れます。
ディスク使用率の増加速度、メモリ消費トレンド、再起動頻度といったシグナルをpredictiveに解釈できます。サーバーがまだ障害を起こしていないうちに、短時間で障害を起こす可能性が高まったサーバーからトラフィックがソフトに引き上げられます。
サーバーテレメトリーはADCルーティングインテリジェンスのライブなデータ源です — 統合、スケーラビリティ、監査を含みます。
テレメトリーはADCコントロールプレーンへ定期的に流れます。ロードバランシングアルゴリズムはETMスコアに応じて動作できます。特定のルーティング判断はETMイベントに応じてトリガーできます。オペレーターはカスタムスクリプトを書くことなく、ポリシー言語にETMメトリクスを結びつけられます。
プロトコルベースのアクティブ健全性プローブ（HTTP、TCP、Oracle）は引き続き動作します。ETMテレメトリーはこのプローブの傍らに『内部からのビュー』レイヤーを追加します。ルーティングの判断は2つのソースを併せて評価します：『応答しているか？』（プロトコルプローブ）+『健全か？』（ETM）。
どのメトリクスをどの周期で収集するかをサーバーロールに応じて構成できます。Webサーバー向けにはCPU/RAM/IO、データベースサーバー向けには接続上限とquery latency、アプリケーションサーバー向けにはGCとスレッドプールを優先できます。
サーバー上のエージェントは最小限のリソース使用のために設計されています。高スループットのbackendでもパフォーマンス低下を起こすことなく動作します。メトリクス収集の密度は構成可能です。
テレメトリーを企業の監視とobservabilityプラットフォームへ転送できます。ETM自身の管理インターフェースの代わりに企業標準のobservability stackを使用したい場合にデータフローが提供されます。
単一のTR7クラスターから数千台のサーバーテレメトリーを収集できます。マルチリージョン構成では、TR7 Central Managementにより異なるリージョンのサーバーインベントリを単一のコンソールから表示できます。
アプリケーションサーバーのデータベース接続上限が飽和に近づいたとき、ETMはこれをADCに伝えます。ADCはそのサーバーの重みを段階的に下げ、新規接続を他のサーバーへ誘導します。ユーザーはtimeoutを見ません。backendが段階的に呼吸します。
バックアップまたはログ蓄積を理由にサーバーのディスク使用率が95%を超えると、ETMはイベントを生成します。サーバーがプールから自動的に外され、オペレーター対応のためにマークされます。ディスクが完全に埋まりサービスが崩壊することが防がれます。
メモリ使用率が継続的に増加しOOMリスクが高いサーバーは、まだ崩壊する前にETMによって低い重みに移せます。トラフィックが他のサーバーへソフトにシフトされ、インシデントに発展する前に問題が解決されます。
サーバー上のTLS証明書の有効期限が30日未満になるとETMに通知されます。オペレーターに警告が届きます。証明書が更新されるまでサーバーは重要なトラフィックを受け取らないか、アラームが引き上げられます。予期しない証明書エラーのリスクがなくなります。
ETM サーバーテレメトリーをお客様自身のbackendでライブで見てみましょう — パイロットサーバーグループ上で構築セッションを計画しましょう。