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

LogEmitter System.Diagnostics.Tracing extension project #3305

Closed
wants to merge 53 commits into from

Conversation

CodeBlanch
Copy link
Member

@CodeBlanch CodeBlanch commented May 25, 2022

Changes

  • Adds extensions for System.Diagnostics.Tracing

Proposed Public API

namespace OpenTelemetry.Logs
{
    public class OpenTelemetryLoggerProvider
    {
+       public bool IncludeFormattedMessage { get; }
    }
}

TODOs

  • Appropriate CHANGELOG.md updated for non-trivial changes
  • Changes in public API reviewed

@codecov
Copy link

codecov bot commented May 25, 2022

Codecov Report

Merging #3305 (ffda1ce) into main (ab10e11) will decrease coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head ffda1ce differs from pull request most recent head cf69b8c. Consider uploading reports for the commit cf69b8c to get more accurate results

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3305      +/-   ##
==========================================
- Coverage   86.21%   86.17%   -0.04%     
==========================================
  Files         265      263       -2     
  Lines        9598     9543      -55     
==========================================
- Hits         8275     8224      -51     
+ Misses       1323     1319       -4     
Impacted Files Coverage Δ
.../OpenTelemetry/Logs/OpenTelemetryLoggerProvider.cs 96.10% <100.00%> (+0.05%) ⬆️
src/OpenTelemetry/Logs/Pool/LogRecordSharedPool.cs 78.94% <0.00%> (-21.06%) ⬇️
src/OpenTelemetry/ProviderExtensions.cs 81.81% <0.00%> (-9.10%) ⬇️
...Telemetry/Metrics/PeriodicExportingMetricReader.cs 72.72% <0.00%> (-5.46%) ⬇️
src/OpenTelemetry/Metrics/MetricReader.cs 86.44% <0.00%> (-1.70%) ⬇️
src/OpenTelemetry/Logs/LogRecordAttributeList.cs 74.56% <0.00%> (-0.88%) ⬇️
...ry/Internal/PeriodicExportingMetricReaderHelper.cs 100.00% <0.00%> (ø)
...qlClient/Implementation/SqlActivitySourceHelper.cs 100.00% <0.00%> (ø)
...tensions.Serilog/OpenTelemetrySerilogExtensions.cs
...try.Extensions.Serilog/OpenTelemetrySerilogSink.cs
... and 7 more

@reyang reyang self-requested a review May 25, 2022 01:13
/// Create a <see cref="LogEmitter"/>.
/// </summary>
/// <returns><see cref="LogEmitter"/>.</returns>
public LogEmitter CreateEmitter() => new(this);
Copy link
Member

Choose a reason for hiding this comment

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

Do you consider LogEmitter as a pub-sub model? (similar like ActivitySource - which can be subscribed by multiple listeners)

Copy link
Member Author

Choose a reason for hiding this comment

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

I hadn't thought about that. There isn't much in the spec, but it seems mainly to be a way to just throw logs at a processor/exporter without using a log library. I think it would be nice/useful to do this, but should we pursue through the spec first?

@CodeBlanch
Copy link
Member Author

This now also includes LogRecordPool. Blame @reyang for the scope creep 🤣

@CodeBlanch CodeBlanch changed the title [SDK] LogEmitter API [SDK] LogEmitter API + LogRecordPool May 26, 2022
/// <summary>
/// Manages a pool of <see cref="LogRecord"/> instances.
/// </summary>
public sealed class LogRecordPool
Copy link
Member Author

Choose a reason for hiding this comment

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

I didn't spend a whole lot of time on this algorithm. Just wanted to get something workable in place that we can improve as we go. There is a fast-path using a [ThreadStatic] for simple processors executing on the same thread. For the batch case there is a shared pool which is used after the [ThreadStatic].

/// Rent a <see cref="LogRecord"/> from the pool.
/// </summary>
/// <returns><see cref="LogRecord"/>.</returns>
public static LogRecord Rent() => current.RentCore(clearIfReused: true);
Copy link
Member

Choose a reason for hiding this comment

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

