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

[OTLP] Export LogRecord.CategoryName as InstrumentationScope name #4941

Conversation

vishweshbankwar
Copy link
Member

@vishweshbankwar vishweshbankwar commented Oct 11, 2023

May fix #4867

Changes

This PR sets the InstrumentationScope name field under ScopeLogs to LogRecord.CategoryName. With this change exported logs will be grouped by the LogRecord.CategoryName.

As an example consider following scenario

var logger1 = loggerFactory.CreateLogger("ProgramA");

var logger2 = loggerFactory.CreateLogger("ProgramB");

 

logger1.FoodPriceChanged("artichoke", 9.99);

logger2.FoodPriceChanged("grapes", 9.99);

OTLP payload will look like below: The logs are grouped by CategoryName

{
  "resourceLogs": [
    {
      "resource": {
        "attributes": [
          {
            "key": "telemetry.sdk.name",
            "value": {
              "stringValue": "opentelemetry"
            }
          },
          {
            "key": "telemetry.sdk.language",
            "value": {
              "stringValue": "dotnet"
            }
          },
          {
            "key": "telemetry.sdk.version",
            "value": {
              "stringValue": "1.6.1-alpha.0.53"
            }
          },
          {
            "key": "service.name",
            "value": {
              "stringValue": "unknown_service:getting-started-console"
            }
          }
        ]
      },
      "scopeLogs": [
        {
          "scope": {
            "name": `ProgramA`
          },
          "logRecords": [
            {
              "timeUnixNano": "1697049028570433100",
              "severityNumber": "SEVERITY_NUMBER_INFO",
              "severityText": "Information",
              "body": {
                "stringValue": "Food `{name}` price changed to `{price}`."
              },
              "attributes": [
                {
                  "key": "name",
                  "value": {
                    "stringValue": "artichoke"
                  }
                },
                {
                  "key": "price",
                  "value": {
                    "doubleValue": 9.99
                  }
                }
              ],
              "observedTimeUnixNano": "1697049028570433100"
            }
          ]
        },
        {
          "scope": {
            "name": `ProgramB`
          },
          "logRecords": [
            {
              "timeUnixNano": "1697049028743206200",
              "severityNumber": "SEVERITY_NUMBER_INFO",
              "severityText": "Information",
              "body": {
                "stringValue": "Food `{name}` price changed to `{price}`."
              },
              "attributes": [
                {
                  "key": "name",
                  "value": {
                    "stringValue": "grapes"
                  }
                },
                {
                  "key": "price",
                  "value": {
                    "doubleValue": 9.99
                  }
                }
              ],
              "observedTimeUnixNano": "1697049028743206200"
            }
          ]
        }
      ]
    }
  ]
}

Merge requirement checklist

  • CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
  • Unit tests added/updated
  • Appropriate CHANGELOG.md files updated for non-trivial changes
  • Changes in public API reviewed (if applicable)

@codecov
Copy link

codecov bot commented Oct 11, 2023

Codecov Report

Merging #4941 (7c2e9c9) into main (18c85fa) will decrease coverage by 0.30%.
The diff coverage is 96.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4941      +/-   ##
==========================================
- Coverage   83.65%   83.35%   -0.30%     
==========================================
  Files         295      295              
  Lines       12325    12352      +27     
==========================================
- Hits        10310    10296      -14     
- Misses       2015     2056      +41     
Flag Coverage Δ
unittests 83.35% <96.66%> (-0.30%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
....Exporter.OpenTelemetryProtocol/OtlpLogExporter.cs 100.00% <100.00%> (ø)
...rotocol/Implementation/OtlpLogRecordTransformer.cs 89.21% <96.00%> (+1.87%) ⬆️

... and 6 files with indirect coverage changes

@vishweshbankwar vishweshbankwar marked this pull request as ready for review October 11, 2023 20:33
@vishweshbankwar vishweshbankwar requested a review from a team October 11, 2023 20:33
@CodeBlanch
Copy link
Member

I have one bit of feedback. There is actually support for instrumentation scope on LogRecord today! It is LogRecord.Logger.Name (also version there). I would vote for the SDK to set LogRecord.Logger based on the categoryName for the ILogger path. Then we can update OTLP to use that. What that would accomplish is if people use the experimental log bridge stuff it will also work correctly. But if you want to tackle that later, fine by me.

(I think this would make @alanwest happy because it would remove any knowledge of "category name" from OTLP 😄)

@vishweshbankwar
Copy link
Member Author

I have one bit of feedback. There is actually support for instrumentation scope on LogRecord today! It is LogRecord.Logger.Name (also version there). I would vote for the SDK to set LogRecord.Logger based on the categoryName for the ILogger path. Then we can update OTLP to use that. What that would accomplish is if people use the experimental log bridge stuff it will also work correctly. But if you want to tackle that later, fine by me.

(I think this would make @alanwest happy because it would remove any knowledge of "category name" from OTLP 😄)

That part requires experimental stuff. I would like to keep that one separate from this.

@CodeBlanch
Copy link
Member

That part requires experimental stuff.

Not true! Otlp will see it either public or internal but everything is there and the logic is the same either way. Whether or not the bridge api is available for other things to set it depends on experimental stuff but the SDK + LogRecord portion is always there.

@vishweshbankwar
Copy link
Member Author

That part requires experimental stuff.

Not true! Otlp will see it either public or internal but everything is there and the logic is the same either way. Whether or not the bridge api is available for other things to set it depends on experimental stuff but the SDK + LogRecord portion is always there.

I was not aware of this:

[assembly: InternalsVisibleTo("OpenTelemetry.Exporter.Console" + AssemblyInfo.PublicKey)]
[assembly: InternalsVisibleTo("OpenTelemetry.Exporter.OpenTelemetryProtocol" + AssemblyInfo.PublicKey)]
[assembly: InternalsVisibleTo("OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests" + AssemblyInfo.PublicKey)]

I can do that as a separate change. If that is ok?

@CodeBlanch
Copy link
Member

@vishweshbankwar

I can do that as a separate change. If that is ok?

Works for me!

scopeLogs.LogRecords.Add(otlpLogRecord);
}
}

return request;
}

[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal void Return(OtlpCollector.ExportLogsServiceRequest request)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stay consistent with Traces and Metrics and change this to an extension method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Planning on doing same refactor for traces and metrics. will remove the static classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow some way to set/influence InstrumentationScope for logs
4 participants