服務指標

每個 Knative 服務都有一個代理容器，用於代理與應用程式容器的連線。 針對佇列代理效能報告了許多指標。

使用下列指標，您可以測量要求是否在代理端排隊（需要背壓），以及在應用程式端提供要求的實際延遲。

佇列代理指標

要求端點。

指標名稱	說明	類型	標籤	單位	狀態
revision_request_count	路由至 queue-proxy 的要求數量	計數器	configuration_name container_name namespace_name pod_name response_code response_code_class revision_name service_name	無單位	穩定
revision_request_latencies	以毫秒為單位的回應時間	長條圖	configuration_name container_name namespace_name pod_name response_code response_code_class revision_name service_name	毫秒	穩定
revision_app_request_count	路由至 user-container 的要求數量	計數器	configuration_name container_name namespace_name pod_name response_code response_code_class revision_name service_name	無單位	穩定
revision_app_request_latencies	以毫秒為單位的回應時間	長條圖	configuration_name namespace_name pod_name response_code response_code_class revision_name service_name	毫秒	穩定
revision_queue_depth	服務與等候佇列中的目前項目數，如果並行處理無限制，則不回報	量規	configuration_name event-display container_name namespace_name pod_name response_code_class revision_name service_name	無單位	穩定

注意

只有在修訂版並行處理硬性限制設定為大於 1 的值時，才會匯出 revision_queue_depth 指標。

公開佇列代理指標

佇列代理會針對 9091 連接埠上的要求端點匯出指標。 當 configmap observability 中的 metrics.request-metrics-backend-destination 設定為 prometheus（預設值）時，Prometheus 可以抓取這些指標。 後端可以變更為 opencensus，這會使用推播模型，並且需要可以在相同 configmap 中透過 metrics.opencensus-address 設定的目的地位置。 使用者可以使用 metrics.request-metrics-reporting-period-seconds 控制兩個後端的報告週期。 如果完全未設定 metrics.request-metrics-reporting-period-seconds，則報告週期取決於影響控制和資料平面的全域報告週期值 metrics.reporting-period-seconds。 如果這兩個屬性都不可用，則 Prometheus 後端的報告週期預設為 5 秒，而 Opencensus 後端的報告週期預設為 60 秒。

以下是 observability configmap 的範例組態，以便連線至 OpenTelemetry 收集器

metrics.request-metrics-backend-destination: "opencensus"
metrics.opencensus-address: "otel-collector.metrics:55678"
metrics.request-metrics-reporting-period-seconds: "1"

注意

報告週期為 1 秒，以便我們盡快推播指標，但這對於目標指標後端而言可能會難以負荷。 將值設定為零或負值會預設為 10 秒（並不表示沒有延遲），這是 Opencensus 指標用戶端程式庫定義的預設報告週期。 後者由 Knative Serving 用於匯出指標。