kube-apiserver コンポーネントは、Kubernetes の RESTful API を提供します。この API により、外部クライアントやクラスター内の他のコンポーネントが ACK クラスターと対話できます。このトピックでは、kube-apiserver コンポーネントのメトリック、ダッシュボードの使用方法に関するガイダンス、および一般的なメトリックの異常について説明します。
始める前に
アクセス方法
詳細については、「コントロールプレーンコンポーネントをモニタリングするためのダッシュボードの表示」をご参照ください。
メトリックのリスト
メトリックは、コンポーネントのステータスとパラメーターを公開するために使用されます。次の表は、kube-apiserver コンポーネントのメトリックを説明しています。
メトリック | タイプ | 説明 |
apiserver_request_duration_seconds_bucket | ヒストグラム | このメトリックは、API Server クライアントから API Server へのさまざまなリクエストのアクセスレイテンシー分布を追跡するために使用されます。 リクエストのディメンションには、以下が含まれます。
API Server ヒストグラムのバケットのしきい値は |
apiserver_request_total | カウンター | API Server へのさまざまなリクエストのカウンター。リクエストのディメンションには、Verb、Group、Version、Resource、Scope、Component、HTTP contentType、HTTP code (応答の HTTP ステータスコード)、および Client が含まれます。 |
apiserver_request_no_resourceversion_list_total | カウンター |
|
apiserver_current_inflight_requests | ゲージ | API Server が現在処理しているリクエストの数。リクエストには次の 2 つのタイプがあります。
|
apiserver_dropped_requests_total | カウンター | スロットリング中に API Server が積極的にドロップするリクエストの数。HTTP の戻り値は |
etcd_request_duration_seconds_bucket | ヒストグラム | このメトリックは、API Server から etcd へのリクエストのレイテンシー分布をカウントします。 リクエストのディメンションには、Operation と Type (操作オブジェクトのタイプ) が含まれます。 バケットのしきい値は |
apiserver_flowcontrol_request_concurrency_limit | ゲージ | API 優先度と公平性 (APF) リクエストの同時実行数制限。これは、優先度付きキューの最大同時実行数制限を示します。これは、キューが理論的に同時に処理できるリクエストの最大数です。これにより、API Server がスロットリングポリシーを使用して、異なる優先度のキューにリソースを割り当て、高優先度のリクエストが迅速に処理されるようにする方法を理解するのに役立ちます。 このメトリックは Kubernetes v1.30 で非推奨となり、v1.31 で削除されます。Kubernetes v1.31 以降を実行するクラスターでは、代わりに apiserver_flowcontrol_nominal_limit_seats メトリックを使用してください。 |
apiserver_flowcontrol_current_executing_requests | ゲージ | 優先度付きキューで現在実行されているリクエストの数。これは、キューの実際の同時ペイロードを示します。これにより、API Server の実際のペイロードを理解し、システムが最大同時実行数制限に近づいているかどうかを判断して、過負荷を防ぐのに役立ちます。 |
apiserver_flowcontrol_current_inqueue_requests | ゲージ | 優先度付きキューで処理を待っているリクエストの数。これは、キューのリクエストバックログを示します。これにより、API Server のトラフィックプレッシャーと、キューが過負荷になっているかどうかを理解するのに役立ちます。 |
apiserver_flowcontrol_nominal_limit_seats | ゲージ | APF の公称同時実行数制限シートの数。これは、シート単位で測定された API Server の理論的な (公称) 最大同時処理能力です。これにより、API Server がスロットリングポリシーを使用して、異なる優先度のキューにリソースを割り当てる方法を理解するのに役立ちます。 |
apiserver_flowcontrol_current_limit_seats | ゲージ | APF の現在の同時実行数制限シートの数。これは、優先度付きキューの現在の同時実行数制限を示します。これは、動的調整後に許可される最大同時実行シート数であり、キューの実際の同時実行能力を反映しており、システム負荷やその他の要因によって動的に変化する可能性があります。 nominal_limit_seats とは異なり、この値はグローバルなスロットリングポリシーの影響を受ける可能性があります。 |
apiserver_flowcontrol_current_executing_seats | ゲージ | APF のために現在実行されているシートの数。これは、優先度付きキューで現在実行されているリクエストに対応するシートの数を示します。これは、キューで消費されている同時リソースを反映しています。これにより、キューの実際の負荷を理解するのに役立ちます。 current_executing_seats が current_limit_seats に近い場合、キューの同時リソースが枯渇寸前である可能性があります。 API Server の maxMutatingRequestsInflight および maxRequestsInflight パラメーターの値を増やすことで、構成を最適化できます。構成ページへのアクセス方法とパラメーター値については、「Pro マネージドクラスターのコントロールプレーンコンポーネントのパラメーターをカスタマイズする」をご参照ください。 |
apiserver_flowcontrol_current_inqueue_seats | ゲージ | APF のために現在キューに入っているシートの数。これは、優先度付きキューで処理を待っているリクエストに対応するシートの数を示します。これは、キューで処理を待っているリクエストによって占有されているリソースを反映しています。これにより、キューのバックログを理解するのに役立ちます。 |
apiserver_flowcontrol_request_execution_seconds_bucket | ヒストグラム | リクエストの実際の実行時間。これは、リクエストが実行開始から完了するまでにかかる時間を記録します。 時間間隔は {0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30} です。単位は秒です。 |
apiserver_flowcontrol_request_wait_duration_seconds_bucket | ヒストグラム | リクエストがキューで待機する時間の分布。これは、リクエストがキューに入ってから実行が開始されるまでの待機時間を記録します。 時間間隔は {0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30} です。単位は秒です。 |
apiserver_flowcontrol_dispatched_requests_total | カウンター | 正常にスケジュールされ、処理されたリクエストの数。これは、API Server によって正常に処理されたリクエストの総数を反映しています。 |
apiserver_flowcontrol_rejected_requests_total | カウンター | 同時実行数制限またはキュー容量を超えたために拒否されたリクエストの数。 |
apiserver_admission_controller_admission_duration_seconds_bucket | ヒストグラム | アドミッションコントローラーの処理レイテンシー。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate または admit)、およびリクエストが拒否されたかどうか (true または false) が含まれます。 バケットのしきい値は |
apiserver_admission_webhook_admission_duration_seconds_bucket | ヒストグラム | アドミッション Webhook の処理レイテンシー。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate、リクエストの有効性をチェックするため、または admit、有効な場合にリクエストを許可するかどうかを決定するため)、およびリクエストが拒否されたかどうか (true または false) が含まれます。 バケットのしきい値は |
apiserver_admission_webhook_admission_duration_seconds_count | カウンター | アドミッション Webhook によって処理されたリクエストのカウンター。ラベルには、アドミッションコントローラー名、操作 (CREATE、UPDATE、CONNECT など)、API リソース、操作タイプ (validate または admit)、およびリクエストが拒否されたかどうか (true または false) が含まれます。 |
cpu_utilization_core | ゲージ | CPU 使用率。単位: コア。 |
memory_utilization_byte | ゲージ | メモリ使用量。単位: バイト。 |
up | ゲージ | サービスの可用性。
|
ダッシュボード使用ガイド
ダッシュボードは、コンポーネントのメトリックと関連する Prometheus Query Language (PromQL) クエリを使用して構築されています。これには、主要メトリック、概要、リソース分析、QPS とレイテンシー、APF スロットリング、アドミッションコントローラーと Webhook、およびクライアント分析のセクションが含まれます。
次の手順は、一般的なワークフローを説明しています。
主要メトリック: クラスターの主要メトリックをすばやく表示します。
概要: API Server の応答時間、処理中のリクエスト数、およびスロットリングが発生したかどうかを分析します。
リソース分析: マネージドコンポーネントのリソース使用量を表示します。
QPS とレイテンシー: 複数のディメンションから QPS と応答時間 (RT) を詳細に分析します。
APF スロットリング: APF メトリックを使用して、API Server のリクエストトラフィック分布とスロットリングステータスを分析し、システムのパフォーマンスボトルネックを特定できます。
アドミッションコントローラーと Webhook: アドミッションコントローラーと Webhook の QPS と RT を分析します。
クライアント分析: 複数のクライアントディメンションから QPS を分析します。
[フィルターペイン]
ダッシュボードの上部にあるフィルターペインで、Verb、Resource、Quantile、および Interval (PromQL サンプリング期間) パラメーターを設定して、API Server リクエストをフィルターできます。
Quantile を調整すると、値 0.9 は、ダッシュボードがヒストグラムメトリックの 90 パーセンタイルの値を表示することを示します。分位数 0.9 (P90) は、総サンプルのごく一部を占めるロングテールサンプルの影響を除去できます。分位数 0.99 (P99) は、ロングテールサンプルの影響を含みます。

