Exceptions for Structured Logs

[Flash0ver]

Description

Through both internal and external feedback, as the next addition to Structured Logs, we should support Exceptions.

Especially considering the APIs of Microsoft.Extensions.Logging through the ILogger.Log<TState> method, and the LoggerExtensions extension methods.

Sentry.SentryStructuredLogger

We could add overloads that take an Exception, either with or without the template-String, or both:

public void Log/*Level*/(Exception? exception);
public void Log/*Level*/(string template, object[]? parameters = null, Exception? exception);
public void Log/*Level*/(Exception? exception, string template, object[]? parameters = null);

For comparison the LoggerExtensions methods, which optionally places the exception before the message:

public static void Log/*Level*/(this ILogger logger, EventId eventId, Exception? exception, string? message, params object?[] args)
public static void Log/*Level*/(this ILogger logger, EventId eventId, string? message, params object?[] args)
public static void Log/*Level*/(this ILogger logger, Exception? exception, string? message, params object?[] args)
public static void Log/*Level*/(this ILogger logger, string? message, params object?[] args)

Microsoft.Extensions.Logging.ILogger

Due to the prevalence of this de-facto Logging-Abstraction for all modern application models, we should not just discard the Exception already available and used by existing applications.

log Envelope and Payload

Structured Logs is not a replacement for Events, but an enhancement. Also, the average byte size of a log should be kept as small as possible, see Logs Dev Docs. So we should not log entire Stack Traces. However, we could add some limited information about the Exception instance, such as Message and Type, attached as attributes. E.g.

{
  "body": "..",
  ..,
  "attributes": {
    "exception.message": {
      "value": "An item with the same key has already been added. Key: my-key",
      "type": "string"
    }
    "exception.type": {
      "value": "System.ArgumentException",
      "type": "string"
    }
  }
}

See also OTEL's Exception: https://getsentry.github.io/sentry-conventions/generated/attributes/exception.html

What should be the behavior, if no message is provided, but only an Exception?

• Exception-Message as "body", Exception-Type as attribute.
• Exception-Message as "body", both Exception-Message and Exception-Type as attribute.

Sentry

Supporting a clickable link from Logs to Issues/Errors is currently not considered (see https://github.com/getsentry/sentry-dotnet/issues/4132#issuecomment-3179177147). However, from Issues/Errors, you can view Logs with the same Trace-ID, as well has navigate from Logs via the Trace to the Error.

[linear[bot]]

NET-414 Exceptions for Structured Logs

[jamescrosswell]

Could we capture the exception as an event and then link to that from the relevant log (rather than trying to reproduce some/all of what we already do for exception events in logs)?

[Syed-RI]

ETA?

[bruno-garcia]

we just shipped the experimental support for logs. we need to get some usage and focus on quality for now before we keep expanding in terms of functionality. also next 4 weeks are focused on quality in general at the company and we have a big backlog of bugs in this repo

[Syed-RI]

Appreciate the feedback @bruno-garcia, but it seems this will be critical part for us to call it "Prod Ready" for our MAUI project. Is there any way this can get prioritised? As otherwise we dont see the actual exception that happened.

example:

try
{
    _logger.LogInformation("Logging via Sentry");
    ....
}
catch (MyException ex)
{
    _logger.LogError(ex, "Something went wrong"); // ex is not propagated in Sentry dash
}

cc @jamescrosswell @Flash0ver

[jamescrosswell]

We could look at prioritising this once version 6 is GA @Flash0ver? Having some version of Sentry that works with .NET 10 is the current priority and we won't get this into the version 6 release.

There are various other things, like metrics, in the pipeline as well but we should definitely finish logs before adding more stuff.