Skip to content

Commit

Permalink
add open question about log limits
Browse files Browse the repository at this point in the history
  • Loading branch information
lmolkova committed Dec 27, 2024
1 parent 94abf82 commit 1a1ea49
Showing 1 changed file with 6 additions and 5 deletions.
11 changes: 6 additions & 5 deletions oteps/4333-recording-exceptions-on-logs.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ this OTEP proposes to record exception stack traces on logs with `Error` or high
It should not be an instrumentation library concern to decide whether exception stack trace should be recorded or not.
Library may write logs providing exception instance through a log bridge and not be aware of this guidance.

It also maybe desirable by some vendors/apps to record all the exception details.
It also maybe desirable by some vendors/apps to record all exception details at all levels.

OTel Logs API should provide methods that enrich log record with exception details such as
`setException(exception)` similar to [RecordException](../specification/trace/api.md?plain=1#L682)
Expand Down Expand Up @@ -242,8 +242,8 @@ MessageContext context = retrieveNext();
try {
processMessage.accept(context)
} catch (Throwable t) {
// This native instrumentation may use OTel log API or another logging library such as SLF4J.
// Here we use Error severity since it remained unhandled by the application code
// This native instrumentation may use OTel log API or another logging library such as slf4j.
// Here we use Error severity since this exception was not handled by the application code.
logger.atError()
.addKeyValuePair("messaging.message.id", context.getMessageId())
...
Expand All @@ -268,7 +268,7 @@ final class InstrumentedRecordInterceptor<K, V> implements RecordInterceptor<K,

@Override
public void failure(ConsumerRecord<K, V> record, Exception exception, Consumer<K, V> consumer) {
// we should capture the error in the scope of the processing span (or pass its context explicitly).
// we should capture this error in the scope of the processing span (or pass its context explicitly).
logger.logRecordBuilder()
.setSeverity(Severity.ERROR)
.addAttribute("messaging.message.id", record.getId())
Expand Down Expand Up @@ -314,7 +314,8 @@ Alternatives:

## Open questions

TBD
- Do we need to have log-related limits similar to [span event limits](/specification/trace/sdk.md#span-limits)
on the SDK level?

## Future possibilities

Expand Down

0 comments on commit 1a1ea49

Please sign in to comment.