次のフィルターペインで、時間範囲とページの更新間隔を選択できます。
[主要メトリック]
可観測性表示
機能分析
名前 | PromQL | 説明 |
API QPS | sum(irate(apiserver_request_total[$interval])) | API Server の合計 QPS。 |
読み取りリクエスト成功率 | sum(irate(apiserver_request_total{code=~"20.*",verb=~"GET|LIST"}[$interval]))/sum(irate(apiserver_request_total{verb=~"GET|LIST"}[$interval])) | API Server が読み取りリクエストを処理する際の成功率。 |
書き込みリクエスト成功率 | sum(irate(apiserver_request_total{code=~"20.*",verb!~"GET|LIST|WATCH|CONNECT"}[$interval]))/sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH|CONNECT"}[$interval])) | API Server が書き込みリクエストを処理する際の成功率。 |
処理中の読み取りリクエスト数 | sum(apiserver_current_inflight_requests{requestKind="readOnly"}) | API Server が現在処理している読み取りリクエストの数。 |
処理中の書き込みリクエスト数 | sum(apiserver_current_inflight_requests{requestKind="mutating"}) | API Server が現在処理している書き込みリクエストの数。 |
リクエストスロットリング率 | sum(irate(apiserver_dropped_requests_total[$interval])) | ドロップされたリクエスト率。 スロットリング中に API Server によって積極的にドロップされたリクエストの総リクエスト数に対する比率。 |
[概要]
可観測性表示
機能分析
名前 | PromQL | 説明 |
GET 読み取りリクエストレイテンシー | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log|proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le)) | GET リクエストの応答時間を表示します。ディメンションには、API Server Pod、Verb (GET)、Resources、および Scope が含まれます。 |
LIST 読み取りリクエストレイテンシー | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le)) | LIST リクエストの応答時間を表示します。ディメンションには、API Server Pod、Verb (LIST)、Resources、および Scope が含まれます。 |
書き込みリクエストレイテンシー | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET|WATCH|LIST|CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le)) | 変更リクエストの応答時間を表示します。ディメンションには、API Server Pod、Verb (GET、WATCH、LIST、CONNECT を除く)、Resources、および Scope が含まれます。 |
処理中の読み取りリクエスト数 | apiserver_current_inflight_requests{request_kind="readOnly"} | API Server が処理している読み取りリクエストの数。 |
処理中の書き込みリクエスト数 | apiserver_current_inflight_requests{request_kind="mutating"} | API Server が処理している書き込みリクエストの数。 |
リクエストスロットリング率 | sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name) sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name) | API Server のスロットリング率。 |
[リソース分析]
可観測性表示
機能分析
名前 | PromQL | 説明 |
メモリ使用量 | memory_utilization_byte{container="kube-apiserver"} | API Server のメモリ使用量。単位: バイト。 |
CPU 使用率 | cpu_utilization_core{container="kube-apiserver"}*1000 | API Server の CPU 使用率。単位: ミリコア。 |
リソースオブジェクト数 |
|
説明 互換性の問題により、apiserver_storage_objects と etcd_object_counts の両方がバージョン 1.22 に存在します。 |
[QPS とレイテンシー]
可観測性表示
機能分析
名前 | PromQL | 説明 |
Verb 別の QPS 分析 | sum(irate(apiserver_request_total{verb=~"$verb"}[$interval]))by(verb) | Verb 別にリクエストのクエリ/秒 (QPS) を分析します。 |
Verb とリソース別の QPS 分析 | sum(irate(apiserver_request_total{verb=~"$verb",resource=~"$resource"}[$interval]))by(verb,resource) | Verb と Resource 別にリクエストの QPS を分析します。 |
Verb 別のリクエストレイテンシー分析 | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT",resource!=""}[$interval])) by (le,verb)) | Verb 別にリクエストレイテンシーを分析します。 |
Verb とリソース別のリクエストレイテンシー分析 | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT", resource=~"$resource",resource!=""}[$interval])) by (le,verb,resource)) | Verb と Resource 別にリクエストレイテンシーを分析します。 |
2xx 以外の戻り値を持つ読み取りリクエストの QPS | sum(irate(apiserver_request_total{verb=~"GET|LIST",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code) | 2xx 以外の戻り値を持つ読み取りリクエストの QPS をカウントします。2xx 以外の戻り値は、4xx や 5xx などの失敗を示します。 |
2xx 以外の戻り値を持つ書き込みリクエストの QPS | sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH",verb=~"$verb",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code) | 2xx 以外の戻り値を持つ書き込みリクエストの QPS をカウントします。2xx 以外の戻り値は、4xx や 5xx などの失敗を示します。 |
API Server から Etcd へのリクエストレイテンシー | histogram_quantile($quantile, sum(irate(etcd_request_duration_seconds_bucket[$interval])) by (le,operation,type,instance)) | API Server から etcd へのリクエストレイテンシーをカウントします。 |
APF スロットリング
APF スロットリングメトリックのモニタリングは段階的リリースです。
APF 関連のメトリックは、Kubernetes v1.20 以降を実行するクラスターでのみサポートされます。クラスターをアップグレードするには、「ACK クラスターを手動でアップグレードする」をご参照ください。
APF メトリックダッシュボードでは、次のコンポーネントもアップグレードする必要があります。詳細については、「コンポーネントモニタリングのアップグレード手順」をご参照ください。
コンテナークラスターモニタリングコンポーネント: 0.06 以降。
ack-arms-prometheus コンポーネント: v1.1.31 以降。
マネージドプローブ: v1.1.31 以降。
可観測性表示


機能分析
次の表の一部のメトリックは、PL、Instance、および FS ディメンションによって収集されます。
PL: 優先度レベルディメンション。メトリックは、さまざまな優先度に基づいて収集されます。
Instance: API Server インスタンスディメンション。メトリックは、API Server インスタンスに基づいて収集されます。
FS: フロー スキーマディメンション。メトリックは、リクエストの分類に基づいて収集されます。
APF と前述のディメンションの詳細については、APF ドキュメントをご参照ください。
名前 | PromQL | 説明 |
APF リクエスト同時実行数制限 (PL 別) | sum by(priority_level) (apiserver_flowcontrol_request_concurrency_limit) | PL 別または Instance と PL 別に APF リクエストの同時実行数制限をカウントします。これは、優先度付きキューが理論的に同時に処理できるリクエストの最大数です。 apiserver_flowcontrol_request_concurrency_limit メトリックは Kubernetes v1.30 で非推奨となり、v1.31 で削除されます。Kubernetes v1.31 以降を実行するクラスターでは、代わりに apiserver_flowcontrol_nominal_limit_seats メトリックを使用してください。 |
APF リクエスト同時実行数制限 (Instance および PL 別) | sum by(instance,priority_level) (apiserver_flowcontrol_request_concurrency_limit) | |
現在の APF 実行中リクエスト数 (FS および PL 別) | sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_executing_requests) | FS と PL 別、または Instance、FS、PL 別に現在実行中の APF リクエストの数をカウントします。 |
現在の APF 実行中リクエスト数 (Instance、FS、および PL 別) | sum by(instance,flow_schema,priority_level)(apiserver_flowcontrol_current_executing_requests) | |
キューで待機中の APF リクエスト数 (FS および PL 別) | sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests) | FS と PL 別、または Instance、FS、PL 別に現在のキューで処理を待っているリクエストの数をカウントします。 |
キューで待機中の APF リクエスト数 (Instance、FS、および PL 別) | sum by(instance,flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests) | |
APF 公称同時実行数制限シート数 | sum by(instance,priority_level) (apiserver_flowcontrol_nominal_limit_seats) | Instance と PL 別に APF シート関連のメトリックをカウントします。メトリックには以下が含まれます。
|
APF 現在の同時実行数制限シート数 | sum by(instance,priority_level) (apiserver_flowcontrol_current_limit_seats) | |
現在実行中の APF シート数 | sum by(instance,priority_level) (apiserver_flowcontrol_current_executing_seats) | |
現在キューにある APF シート数 | sum by(instance,priority_level) (apiserver_flowcontrol_current_inqueue_seats) | |
APF リクエスト実行時間 | histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_execution_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level)) | リクエストが実行開始から完了するまでにかかる時間。 |
APF リクエスト待機時間 | histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_wait_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level)) | リクエストがキューに入ってから実行が開始されるまでの待機時間。 |
正常にディスパッチおよび処理された APF リクエストの QPS | sum(irate(apiserver_flowcontrol_dispatched_requests_total[$interval]))by(instance,flow_schema,priority_level) | 正常にスケジュールされ、処理されたリクエストの QPS。 |
拒否された APF リクエストの QPS | sum(irate(apiserver_flowcontrol_rejected_requests_total[$interval]))by(instance,flow_schema,priority_level) | 同時実行数制限またはキュー容量を超えたために拒否されたリクエストの QPS。 |
[アドミッションコントローラーと Webhook]
可観測性表示
機能分析
名前 | PromQL | 説明 |
アドミッションコントローラーレイテンシー [admit] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="admit"}[$interval])) ) | 使用される admit タイプのアドミッションコントローラーの名前、操作、拒否ステータス、および実行時間。 メトリックのバケットのしきい値は |
アドミッションコントローラーレイテンシー [validate] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="validate"}[$interval])) ) | 使用される validate タイプのアドミッションコントローラーの名前、操作、拒否ステータス、および実行時間。 メトリックのバケットのしきい値は |
アドミッション Webhook レイテンシー [admit] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="admit"}[$interval])) ) | 使用される admit タイプの Webhook の名前、操作、拒否ステータス、および実行時間。 メトリックのバケットのしきい値は |
アドミッション Webhook レイテンシー [validating] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="validating"}[$interval])) ) | 使用される validating タイプの Webhook の名前、操作、拒否ステータス、および実行時間。 メトリックのバケットのしきい値は |
アドミッション Webhook リクエスト QPS | sum(irate(apiserver_admission_webhook_admission_duration_seconds_count[$interval]))by(name,operation,type,rejected) | アドミッション Webhook のリクエスト QPS。 |
[クライアント分析]
可観測性表示
機能分析
名前 | PromQL | 説明 |
クライアント別の QPS 分析 | sum(irate(apiserver_request_total{client!=""}[$interval])) by (client) | クライアント別に QPS を分析します。これは、API Server にアクセスするクライアントとその QPS を分析するために使用されます。 |
Verb、リソース、クライアント別の QPS 分析 | sum(irate(apiserver_request_total{client!="",verb=~"$verb", resource=~"$resource"}[$interval]))by(verb,resource,client) | Verb、Resource、Client 別に QPS を分析します。 |
Verb、リソース、クライアント別の LIST リクエスト QPS 分析 (ResourceVersion フィールドなし) | sum(irate(apiserver_request_no_resourceversion_list_total[$interval]))by(resource,client) |
|
一般的なメトリックの異常
コンポーネントの一般的なメトリックが異常な場合は、次の説明を参照して、その動作が予期されたものかどうかを判断してください。
[読み取り/書き込みリクエスト成功率]
説明
法線 | 異常 | 説明 |
[読み取りリクエスト成功率] と [書き込みリクエスト成功率] は 100% に近いです。 | [読み取りリクエスト成功率] と [書き込みリクエスト成功率] は、たとえば 90% 未満など、低いパーセンテージのままです。 | 200 以外の戻り値を持つリクエストが多数あります。 |
推奨される解決策
ダッシュボードを使用して、[2xx 以外の戻り値を持つ読み取りリクエストの QPS] および [2xx 以外の戻り値を持つ書き込みリクエストの QPS] チャートで 2xx 以外の戻り値の原因となるリクエストタイプとリソースを特定します。これらのリクエストが予期されたものであるかどうかを評価し、それらを最適化するための措置を講じます。たとえば、[GET/deployment 404] が表示された場合、404 を返すデプロイメントを取得するリクエストがあることを示します。これにより、[読み取りリクエスト成功率] が低下します。これが予期された動作であるかどうかを判断する必要があります。
[GET/LIST 読み取りリクエストレイテンシーと書き込みリクエストレイテンシー]
説明
法線 | 異常 | 説明 |
[GET 読み取りリクエストレイテンシー]、[LIST 読み取りリクエストレイテンシー]、および [書き込みリクエストレイテンシー] は、アクセスされるクラスターリソースの数とクラスターの規模に関連しています。正常な時間と異常な時間の間に固定の境界はありません。ビジネスに影響がない限り、レイテンシーは許容範囲内です。たとえば、特定のタイプのリソースにアクセスするほど、LIST リクエストにかかる時間は長くなります。一般的に、[GET 読み取りリクエストレイテンシー] と [書き込みリクエストレイテンシー] が 1 秒未満、[LIST 読み取りリクエストレイテンシー] が 5 秒未満であれば正常です。 |
| リクエストの応答時間が長すぎる場合は、多くのクラスターリソースや遅い Webhook 呼び出しなどの要因を除外する必要があります。 |
推奨される解決策
ダッシュボードを使用して、[GET 読み取りリクエストレイテンシー]、[LIST 読み取りリクエストレイテンシー]、および [書き込みリクエストレイテンシー] チャートで高レイテンシーの原因となっているリクエストタイプとリソースを特定し、問題を解決するための措置を講じます。
apiserver_request_duration_seconds_bucketリクエストレイテンシーメトリックの最大しきい値は 60 秒です。60 秒以上かかるリクエストは 60 秒としてカウントされます。ただし、Pod へのログインリクエスト (POST pod/exec) やログ読み取りリクエストは長期間の接続を確立します。これらのリクエストは通常 60 秒以上かかります。トラブルシューティング中にこれらのタイプのリクエストは無視できます。
アドミッション Webhook レイテンシー を参照して、遅い Webhook 実行が API Server リクエストのレイテンシーを長くしているかどうかを分析します。
[処理中の読み取り/書き込みリクエストとリクエストスロットリング率]
説明
法線 | 異常 | 説明 |
一般的に、[処理中の読み取りリクエスト数] と [処理中の書き込みリクエスト数] が 100 未満で、[リクエストスロットリング率] が 0 であれば正常です。 |
| リクエストを処理するキューにバックログがある場合、リクエストの急増や遅い Webhook 呼び出しによる処理遅延などの要因を除外する必要があります。キューの長さを超えると、API Server はリクエストをスロットリングします。これにより、[リクエストスロットリング率] が 0 より大きくなり、クラスターの安定性に影響します。 |
推奨される解決策
QPS とレイテンシー および クライアント分析 セクションを参照して、上位のリクエストを分析し、それらが予期されたものであるかどうかを評価します。リクエストがアプリケーションによって開始された場合は、リクエスト数を減らす必要があるかどうかを判断します。
アドミッション Webhook レイテンシー を参照して、遅い Webhook 実行が API Server リクエスト処理を遅くしているかどうかを分析します。
[アドミッション Webhook レイテンシー]
説明
法線 | 異常 | 説明 |
[アドミッション Webhook レイテンシー] は 0.5 秒未満です。 | [アドミッション Webhook レイテンシー] は持続的に 0.5 秒を超えています。 | 遅い Webhook 応答は、API Server の応答時間に影響します。 |
推奨される解決策
Webhook のログやその他の情報を確認して、その動作が予期されたものかどうかを判断します。Webhook が不要な場合は、アンインストールしてください。
参考資料
クラスターの他のコントロールプレーンコンポーネントのメトリック、ダッシュボードの使用方法、および一般的なメトリックの異常に関する詳細については、次のトピックをご参照ください。
コンソールまたは API を使用して Prometheus モニタリングデータをクエリする方法の詳細については、「PromQL を使用して Prometheus モニタリングデータをクエリする」をご参照ください。
Alibaba Cloud Prometheus Monitoring を使用してカスタム PromQL クエリに基づいてアラートルールを設定する方法の詳細については、「Prometheus アラートルールを作成する」をご参照ください。