APIゲートウェイ・エンドポイントが実際に到達可能かどうかを監視する方法
APIゲートウェイ・サービスで作成されたAPIゲートウェイの状態および到達可能性を監視する問題のトラブルシューティング方法を確認します。
このガイダンスは、APIゲートウェイ・エンドポイントにアクセス可能かどうかを監視する必要がある場合に使用します。APIゲートウェイのメトリックは、トラフィック、レイテンシおよびレスポンス・パターンを示しますが、1つの組込みのゲートウェイ・アライブ・ステータス・メトリックは提供されません。エンドポイントの有効性については、デプロイされたAPIパスでヘルス・チェックを使用し、APIゲートウェイ・メトリックを使用してトラフィックおよび障害を調査します。
問題の症状
次の症状が1つ以上表示される場合があります。
-
APIゲートウェイ・エンドポイントに使用できる直接到達可能性シグナルはありません。
-
APIゲートウェイ・メトリックは、専用のヘルス・ステータス・メトリックを表示しません。
-
トラフィック・ボリューム、レイテンシおよびレスポンス・コードの傾向は、エンドポイントの稼働率を確認しません。
-
APIゲートウェイ・デプロイメント・エンドポイントにOCIネイティブ・ヘルス・チェックが構成されていません。
考えられる理由
エンドポイント到達可能性およびゲートウェイ・メトリックは、リクエスト・パスの様々な部分を測定します。
-
ヘルス・チェックは、デプロイされたAPIパスがヘルス・チェック・プローブの場所から到達可能かどうかを示します。
-
APIゲートウェイ・メトリックは、トラフィックがゲートウェイに到達した後のゲートウェイの動作を示します。
-
到達可能なゲートウェイは、増加する
4xxまたは5xxレスポンスを返すことができます。 -
トラフィックがほとんどまたはまったくないゲートウェイには、最近のメトリック・データ・ポイントがほとんどないため、メトリックのみが弱いライブ・シグナルになります。
エンドポイント存続のヘルス・チェックの構成
デプロイされたエンドポイントが到達可能であるというバイナリ・シグナルまたはニア・バイナリ・シグナルが必要な場合は、ヘルス・チェックを使用します。
次の要件を満たすAPIルートを選択します:
-
ルートは、予測可能な成功レスポンス(
200や204など)を返します。 -
ルートはサインイン・リダイレクトをトリガーしません。
-
ルートには、ユーザー単位の資格証明や短期間の問合せパラメータは必要ありません。
-
ルートは書込み操作を実行したり、ビジネス・サイド・エフェクトを作成したりしません。
-
ルートは、モニターするAPIゲートウェイ・パスを表します。
ヘルス・チェックを作成する前に、ルートを手動で確認します:
curl -i https://<gateway-hostname>/<deployment-path-prefix>/<api-route-path>
検証したデプロイ済のエンドポイントをターゲットとするOCIヘルス・チェックを作成します。次のモニタリング目標のヘルス・チェックを使用します。
-
エンドポイント到達性。
-
外部可用性チェック。
-
エンドポイントが予期したステータス・コードで応答を停止したときにアラートを生成します。
APIゲートウェイ・メトリックの確認
APIゲートウェイ・メトリックを使用して、エンドポイントに到達した後のトラフィックおよび障害パターンを把握します。メトリック・エクスプローラで、oci_apigatewayネームスペースのパブリックAPIゲートウェイ・メトリックを確認します。
次のメトリックおよびディメンションから開始します。
-
HttpResponses、httpStatusCodeおよびhttpStatusCategory。 -
BackendHttpResponses、backendHttpStatusCodeおよびbackendHttpStatusCategory。 -
Latency、IntegrationLatencyおよびInternalLatency。 -
resourceId、deploymentIdおよびroute。
HttpResponsesを使用して、APIゲートウェイによって返されたステータス・コードを確認します。バックエンド・サービスによって返されたステータス・コードを確認するには、BackendHttpResponsesを使用します。
モニタリング結果の解釈
ヘルス・チェックのステータスとAPIゲートウェイのメトリックを一緒に使用して、問題が発生した場所を特定します:
-
ヘルス・チェックが失敗した場合、エンドポイントがプローブ・パスからアクセスできないか、異常である可能性があります。
-
ヘルス・チェックは成功したが、
4xxまたは5xxレスポンスが増加した場合、エンドポイントは到達可能ですが、リクエストは失敗します。 -
トラフィックが少なく、メトリックに最新のデータが表示されない場合、欠落しているデータはゲートウェイが使用できないことを証明しません。
-
到達可能性は成功したが、待機時間が増加した場合、ゲートウェイは到達可能ですが、リクエスト処理が低下する可能性があります。
修正モニタリング・ギャップ
回答する必要がある質問に一致する監視シグナルを使用します。
-
エンドポイントの存続性を監視するには、デプロイされたAPIルートのヘルス・チェックを構成します。
-
レスポンス動作を調査するには、APIゲートウェイのメトリックを確認します。
-
可用性と動作の両方を監視するには、ヘルス・チェックをAPIゲートウェイのメトリックおよびアラームと組み合せます。
-
誤った結論を回避するために、1つのAPIゲートウェイ・メトリックをダイレクト・ゲートウェイ・アライブ・インジケータとして使用しないでください。
エンドポイント・モニタリングの検証
エンドポイント・モニタリングを構成したら、次の設定を確認します。
-
curlを使用してテストするときに、選択したAPIパスが予期されるステータス・コードを返すことを確認します。 -
OCIヘルス・チェックでエンドポイントを正常にプローブできることを確認します。
-
メトリック・エクスプローラにゲートウェイのリクエストおよびレスポンスの傾向が表示されることを確認します。
-
アラームがエンドポイントの到達可能性の問題とレスポンス・コードまたはレイテンシの問題を区別することを確認します。
詳細情報
詳細は、次を参照してください: