Adding a feature to get the traceidentifier for a request #210
Conversation
|
Hi @Praburaj, I'm your friendly neighborhood Microsoft Open Technologies, Inc. Pull Request Bot (You can call me MSOTBOT). Thanks for your contribution!
TTYL, MSOTBOT; |
ghost
added
the
|
|
|
Sure @GrabYourPitchforks. We can add a DateTime field to this interface having that information. |
| /// <summary> | ||
| /// Identifier to trace a request. | ||
| /// </summary> | ||
| Guid TraceIdentifier { get; } |
There was a problem hiding this comment.
Any reason this is specifically a Guid and not a string? (The OWIN spec doesn't specify a format.)
There was a problem hiding this comment.
BTW I'm not suggesting it should be a string, just asking.
There was a problem hiding this comment.
Traditionally these have been GUIDs so that they can be flowed via the CorrelationManager.
There was a problem hiding this comment.
Yeah that makes sense... but not really 😄 I'm not really opposed to it being a GUID, it just seems so arbitrary (even in CorrelationManager). I mean what's so special about GUIDs anyway - a correlation id is logically an opaque value. So honestly I'm fine either way.
There was a problem hiding this comment.
GUIDs actually solve the problem nicely because they have a definite ordering so can be indexed. You can't do that with strings without a lot of ceremony: making sure everything is length-prefixed in storage (nvarchar, but then you kill indexability), making sure everybody agrees on which comparer to use (good luck doing this in SQL), and so on.
There was a problem hiding this comment.
That they have a fixed, unambiguous, universal representation is a huge plus over strings, even if ordering doesn't matter. I agree that academically the difference shouldn't matter, but practically it does. I guarantee you'll have a difficult time building a reliable, high-performance correlation engine if your key is an arbitrary structureless string.
There was a problem hiding this comment.
Most of the time these Ids are persisted as a string always so I'm not sure what you mean. Are you saying if we don't use the .NET Guid type that it won the performant?
There was a problem hiding this comment.
The nearly 100% use case is that they're persisted in an ETW log or similar structure, so they're definitely not persisted as strings. Please reread my argument above - I'm not advocating GUIDs for the sake of having GUIDs, I'm advocating it because it's structured, unambiguous, and easy for correlation engines to reason about. If you have another structure in mind that meets these requirements then by all means suggest it.
There was a problem hiding this comment.
@Eilon - Just as a side note. OWIN spec actually says owin.RequestId is a string.
3.2.1 Request Data
owin.RequestId An optional string that uniquely identifies a request. The value is opaque and SHOULD have some level of uniqueness. A Host MAY specify this value. If it is not specified, middleware MAY set it. Once set, it SHOULD NOT be modified.
There was a problem hiding this comment.
Yep I read the OWIN spec 😄 Honestly I'm OK with forcing GUID because there's nothing really wrong with it in practice. It's just kind of annoying when practicality trumps so-called "correctness."
|
Any reason it's a guid instead of a string? |
| var requestId = Prop<string>(OwinConstants.RequestId); | ||
| if (requestId != null) | ||
| { | ||
| return new Guid(requestId); |
There was a problem hiding this comment.
The OWIN spec say it's an opaque value, we can't assume it will parse as a GUID. TryParse?
There was a problem hiding this comment.
sure. I can fix that. Else return Guid.Empty?
There was a problem hiding this comment.
Hmm this makes me more worried actually. If we want to support OWIN, and OWIN uses strings, I don't see how we can force GUIDs... that's not to say that if we happen to get a GUID that we shouldn't use it...
There was a problem hiding this comment.
OWIN on the top of any of IIS/Systemweb/WebListener will not be a problem. But this can affect any other servers. The alternate that I can think of is change all Guid to string and continue to produce GUID in our servers so that E2E tracing is possible (and just do a guid.ToString())?
|
@Tratcher Updated PR with feedback. |
|
|
Addresses : #117 Related changes in Helios & weblistener in separate PRs.
Addresses : #117
Related changes in Helios & weblistener in separate PRs.
@Tratcher