全部產品
Search
文件中心

Container Service for Kubernetes:kube-apiserver組件監控指標及大盤使用說明

更新時間:Aug 28, 2025

kube-apiserver組件提供了Kubernetes的RESTful API介面,使得外部客戶端、叢集內的其他組件可以與ACK叢集互動。本文介紹kube-apiserver組件的監控指標清單、大盤使用指導以及常見指標異常解析。

使用前須知

操作入口

請參見查看叢集控制面組件監控大盤

指標清單

指標是組件對外透出狀態和參數的方式之一。kube-apiserver組件使用的指標清單如下。

指標清單

類型

解釋

apiserver_request_duration_seconds_bucket

Histogram

該指標用於統計API Server用戶端對API Server不同請求的訪問時延分布。

請求的維度包括:

  • Verb:請求的類型,例如GET、POST、PUT、DELETE等。

  • Group:API組,即相關API介面的集合,用於擴充Kubernetes API。

  • Version:API版本,例如v1、v1beta1等。

  • Resource:請求針對的資源類型,例如Pod、Service、Lease等。

  • Subresource:資源的子資源,例如Pod詳細資料、Pod日誌等。

  • Scope:請求的範圍,例如命名空間維度資源(Namespace-scoped)或叢集維度資源(Cluster-scoped)。

  • Component:發起請求的組件的名稱,例如kube-controller-managerkube-schedulercloud-controller-manager等。

  • Client:發起請求的用戶端,可能是內部組件或外部服務。

API ServerHistogram的Bucket閾值為{0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.25, 1.5, 1.75, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5, 6, 7, 8, 9, 10, 15, 20, 25, 30, 40, 50, 60}。單位:秒。

apiserver_request_total

Counter

API Server不同請求的計數。請求的維度包括Verb、Group、Version、Resource、Scope、Component、HTTP contentType、HTTP code(響應的HTTP狀態代碼)和Client。

apiserver_request_no_resourceversion_list_total

Counter

API Server的請求中參數未配置resourceVersion的LIST請求的計數。評估Quorum Read類型的LIST請求可以定位是否存在過多的此類請求以及發起相應請求的用戶端,以便最佳化用戶端的請求行為,提高叢集效能。請求的維度包括Group、Version、Resource、Scope和Client。

apiserver_current_inflight_requests

Gauge

API Server當前處理的請求數量。請求包括兩種:

  • ReadOnly:這類請求不會改變叢集的狀態,通常為讀取資源的操作,例如擷取Pods列表、查詢節點狀態等。

  • Mutating:這類請求會改變叢集的狀態,通常為建立、更新或刪除資源的操作,例如建立Pod、更新Service配置等。

apiserver_dropped_requests_total

Counter

API Server執行限流策略過程中,主動丟棄掉的請求數。HTTP傳回值為429 'Try again later'

etcd_request_duration_seconds_bucket

Histogram

該指標用於統計API Server對etcd請求的訪問時延分布。

請求的維度包括操作(Operation)和操作對象的類型(Type)。

Bucket閾值為{0.005, 0.025, 0.05, 0.1, 0.2, 0.4, 0.6, 0.8, 1.0, 1.25, 1.5, 2, 3, 4, 5, 6, 8, 10, 15, 20, 30, 45, 60}。單位:秒。

apiserver_flowcontrol_request_concurrency_limit

Gauge

APF請求並發限制。表示某個優先順序隊列的最大並發限制,即該隊列理論上允許同時處理的最大請求數,供您瞭解API Server如何通過流量控制策略將資源分派給不同優先順序的隊列,從而確保高優先順序請求可以及時處理。

該指標在Kubernetes 1.30版本變為Deprecated,自1.31版本起移除,1.31及以上版本的叢集中建議使用apiserver_flowcontrol_nominal_limit_seats指標代替。

apiserver_flowcontrol_current_executing_requests

Gauge

某個優先順序隊列中當前正在執行的請求數量,即該隊列的實際並發負載,供您瞭解API Server的實際負載情況,判斷是否接近系統最大並發限制,防止過載。

apiserver_flowcontrol_current_inqueue_requests

Gauge

某個優先順序隊列中當前在隊列中等待處理的請求數量,即該隊列的請求積壓情況,以瞭解API Server的流量壓力以及隊列是否過載。

apiserver_flowcontrol_nominal_limit_seats

Gauge

APF 名義並發限制席位元量,即API Server理論上(nominal)的最大並發處理能力,以Seat為單位。供您瞭解API Server如何通過流量控制策略將資源分派給不同優先順序的隊列。

