knative / knative/serving

Are the Autoscaler Concurrency Metrics per pod?

Open
#13,652 3 comments 0 reactions 0 assignees View on GitHub
kind/question triage/accepted
Dominant language
Go
Stars
6.1k
Forks
1.2k
Avg merge
2d 7h
Merged PRs (30d)
2

Description

## Ask your question here:
Hello, going over the [Metics documentation](https://knative.dev/docs/serving/observability/metrics/serving-metrics/#autoscaler), I have a question on the `stable_request_concurrency` and `panic_request_concurrency` metrics. The definition says "Average of requests count per observed pod ...". However, it appears that these metrics represent the total request concurrency for the revision and are not exactly the value per pod.

I tried to explore the code and this is what I found:
* [Summing the metric](https://github.com/knative/serving/blob/knative-v1.3.2/pkg/autoscaler/metrics/stats_scraper.go#L353)
* [Average](https://github.com/knative/serving/blob/knative-v1.3.2/pkg/autoscaler/metrics/collector.go#L411) - so the average is extrapolated from the sample number of pods to the total number of pods

* So, if `target_concurrency_per_pod` is `1`, there were 2 pods, and the `stable_request_concurrency` is `1.5`, we are still below the target. Is this understanding correct?
* If the above is correct, can the documentation be updated from "Average of requests count per observed pod ..." to "Estimated requests count over all observed pods ..." (or something along those lines), to avoid confusion?

Thanks!

Contributor guide

Open the contributing guide

Research direction

Start with the autoscaler metrics documentation and inspect the linked code in pkg/autoscaler/metrics/stats_scraper.go and pkg/autoscaler/metrics/collector.go. Confirm whether stable_request_concurrency and panic_request_concurrency are estimated across observed pods, then update the metric definition to remove the ambiguity and clarify the target_concurrency_per_pod example.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
documentation, observability
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.