-
Notifications
You must be signed in to change notification settings - Fork 284
feat(app/inbound): http and grpc status code metrics #4313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@cratelyn
cratelyn
force-pushed
the
kate/app-inbound.add-status-code-metrics
branch
from
December 1, 2025 16:07
1dc3306 to
0d51e4e
Compare
@cratelyn
cratelyn
changed the title
(削除) feat(app/inbound): add response status metrics (削除ここまで)
(追記) feat(app/inbound): http and grpc status code metrics (追記ここまで)
Dec 1, 2025
in #4298, we introduced a new metrics telemetry layer that can measure and report status codes, in a protocol-agnostic fashion. this commit integrates this status code telemtry into the inbound proxy, so that HTTP and gRPC traffic can be observed. a new family of metrics is introduced to the `InboundMetrics` structure, and the inbound http\* router's metrics layer is accordingly updated to thread this metrics family into an extractor, which is in turn provided to the `NewRecordStatusCode` layer. \* as a note for reviewers, the inbound proxy does not model the http and grpc protocols as distinct concepts in the network stack's type system, unlike the outbound proxy. this means that while target types in the outbound proxy like `Http<()>` are specific to HTTP, the inbound proxy's distinction of HTTP/gRPC is determined by obtaining and inspecting the `PermitVariant`. #### 🔗 related some previous pull requests related to this change: * #4298 * #4180 * #4203 * #4127 * #4119 Signed-off-by: katelyn martin <kate@buoyant.io>
@cratelyn
cratelyn
force-pushed
the
kate/app-inbound.add-status-code-metrics
branch
from
December 1, 2025 16:13
0d51e4e to
9a3b864
Compare
Member
Author
cratelyn
commented
Dec 1, 2025
ci is not currently passing. #4330 shows that this is happening on main, and is not related to these changes.
Member
Author
cratelyn
commented
Dec 4, 2025
#4333 is addressing fixes required in linkerd-install.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
in #4298, we introduced a new metrics telemetry
layer that can measure and report status codes, in a protocol-agnostic
fashion. this commit integrates this status code telemtry into the
inbound proxy, so that HTTP and gRPC traffic can be observed.
a new family of metrics is introduced to the
InboundMetricsstructure,and the inbound http* router's metrics layer is accordingly updated to
thread this metrics family into an extractor, which is in turn provided
to the
NewRecordStatusCodelayer.* as a note for reviewers, the inbound proxy does not model the http and
grpc protocols as distinct concepts in the network stack's type system,
unlike the outbound proxy. this means that while target types in the
outbound proxy like
Http<()>are specific to HTTP, the inbound proxy'sdistinction of HTTP/gRPC is determined by obtaining and inspecting the
PermitVariant.🔗 related
some previous pull requests related to this change:
NewRecordStatusCodemiddleware #4298Permitted<T>target #4119