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