apiserver_flowcontrol_current_limit_seats

Gauge

APF 當前並發限制席位元量。表示某個優先順序隊列的當前並發限制(Current Concurrency Limit),即在動態調整後實際允許的最大並發席位元量,反映當前隊列的實際並發能力(可能因系統負載或其他因素而動態變化)。

與 nominal_limit_seats 不同,此值可能會受全域流量控制策略影響。

apiserver_flowcontrol_current_executing_seats

Gauge

APF 當前在執行的席位元量,表示某個優先順序隊列中當前正在執行的請求數對應的席位元量,反映了當前隊列中正在消耗的並發資源。供您瞭解隊列的實際負載情況。

如果 current_executing_seats 接近 current_limit_seats,表明該隊列的並發資源可能即將耗盡。

您可以提升API Server的maxMutatingRequestsInflight和maxRequestsInflight的參數取值以最佳化配置。操作入口及參數取值,請參見自訂Pro版叢集的控制面組件參數

apiserver_flowcontrol_current_inqueue_seats

Gauge

APF當前隊列中席位元量,表示某個優先順序隊列中當前等待處理的請求數對應的席位元量,反映了當前隊列中等待處理的請求所佔用的資源,以供您瞭解隊列的積壓情況。

apiserver_flowcontrol_request_execution_seconds_bucket

Histogram

請求的實際執行時間,記錄了請求從開始執行到最終完成所花費的時間。

時間區間分布為{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

Histogram

請求在隊列中等待的時間分布,記錄了請求從進入隊列到開始執行之間的等待時間

時間區間分布為{0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30}。單位:秒。

apiserver_flowcontrol_dispatched_requests_total

Counter

成功調度並處理的請求數量,反映了API Server成功處理的請求總數。

apiserver_flowcontrol_rejected_requests_total

Counter

因超出並發限制或隊列容量而被拒絕的請求數量。

apiserver_admission_controller_admission_duration_seconds_bucket

Histogram

准入控制器(Admission Controller)的處理延時。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate或admit)和請求是否被拒絕(true或false)。

Bucket閾值為{0.005, 0.025, 0.1, 0.5, 2.5}。單位:秒。

apiserver_admission_webhook_admission_duration_seconds_bucket

Histogram

准入Webhook(Admission Webhook)的處理延時。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate,校正請求的合法性,或admit,在請求合法的情況下,決定是否允許該請求)和請求是否被拒絕(true或false)。

Bucket的閾值為{0.005, 0.025, 0.1, 0.5, 2.5}。單位:秒。

apiserver_admission_webhook_admission_duration_seconds_count

Counter

准入Webhook(Admission Webhook)的處理請求統計。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate或admit)和請求是否被拒絕(true或false)。

cpu_utilization_core

Gauge

CPU使用量。單位:核(Core)。

memory_utilization_byte

Gauge

記憶體使用量量。單位:位元組(Byte)。

up

Gauge

服務可用性。

  • 1:表示服務可用。

  • 0:表示服務不可用。

說明

如下資源使用率指標已廢棄,請及時去除依賴該指標的警示和監控。

  • cpu_utilization_ratio:CPU使用率。

  • memory_utilization_ratio:記憶體使用量率。

大盤使用指導

大盤基於組件指標和相關PromQL繪製,包括關鍵計量、概覽、資源分析、QPS和時延、准入控制器和Webhook、用戶端分析部分。

大盤構成模組如下,常見的使用順序為:

  1. 關鍵計量:快速查看叢集關鍵計量。

  2. 概覽:分析API Server的響應時延、當前處理請求數和是否有限流發生。

  3. 資源分析:查看託管側組件的資源水位。

  4. QPS和時延:通過多維度深入分析QPS、RT。

  5. APF限流:根據APF指標確認API Server的請求流量分布、限流狀態以及系統效能瓶頸。

  6. 注入控制器和Webhook:分析准入控制器和Webhook的QPS、RT。

  7. 用戶端分析:通過用戶端多維度分析QPS。

篩選框

在大盤上方,您可以根據篩選框配置觀測API Server請求的Verb、資源(Resource)、分位元(Quantile)和面板使用的PromQL的採樣時間長度(Interval)。

說明

調整分位元(Quantile)時,以0.9為例,表示大盤上Histogram類型指標的採樣值的數量占該類型指標總體採樣值的90%。分位元為0.9(簡稱為P90)的指標可以去除採樣值佔比小的長尾樣本的影響,分位元為0.99(簡稱為P99)的指標會包含長尾樣本的影響。