I don't have a clear position right now - would we prefer to do the clean up here or earlier (e.g. when the ref count goes to zero)? There might be small perf differences (e.g. I imagine Rent() is always called synchronously, while DecRef might be called asynchronously - from the exporter thread).

Copy link
Member Author

Choose a reason for hiding this comment

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

In the new iteration there isn't much to clear, log data is set fully each time (overriding what was there before). There is a bit of cleanup for the new reusable tag/attribute storage which I put on the return to the pool.

@CodeBlanch CodeBlanch mentioned this pull request Jun 18, 2022
1 task
@github-actions
Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Jun 26, 2022
@cijothomas cijothomas removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Jun 27, 2022
@CodeBlanch CodeBlanch changed the title [SDK] LogRecordPool + LogEmitter API + Serilog/Tracing extensions [SDK] LogEmitter API + Serilog/Tracing extensions Jun 30, 2022
@CodeBlanch CodeBlanch mentioned this pull request Jun 30, 2022
1 task
@github-actions
Copy link
Contributor

github-actions bot commented Jul 8, 2022

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Jul 8, 2022
Comment on lines 35 to 37
public static LoggerConfiguration OpenTelemetry(
this LoggerSinkConfiguration loggerConfiguration,
OpenTelemetryLoggerProvider openTelemetryLoggerProvider)
Copy link
Member

Choose a reason for hiding this comment

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

For some of our other extension methods we've put the extension method in the same namespace as the class that's being extended. So, does it make sense to put this method in the Serilog.Configuration namespace, or just the root Serilog namespace? Is there an existing precedence for other Serilog extensions?

EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "OpenTelemetry.Extensions.Serilog", "src\OpenTelemetry.Extensions.Serilog\OpenTelemetry.Extensions.Serilog.csproj", "{F5062ED1-6B59-45FC-8E08-2F5D41A19864}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "OpenTelemetry.Extensions.Tracing", "src\OpenTelemetry.Extensions.Tracing\OpenTelemetry.Extensions.Tracing.csproj", "{F1C65913-81EC-4297-A666-A66280E3E1B6}"
Copy link
Member

Choose a reason for hiding this comment

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

Tracing is such a commonly used term. I get it comes from System.Diagnostics.Tracing, but is there a better name?

What about OpenTelemetry.Extensions.EventSource? Or if that's too narrow of a name maybe OpenTelemetry.Extensions.EventTracing? Or... ugh maybe even OpenTelemetry.Extensions.SystemDiagnosticsTracing 🥴?

/// <summary>
/// Gets a value indicating whether or not formatted messages should be included on log messages.
/// </summary>
public bool IncludeFormattedMessage { get; }
Copy link
Member

Choose a reason for hiding this comment

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

Bugging you again with the "we sure we wanna expose this publicly, yet?" question 😆... I don't have a strong feeling that we shouldn't, just wanna raise it for discussion.

Brainstorming alternatives, would it make sense instead to expose this on the LogEmitter class?

At the moment, both the extensions are instantiated with an instance of the logging provider and then

  1. store the IncludeFormattedMessage setting, then
  2. call CreateEmitter()

Would it make sense to just instantiate the extensions with an emitter instead of the provider? So like Serilog would look like

Log.Logger = new LoggerConfiguration()
    .WriteTo.OpenTelemetry(openTelemetryLoggerProvider.CreateEmitter()) // <- Register OpenTelemetry Serilog sink
    .CreateLogger();

Again, I don't have a strong sense that one option is better than the other at this point, just curious of your thoughts.

@CodeBlanch CodeBlanch changed the title [SDK] LogEmitter API + Serilog/Tracing extensions LogEmitter Serilog & Tracing extension projects Jul 11, 2022
@CodeBlanch CodeBlanch changed the title LogEmitter Serilog & Tracing extension projects LogEmitter System.Diagnostics.Tracing extension project Jul 18, 2022
@CodeBlanch
Copy link
Member Author

Closing this PR because everything it was doing has been moved to smaller PRs.

@CodeBlanch CodeBlanch closed this Jul 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issues and pull requests which have been flagged for closing due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants