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 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 #4132 (comment)).
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]

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?