Open NinoFloris opened 3 years ago
cc @maryamariyan
RequestId
is really not relevant anymore (at least to us) withSpanId
andTraceId
being integrated by default but we can't turn it off
This might be redundant in the default use, but they aren't entirely useless. You can turn off Span and Trace using https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.activitytrackingoptions?view=dotnet-plat-ext-5.0
there exist a few scope pushes that have limited or no value for us
You can provide a custom IExternalScopeProvider
which will enable you to filter which scopes are logged.
We should support this more natively in logging. It's really not possible to turn off scopes today
Yep, I believe @shirhatti was going to file an issue.
Triage: We should look at making the RequestId
scope configurable. And templates should have it off by default.
Thanks for contacting us.
We're moving this issue to the Next sprint planning
milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
@BrennanConroy this issue (and specifically that comment) led me to believe trying to override IExternalScopeProvider
for the console logger was not a properly supported scenario https://github.com/dotnet/runtime/issues/36090#issuecomment-537177373
As to the conclusion, this means connectionid and requestpath would stay?
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Yes, agree with this. I just tried to add OpenTelemetry context to JSON console logging in an ASP.NET Core 6 project.
Using the "IncludeScopes" formatter option I get the below scopes on a log , when all I really want is the TraceId/SpanId for correlation purposes.
"Scopes": [
{
"Message": "SpanId:7d01d402b9b9fda5, TraceId:ebd21c67aaf93cc221a6ea2ecc416a24",
"SpanId": "7d01d402b9b9fda5",
"TraceId": "ebd21c67aaf93cc221a6ea2ecc416a24"
},
{
"Message": "ConnectionId:0HMP7SSS89CFI",
"ConnectionId": "0HMP7SSS89CFI"
},
{
"Message": "RequestPath:/x/y RequestId:0HMP7SSS89CFI:00000002",
"RequestId": "0HMP7SSS89CFI:00000002",
"RequestPath": "/x/y"
},
{
"Message": "XXX.PostAsync (YYY)",
"ActionId": "0e04439b-492e-4a1c-aea8-7131c3f64482",
"ActionName": "XXX.PostAsync (YYY)"
}
You can exclude scopes by configuring ActivityTrackingOptions when initialising the logging service.
builder.Services.AddLogging(options =>
{
options.Configure(c => c.ActivityTrackingOptions = ActivityTrackingOptions.None);
});
We use scopes to identify log entries as coming from a certain tenant, this is a critical part of our diagnostic ability.
Scopes have various performance downsides but due to the value they provide we really wouldn't want to disable them completely. We also add all scopes to our json logger going to cloud logging and the smaller these messages can be the better, there is a direct financial cost attached to ingestion of larger than need be messages over time.
However, and this is the issue, in the framework there exist a few scope pushes that have limited or no value for us and can't be turned off without also turning off important log messages.
ConnectionId
is not relevant to us, but we can't turn it off because all of it is enabled under categoryMicrosoft.AspNetCore.Server.Kestrel
which also contains important log messages like reaching connection limits.RequestId
is really not relevant anymore (at least to us) withSpanId
andTraceId
being integrated by default but we can't turn it offRequestPath
is occasionaly useful but we could just as well emit it ourselves.Our minimal scopes would ideally look like:
Would it be possible to provide knob(s) to disable these kestrel scopes somewhere, like in
KestrelServerOptions
? (not sure where RequestId + RequestPath comes from)