典型的なヘルスチェックはエンドポイントにリクエストを送り、200レスポンスを見てサービスを健全とマークします。モダンなアプリケーションではこれでは不十分です。アプリケーションのホームページが応答しながら、データベース接続が遅く、キャッシュレイヤーが壊れ、ダウンストリームの依存関係が落ちている、またはログインフローが動作しなくなっていることがあります。ロードバランサーがこの違いを見えない場合、応答はするが実際の作業はできないバックエンドへのトラフィックルーティングを続けます。
シングルステップチェックはセッションベースのプロトコルでさらに不十分です。FTP、LDAP、Oracle、またはカスタムTCPプロトコルでは、ポートが開いていることはサービスが健全であることを意味しません。実際のヘルスチェックはログイン、コマンドの送信、期待されるレスポンスの受信、必要に応じてログアウト、そしてレスポンスコンテンツの検証を行う必要があります。そうしないとサービスは到達可能に見えながら、実際のユーザー操作は失敗します。
コンテンツ検証はプレーンテキストマッチングに限定されると脆弱になります。APIは常に「OK」という単語を返しながら、JSON内の依存関係の状態、レイテンシメトリック、またはビジネスルールが失敗していることがあります。ヘルスチェックがレスポンスの意味をクエリできない場合、アプリケーションレベルの劣化が遅れて検出されます。
正しいアプローチは、プロトコルの深さ、マルチステップシナリオ、コンテンツクエリ、設定可能なrise/fallしきい値でヘルスチェックを処理することです。プローブ操作はメイントラフィックフローから分離して実行する必要があり、スローまたは停止したヘルスチェックがユーザートラフィックを遅延させないようにする必要があります。
TR7 アクティブヘルスモニタリングはこのモデルを提供します：単一の設定から11プロトコルを監視し、マルチステップシナリオを実行し、JSONataでコンテンツの意味を検証し、真に健全なターゲットのみをローテーションに維持します。
TR7はヘルスチェックを単一プロトコルの制御からマルチプロトコル、シナリオベース、コンテンツ検証された決定システムに変換します。
TCP、UDP、HTTP、HTTPS、PING、DNS、FTP、FTPS、LDAP、LDAPS、Oracleのチェックがすべて同じヘルスチェックオブジェクトから管理されます。選択されたcheckTypeに応じて、関連するフィールドのみが表示され、オペレーターは無関係なパラメータに煩わされません。
TCP、UDP、Oracleチェックでは、send、expect、regex、waitステップを使って順序付けられた制御フローを構築します。いずれかのステップが失敗すると、プローブは失敗とマークされ、バックエンドのヘルス状態がそれに応じて更新されます。
HTTPとHTTPSチェックでは、JSONataクエリを使用してJSONレスポンスの内部の実際の状態を読み取ります。バックエンドは200を返すだけでは健全とみなされません — 依存関係の状態、スコア、レイテンシ、またはビジネス状態などのフィールドも確認できます。
バックエンドを不健全とマークするために必要な連続した失敗レスポンスの数と、ローテーションに戻すために必要な連続した成功レスポンスの数が独立して設定されます。これにより一時的なネットワーク変動がバックエンドをローテーションに継続的に出し入れすることを防ぎます。
アクティブヘルスモニタリングにより多様なサービスタイプが同じエディターから定義可能、テスト可能、運用しきい値で管理可能になります。
TR7はTCP、UDP、HTTP、HTTPS、PING、DNS、FTP、FTPS、LDAP、LDAPS、Oracleのヘルスチェックをサポートします。オペレーターはOracleデータベース、LDAPディレクトリ、DNSサーバー、FTPSリポジトリ、またはHTTP APIに別々のツールを必要としません。選択されたプロトコルタイプに基づいて関連するフィールドが表示され、無関係なフィールドは非表示になります。このモデルにより異種のバックエンドにわたるヘルスチェックが標準化され、保守しやすくなります。
TCPチェックでは、sendText、expectText、expectRegex、waitステップを順番に実行できます。SMTPバナー、IMAP機能クエリ、Redis PING/PONG交換、MQTTレスポンス、カスタムTCPプロトコルメッセージがこのモデルでテスト可能です。単に接続を開くのではなく、実際のプロトコルダイアログが実行されます。いずれかのステップが期待された結果を生成しない場合、バックエンドは不健全とマークされます。
UDPチェックでは、send、wait、expectText、expectRegexステップが使用できます。送信するデータはtext、hex、base64形式で定義でき、バイナリプロトコルプローブのための柔軟性を提供します。DNS、NTP、RADIUS、SIP、および類似のUDPサービスでは、ポートが開いているかどうかだけでなく、期待されるプロトコルレスポンスが検証されます。これによりUDPサービスもアクティブで意味のある方法で監視できます。
HTTP/HTTPSヘルスチェックはメソッド、URI、カスタムヘッダーリスト、リクエストボディ、仮想ホストをサポートします。APIエンドポイントをAuthorizationヘッダー、JSONボディ、またはカスタムHostヘッダーでプローブできます。許容されるステータスコードは単一の値でなくてもよく、200、204、または304をすべて健全とみなせます。この設計によりヘルスチェックが実際のアプリケーション使用に近づきます。
contentCheckModeをjsonataに設定すると、レスポンスボディがJSONとして評価され、JSONata式が実行されます。サービスの状態、依存関係の結果、データベースレイテンシ、またはビジネスメトリックがすべて単一の式内でチェックできます。式がtruthy結果を生成するとバックエンドは健全で、falsy結果はマークされ失敗です。JSONataエラーはログに記録され、正しくない式や予期しないレスポンス構造が可視化されます。
JSONataを必要としないシンプルなシナリオでは、contentQueryがレスポンスボディ内でテキスト検索を実行します。「Welcome」、「UP」、「Service Ready」などのマーカー文字列、またはアプリケーション固有のテキストを素早くチェックできます。このモードはシンプルなヘルスエンドポイントやレガシーアプリケーション向けの低複雑さのソリューションを提供します。オペレーターはシナリオに基づいて基本チェックとJSONataを選択します。
LDAP/LDAPSチェックはポートアクセスだけでなく実際のバインド操作もテストできます。ユーザー名とパスワードで実行されるバインドにより、ディレクトリサービスが認証レベルで検証されます。ポートが開いていてもバインドキュー、認可、またはサービスに問題がある場合はバックエンドを不健全とマークできます。これはAAMとエンタープライズアクセスフローに特に重要な可視性を提供します。
Oracleヘルスチェックは接続の詳細、ユーザー名、パスワード、シナリオステップをサポートします。executeCmdを通じてSQLが実行され、期待されるテキストまたは最小行数が検証されます。単純な接続テストではなく、実際のデータアクセスとビジネスメトリックをクエリできます。このアプローチによりデータベース可用性の問いがアプリケーションの観点から意味のあるものになります。
ヘルスチェックはインターバル、タイムアウト、しきい値、シナリオの構成、インスタンスID、システム内部の特殊な制御と共に動作します。
testIntervalは0.5から3600秒まで設定可能です；デフォルトは1秒です。timeoutは0.01から3600秒まで設定可能です。積極的なタイムアウトにより迅速なフェイルオーバーが可能ですが、誤検知のリスクを増加させる可能性があり、サービスの動作に合わせて調整すべきです。
requiredFailureのデフォルトは2、requiredSuccessのデフォルトは3です。これらのしきい値はサービスがローテーションからどのくらい速く削除され、どのくらい慎重に戻されるかを決定します。しきい値の両側が独立して管理され、一時的な変動をフィルタリングします。
単一のヘルスチェックはAND/ORロジックを使用して複数のアトミックチェックを組み合わせることができます。これにより単一のプローブ結果だけでなく、複数の依存関係またはプロトコルステップを一緒に評価できます。複雑なサービスの健全性がより現実的にモデル化されます。
同じヘルスチェックは各バックエンドのために別々の状態を維持します。ヘルスチェックのインスタンスIDはチェックとターゲットによって差別化されます。これにより同じチェックプロファイルが複数のターゲットに適用されても、各ターゲットのヘルス履歴が独立して追跡されます。
negateの設定により通常の成功ロジックが逆になります。このモードは特定のURLが到達不能であることが期待される、特定のレスポンスが返されないことが期待される、またはサービスパスがアクセス不能のままであることが期待されるシナリオで使用されます。通常なら成功とみなされるレスポンスは失敗として扱われ、逆もそうなります。
ゲートウェイモニターやクラスターIPの接続チェックなどのシステム内部ヘルスチェックは自動的に生成できます。これらのチェックはアプリケーションバックエンドだけでなく、TR7の周囲の接続とアップストリームの到達可能性状態を監視するためにも使用されます。モデルはGTM側のデータセンターチェックなどの追加チェックタイプで拡張できます。
EコマースチームはHTTPチェックとJSONataを使用して、カートサービスが200を返すだけでなく、データベースレイテンシと可用性メトリックが範囲内であることも検証できます。スローまたは依存関係が劣化したバックエンドは自動的にローテーションから削除されます。
銀行チームはOracleチェックを使用して接続を開くだけでなく実際のSQLクエリを実行できます。期待される行数またはクエリ結果が満たされない場合、バックエンドは不健全とマークされ、トラフィックは安全なターゲットに誘導されます。
政府アプリケーションはディレクトリサービスがポートレベルだけでなく実際のバインド操作を通じて動作しているかを検証できます。ポートが開いていても認証が失敗する場合、システムはこれをヘルス問題として扱います。
テレコムチームはDNSチェックを使用して重要なドメインの実際のレコードクエリを実行できます。DNSポートが開いているだけでは不十分 — リゾルバーが期待される回答を生成することで健全とみなされます。
11プロトコル、マルチステップシナリオ、JSONataコンテンツ検証にわたる信頼性の高いヘルスデータにトラフィック決定を基づかせます。お客様自身のサービスでのライブセットアップをご案内します。