篩選框

以下篩選框可以選擇觀測的時間段和頁面重新整理周期。篩選框2

關鍵計量

可觀測性展示100

功能解析

名稱

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]))

Dropped Request Rate。

API Server限流策略過程中,主動丟棄掉的請求數所佔總請求數的比例。

概覽

可觀測性展示50

功能解析

名稱

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))

展示Mutating請求的回應時間,維度包括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的限流速率 ,No data或者0表示沒有限流。

資源分析

可觀測性展示資來源物件

功能解析

名稱

PromQL

說明

記憶體使用量量

memory_utilization_byte{container="kube-apiserver"}

API Server的記憶體使用量量。單位:位元組。

CPU使用量

cpu_utilization_core{container="kube-apiserver"}*1000

API Server的CPU使用量。單位:毫核。

資來源物件數量

  • max by(resource)(apiserver_storage_objects)

  • max by(resource)(etcd_object_counts)

  • 當ACK為1.22及以上版本時, 指標名字為apiserver_storage_objects

  • 當ACK為1.22及以下版本時,指標名字為etcd_object_counts。

說明

由於相容性問題,1.22版本中apiserver_storage_objects名稱和etcd_object_counts名稱均存在。

QPS和時延

可觀測性展示48

功能解析

名稱

PromQL

說明

按Verb維度分析QPS

sum(irate(apiserver_request_total{verb=~"$verb"}[$interval]))by(verb)

按Verb維度,統計單位時間(1s)內的請求QPS。

按Verb+Resource維度分析QPS

sum(irate(apiserver_request_total{verb=~"$verb",resource=~"$resource"}[$interval]))by(verb,resource)

按Verb+Resource維度,統計單位時間(1s)內的請求QPS。

按Verb維度分析請求時延

histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT",resource!=""}[$interval])) by (le,verb))

按Verb維度,分析請求時延。

按Verb+Resource維度分析請求時延

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傳回值(除成功以外的所有情況,例如4xx、5xx等)的讀請求QPS。

非2xx傳回值的寫請求QPS

sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH",verb=~"$verb",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code)

統計非2xx傳回值(除成功以外的所有情況,例如4xx、5xx等)的寫請求QPS。

Apiserver對etcd請求時延

histogram_quantile($quantile, sum(irate(etcd_request_duration_seconds_bucket[$interval])) by (le,operation,type,instance))

統計API Server對etcd的請求時延。

APF限流

說明

APF限流相關指標監控處於灰階發布中。

  • APF相關指標僅支援1.20及以上版本叢集。如需升級,請參見手動升級叢集

  • APF相關指標大盤還依賴如下組件的升級,請參見組件監控升級說明完成升級:

    • 容器叢集監控組件:0.06及以上版本。

    • ack-arms-prometheus組件:v1.1.31及以上版本。

    • 託管探針:v1.1.31及以上版本。

可觀測性展示

image

image

功能解析

下表中部分指標按PL、Instance、FS維度進行統計。

  • PL:Priority Level維度,即根據不同優先順序進行統計。

  • Instance:根據API Server執行個體維度進行統計。

  • FS:Flow Schema維度,即根據請求分類進行統計。

關於APF及上述維度詳細資料,請參見APF

名稱

PromQL

說明

APF 請求並發限制(維度:PL)

sum by(priority_level) (apiserver_flowcontrol_request_concurrency_limit)

按 PL 或 Instance + PL 維度統計 APF 請求並發限制,即某個優先順序隊列理論上允許同時處理的最大請求數。

apiserver_flowcontrol_request_concurrency_limit 在Kubernetes 1.30版本變為Deprecated,自1.31版本起移除1.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

可觀測性展示47

功能解析

名稱

PromQL

說明

准入控制器時延[admit]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="admit"}[$interval])) )

使用到的admit類型的Admission Controller名稱、操作、是否拒絕以及相應的執行時間。

指標Bucket的閾值為{0.005、0.025、0.1、0.5、2.5}。單位:秒。

准入控制器時延[validate]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="validate"}[$interval])) )

使用到的validate類型的Admission Controller名稱、操作、是否拒絕以及相應的執行時間。

指標Bucket的閾值為{0.005、0.025、0.1、0.5、2.5}。單位:秒。

准入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名稱、操作、是否拒絕以及相應的執行時間。

指標Bucket的閾值為{0.005、0.025、0.1、0.5、2.5},單位:秒。

准入Webhook時延[validating]

histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="validating"}[$interval])) )

使用到的admit類型的Webhook名稱、操作、是否拒絕以及相應的執行時間。

指標Bucket的閾值為{0.005、0.025、0.1、0.5、2.5}。單位:秒。

准入Webhook請求QPS

sum(irate(apiserver_admission_webhook_admission_duration_seconds_count[$interval]))by(name,operation,type,rejected)

准入Webhook的請求QPS。

用戶端分析

可觀測性展示45

功能解析

名稱

PromQL

說明

按Client維度分析QPS

sum(irate(apiserver_request_total{client!=""}[$interval])) by (client)

按Client維度分析QPS。用於分析訪問API Server的用戶端以及QPS。

按Verb+Resource+Client維度分析QPS

sum(irate(apiserver_request_total{client!="",verb=~"$verb", resource=~"$resource"}[$interval]))by(verb,resource,client)

按Verb+Resource+Client維度分析QPS。

按Verb+Resource+Client維度分析LIST請求QPS(無resourceVersion欄位)

sum(irate(apiserver_request_no_resourceversion_list_total[$interval]))by(resource,client)

  • 按Verb+Resource+Client維度分析LIST請求的QPS(無resourceVersion欄位)。

  • 可以分析對API Server的全部LIST請求中、到etcd的部分LIST請求,協助識別以及最佳化API Server用戶端的LIST行為。

常見指標異常

如果組件的常見指標異常,請對照下文的情況說明排查是否為預期內情況。

讀/寫請求成功率

情況說明

正常情況

異常情況

說明

讀請求成功率寫請求成功率接近100%。

讀請求成功率寫請求成功率維持在較低百分比,例如小於90%。

存在較多非200傳回值請求。

推薦解決方案

查看面板,定位非2xx傳回值的讀請求QPS非2xx傳回值的寫請求 QPS中導致非200傳回值請求類型和資源。請評估該類請求是否符合預期,並隨之採取措施進行最佳化。例如,如果有GET/deployment 404,表示存在GET Deployment返回404的請求,會導致讀請求成功率降低,請判斷是否為預期行為。

GET/LIST讀請求時延和寫請求時延

情況說明

正常情況

異常情況

說明

GET讀請求時延LIST讀請求時延寫請求時延與訪問的叢集資源數量和叢集規模相關聯,沒有固定的正常與異常的時間分界,只要不影響業務即在接受範圍內。例如,如果訪問的某種資源量越大,那麼LIST請求時間就會越長。一般情況下,GET讀請求時延寫請求時延小於1s,LIST讀請求時延小於5s,為正常現象。

  • GET讀請求時延寫請求時延大於1s。

  • LIST讀請求時延大於5s。

請求的響應時延過長時,需要排除叢集資源數量多、Webhook調用慢等因素的影響。

推薦解決方案

  • 查看面板,定位GET讀請求時延LIST讀請求時延寫請求時延中導致非200傳回值的請求類型和資源,並採取解決措施。

    請求延時指標apiserver_request_duration_seconds_bucket的最大閾值是60s,超過60s的請求都會統計為60s。而登入Pod的請求POST pod/exec、讀取日誌的請求會建立長連結,該類請求時間通常會超過60s。問題定位時,您可忽略該類請求。

  • 參見准入Webhook時延,分析是否由於Webhook執行較慢,導致API Server請求延時間長度。

在處理讀/寫請求數量和請求限流速率

情況說明

正常情況

異常情況

說明

通常情況下,在處理讀請求數量在處理寫請求數量小於100,請求限流速率為0,為正常現象。

  • 在處理讀請求數量在處理寫請求數量大於100。

  • 請求限流速率大於0。

當前在處理請求的隊列積壓時,需要排除短時請求量湧入導致處理延時、Webhook調用慢等因素的影響。超過隊列長度時,API Server會限流,導致請求限流速率大於0,影響叢集穩定性。

推薦解決方案

  • 查看QPS和時延用戶端分析,分析請求中佔比位於頭部的請求,評估是否符合預期。如果請求為實際業務發起,您可以判斷是否需降低請求量。

  • 參見准入Webhook時延,分析是否因為Webhook執行慢導致API Server請求處理慢。

准入Webhook時延

情況說明

正常情況

異常情況

說明

准入Webhook時延小於0.5s。

持續出現准入Webhook時延大於0.5s。

Webhook響應慢會影響API Server的響應時延。

推薦解決方案

排查Webhook日誌等資訊,判斷是否符合預期。如果不需要某個Webhook,請卸載。

相關文檔