-
Notifications
You must be signed in to change notification settings - Fork 0
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
Dotnet8 metrics: proposals #2
Conversation
| `signalr.http_transport.transport` | string | TODO [2] | `TODO` | Recommended | | ||
| `signalr.signalr.transport` | string | SignalR transport - https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/docs/specs/TransportProtocols.md [1] | `ServerSentEvents` | Conditionally Required: if HTTP SignalR transport is used | | ||
| `dotnet.error.code` | string | General-purpose error code reported by .NET, as a starter it supports terminal states of .NET task https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus. | `Canceled`; `RanToCompletion` | Recommended | | ||
| `http.response.status_code` | int | [HTTP response status code](https://tools.ietf.org/html/rfc7231#section-6). | `200` | Conditionally Required: If and only if one was received/sent. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there need for specific status code since this is http-specific metric?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is but its my research queue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a mixed bag. Some stuff seemed like good improvements, others I am pretty skeptical about. Comments inline and more research in some areas still queued up.
| `aspnet.handler` | string | TODO | `TODO` | Required | | ||
| `dotnet.error.code` | string | General-purpose error code reported by .NET, as a starter it supports terminal statuses of .NET task https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus. | `Canceled`; `RanToCompletion` | Recommended | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diagnostics_handler metrics were created for a specific purpose to help customers understand how exceptions in the pipeline were triaged by the exception handling middleware. I'm happy to rename exception.result to something else (perhaps aspnet.handler.result
?), but the goal of enumeration values is to describe how the exception was dealt with. I would not change the semantics of the enumeration without an analysis in the context of the original feature ask and the overall function of the exception handling middleware.
The feature ask is here: dotnet/aspnetcore#48625
James' description of the solution is here: dotnet/aspnetcore#48648
The enumeration values as described by James:
- Aborted - Error occurred because the request was aborted (OperationCanceledException + RequestAborted.IsCancellationRequested)
- Skipped - Response has already started. Middleware can't do anything with the response so skips doing anything.
- Handled - ExceptionHandlerMiddleware has some interesting rules here. An exception is considered handled if an IExceptionHandler returns true, IProblemDetailsService returns true, or the status code is anything other than 404. If an IExceptionHandler or IProblemDetailsService return true then the type name is set for the handler tag.
DeveloperExceptionMiddleware never reports exceptions it catches as handled - Unhandled - All of the above are false.
docs/dotnet/dotnet-aspnet-metrics.md
Outdated
@@ -149,17 +146,12 @@ This metric is required. | |||
| `aspnet.rate_limiting.queued_requests` | UpDownCounter | `{request}` | Number of requests that are currently queued, waiting to acquire a rate limiting lease. [1] | | |||
|
|||
**[1]:** Meter name is `Microsoft.AspNetCore.RateLimiting` | |||
|
|||
**TODO: if they are queued, should they have reject reason ? ** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No they shouldn't. In the original doc reject_reason isn't an attribute on this metric. I think it was added by mistake in your doc -> GH transfer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems it's there
aspnet.rate_limiting.queued_requests.duration - Histogram - seconds
aspnet.rate_limiting.policy
aspnet.rate_limiting.reject_reason
The duration of HTTP requests in a queue, waiting to acquire a rate limiting lease.
Old name: rate-limiting-queued-request-duration
and in the code - https://github.com/dotnet/aspnetcore/blob/d7379f6998b9805772ed52a4792e87e6bf13ed9d/src/Middleware/RateLimiting/src/RateLimitingMetrics.cs#L146
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are referring to doc and code content for aspnet.rate_limiting.queued_request.duration counter, but this part of the markdown doc is talking about queued_requests, not queued_request.duration right?
| [`network.protocol.version`](../general/attributes.md) | string | Version of the application layer protocol used. See note below. [1] | `3.1.1` | Recommended | | ||
| [`network.transport`](../general/attributes.md) | string | [OSI Transport Layer](https://osi-model.com/transport-layer/) or [Inter-process Communication method](https://en.wikipedia.org/wiki/Inter-process_communication). The value SHOULD be normalized to lowercase. | `tcp`; `udp` | Recommended | | ||
| [`network.type`](../general/attributes.md) | string | [OSI Network Layer](https://osi-model.com/network-layer/) or non-OSI equivalent. The value SHOULD be normalized to lowercase. | `ipv4`; `ipv6` | Recommended | | ||
| `tls.version` | string | TLS protocol version | `1.3` | Recommended | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could also be an SSL version based on the type used in the code. The internal enumeration is here:
https://source.dot.net/#System.Net.Primitives/System/Net/SecureProtocols/SslEnumTypes.cs,bfabf9fcb928e856,references
Unless James confirmed that SSL was impossible based on some filtering elsewhere then I'd expect this attribute could have values like "ssl3.0" or "tls1.3". None of the SSL and TLS versions overlap right now, but its probably good not to be ambiguous about it.
|
||
<!-- tocstop --> | ||
|
||
## Metric: `signalr_http_transport.connection.duration` | ||
## Metric: `signalr.http.server.connection.duration` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think http transport may have had a specific meaning but I need to do more research. Sorry James might have known this stuff offhand but I have to dig through the implementation and conversation history to get the context for all of these which makes each proposed change time consuming. Please still bring it up, thats just why I don't have quick answers for everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did do more research here and I think this is the context:
- SignalR is defined as a protocol that can operate over any reliable, in-order, duplex, message based transport
- Right now the only implementations of transports all use http, but in three different variants (long polling, server sent events, and web sockets)
- The Micrsoft.AspNetCore.Http.Connections assembly these metrics are implemented inside of has the logic to create those various http transport flavors. If there were some other non-http transport in the future I suspect it wouldn't be this assembly that implemented it.
- It feels reasonable to omit the word transport and let http imply 'http-based transport'. I don't see any other likely interpretation that would create ambiguity.
| `signalr.http_transport.transport` | string | TODO [2] | `TODO` | Recommended | | ||
| `signalr.signalr.transport` | string | SignalR transport - https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/docs/specs/TransportProtocols.md [1] | `ServerSentEvents` | Conditionally Required: if HTTP SignalR transport is used | | ||
| `dotnet.error.code` | string | General-purpose error code reported by .NET, as a starter it supports terminal states of .NET task https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus. | `Canceled`; `RanToCompletion` | Recommended | | ||
| `http.response.status_code` | int | [HTTP response status code](https://tools.ietf.org/html/rfc7231#section-6). | `200` | Conditionally Required: If and only if one was received/sent. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is but its my research queue.
0fd3372
to
f85bfa8
Compare
Adding OpenAI metrics and fixing markdown errors
No description provided.