Change:
Keep the doc consistent with
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
### Metrics <ins> {{< note >}} In versions of Kubernetes before v1.20, the labels `flow_schema` and `priority_level` were inconsistently named `flowSchema` and `priorityLevel`, respectively. If you're running Kubernetes versions v1.19 and earlier, you should refer to the documentation for your version. {{< /note >}} </ins> When you enable the API Priority and Fairness feature, the kube-apiserver exports additional metrics. Monitoring these can help you determine whether your configuration is inappropriately throttling important traffic, or find

* `apiserver_flowcontrol_rejected_requests_total` is a counter vector (cumulative since server start) of requests that were rejected, <del> broken down by the labels `flowSchema` (indicating the one that matched the request), `priorityLevel` (indicating the one to which </del> <ins> broken down by the labels `flow_schema` (indicating the one that matched the request), `priority_level` (indicating the one to which </ins> the request was assigned), and `reason`.  The `reason` label will be have one of the following values: * `queue-full`, indicating that too many requests were already

* `apiserver_flowcontrol_dispatched_requests_total` is a counter vector (cumulative since server start) of requests that began <del> executing, broken down by the labels `flowSchema` (indicating the one that matched the request) and `priorityLevel` (indicating the </del> <ins> executing, broken down by the labels `flow_schema` (indicating the one that matched the request) and `priority_level` (indicating the </ins> one to which the request was assigned). * `apiserver_current_inqueue_requests` is a gauge vector of recent

* `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector holding the instantaneous number of queued (not executing) requests, <del> broken down by the labels `priorityLevel` and `flowSchema`. </del> <ins> broken down by the labels `priority_level` and `flow_schema`. </ins> * `apiserver_flowcontrol_current_executing_requests` is a gauge vector holding the instantaneous number of executing (not waiting in a <del> queue) requests, broken down by the labels `priorityLevel` and `flowSchema`. </del> <ins> queue) requests, broken down by the labels `priority_level` and `flow_schema`. </ins> * `apiserver_flowcontrol_priority_level_request_count_samples` is a histogram vector of observations of the then-current number of requests broken down by the labels `phase` (which takes on the <del> values `waiting` and `executing`) and `priorityLevel`.  Each </del> <ins> values `waiting` and `executing`) and `priority_level`.  Each </ins> histogram gets observations taken periodically, up through the last activity of the relevant sort.  The observations are made at a high rate.

* `apiserver_flowcontrol_priority_level_request_count_watermarks` is a histogram vector of high or low water marks of the number of requests broken down by the labels `phase` (which takes on the <del> values `waiting` and `executing`) and `priorityLevel`; the label </del> <ins> values `waiting` and `executing`) and `priority_level`; the label </ins> `mark` takes on values `high` and `low`.  The water marks are accumulated over windows bounded by the times when an observation was added to

* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by <del> the labels `priorityLevel` and `flowSchema`, as sampled by the </del> <ins> the labels `priority_level` and `flow_schema`, as sampled by the </ins> enqueued requests.  Each request that gets queued contributes one sample to its histogram, reporting the length of the queue just after the request was added.  Note that this produces different

* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector hoding the computed concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations' concurrency <del> shares), broken down by the label `priorityLevel`. </del> <ins> shares), broken down by the label `priority_level`. </ins> * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram vector of how long requests spent queued, broken down by the labels <del> `flowSchema` (indicating which one matched the request), `priorityLevel` (indicating the one to which the request was </del> <ins> `flow_schema` (indicating which one matched the request), `priority_level` (indicating the one to which the request was </ins> assigned), and `execute` (indicating whether the request started executing). {{< note >}}

* `apiserver_flowcontrol_request_execution_seconds` is a histogram vector of how long requests took to actually execute, broken down by <del> the labels `flowSchema` (indicating which one matched the request) and `priorityLevel` (indicating the one to which the request was </del> <ins> the labels `flow_schema` (indicating which one matched the request) and `priority_level` (indicating the one to which the request was </ins> assigned). ### Debug endpoints