Use the same naming rules for the names of logging dimensions

[iliar-turdushev]

The following has been implemented:

• Use OTel semantic conventions for the names of logging dimensions where possible. Since semantic conventions for logs are Experimental, and are missed for the most of areas/objects we need to agree on the dimensions names, we decided to use semantic conventions for traces. Semantic conventions for traces are also Experimental, but they are defined for a wide variety of areas/objects.
• If a semantic convention for a dimensions or a log message parameter is missing, then we use PascalCase for the name of the dimension.
• Use dot "." instead of underscore "_" as a separator for the names of dimension of LogPropertiesAttribute and TagProviderAttribute.
• Remove "env_" preffix from the names of enrichment dimensions.

Microsoft Reviewers: Open in CodeFlow

[iliar-turdushev]

@ananthsr If we rename enrichment property latencyInfo to LatencyInfo (the first letter is Capital), won't it affect latency measurement? Thank you.

[klauco]

@ananthsr If we rename enrichment property latencyInfo to LatencyInfo (the first letter is Capital), won't it affect latency measurement? Thank you.

let's ensure we align the naming here regardless of the impact.

[xakep139]

Is the PR still draft?

[xakep139]

@iliar-turdushev any chance you checked logging categories we use?

[geeknoid]

Why do we need to change all the logging templates from {foo} to {Foo}?

[iliar-turdushev]

Why do we need to change all the logging templates from {foo} to {Foo}?

@geeknoid
One of the goals of this PR is to be aligned with naming rules/conventions being used in the rest of dotnet, in case there is no a corresponding OTel semantic-convention. In dotnet a PascalCase is being used for the names of logging dimensions and parameters of logger messages. For example: https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpLogging/src/HttpLoggingExtensions.cs#L23C1-L24C93.

[xakep139]

@iliar-turdushev the PR LGTM, the only missing bit is header names normalization (if we agree on the naming)

[joperezr]

@xakep139 @iliar-turdushev Other than fixing code coverage, is this ready to go in?

[iliar-turdushev]

@xakep139 @iliar-turdushev Other than fixing code coverage, is this ready to go in?

@joperezr We are waiting for review from @reyang and @noahfalk. Also, if we agree to follow OTel's HTTP Request/Response header name semantics, then we'll also need to implement header name normalization.

[noahfalk]

This seems fine to me, but for anything nuanced about the conventions I probably wouldn't catch it. If you want a higher level of scrutiny, someone like Liudmila is probably a better reviewer than I.

[iliar-turdushev]

This seems fine to me, but for anything nuanced about the conventions I probably wouldn't catch it. If you want a higher level of scrutiny, someone like Liudmila is probably a better reviewer than I.

@lmolkova Please, review the PR. Thank you.

[lmolkova]

Left a few minor comments on naming.

I'm a bit concerned about the inconsistent naming patterns. otel.attributes and PascalCaseAttributes in the same log record would look messy.

[iliar-turdushev]

Left a few minor comments on naming.

I'm a bit concerned about the inconsistent naming patterns. otel.attributes and PascalCaseAttributes in the same log record would look messy.

@lmolkova Thank you very much for reviewing the PR.

Yeah, we agree, but, unfortunately, there is no perfect solution here. In our opinion, the best we can do is to follow OTel's semantic-conventions where possible. The rest, which is not yet present in OTel or cannot be aligned with OTel due to implementation details in .NET, will be aligned with .NET's naming rules. This, at least, will allow us to leverage some benefits of following OTel's schema, for example, integration with tools built on top of it.

cc @klauco