Skip to content
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

Improve Kestrel metrics #53358

Open
1 task done
JamesNK opened this issue Jan 14, 2024 · 1 comment · May be fixed by #55565
Open
1 task done

Improve Kestrel metrics #53358

JamesNK opened this issue Jan 14, 2024 · 1 comment · May be fixed by #55565
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Milestone

Comments

@JamesNK
Copy link
Member

JamesNK commented Jan 14, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

It's useful to see low-level connection and request information in Kestrel. This information can be used to track regular web app usage, diagnose performance issues and observe malicious activity.

Describe the solution you'd like

Improve Kestrel metrics:

  • Add tags to the exist Kestrel connection metric with the internal reason why the connection was closed. Consider adding the public protocol response code, e.g. GOAWAY.
  • Consider adding a stream duration metric for multiplex connections (HTTP/2, HTTP/3) with information about the stream, including why it was closed (internal reason and public protocol code)

Tracking the number of streams a multiplexed connection created could also be valuable. I'm not sure the best way to do that. Tag on a connection (will need to be rounded to certain values to limit cardinality) or a separate kestrel.connection.streams_count histogram metric.

Additional context

No response

@JamesNK JamesNK added the area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions label Jan 14, 2024
@JamesNK JamesNK added this to the 9.0.0 milestone Jan 14, 2024
@amcasey
Copy link
Member

amcasey commented Jan 26, 2024

It would be nice if we could:

  1. Detect an ongoing attack
  2. Fingerprint a past attack

@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@JamesNK JamesNK linked a pull request May 9, 2024 that will close this issue
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants