Skip to content

Commit 0be3bc3

Browse files
author
Liudmila Molkova
committed
lint
1 parent ec29ff0 commit 0be3bc3

File tree

1 file changed

+6
-5
lines changed

1 file changed

+6
-5
lines changed

oteps/4333-recording-exceptions-on-logs.md

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@
66
- [Guidance](#guidance)
77
* [Details](#details)
88
- [API changes](#api-changes)
9+
- [SDK changes](#sdk-changes)
910
- [Examples](#examples)
1011
* [Logging errors from client library in a user application](#logging-errors-from-client-library-in-a-user-application)
1112
* [Logging errors inside the natively instrumented library](#logging-errors-inside-the-natively-instrumented-library)
@@ -150,11 +151,11 @@ be to record exception stack traces when logging exceptions at `Error` or higher
150151
- The application encounters a (presumably) terminal error, such as an out-of-memory condition.
151152

152153
6. When recording exceptions/errors in logs, applications and instrumentations are encouraged to add additional attributes
153-
to describe the context in which the exception/error has happened.
154+
to describe the context in which the exception/error occurred.
154155
They are also encouraged to define their own events and enrich them with exception/error details.
155156

156157
7. The OTel SDK SHOULD record exception stack traces on logs with severity `Error` or higher and drop
157-
then on logs with lower severity. It SHOULD allow users to change the threshold.
158+
them on logs with lower severity. It SHOULD allow users to change the threshold.
158159

159160
See [logback exception config](https://logback.qos.ch/manual/layouts.html#ex) for an example of configuration that
160161
records stack traces conditionally.
@@ -217,7 +218,7 @@ try {
217218
return response(HttpStatus.NOT_FOUND);
218219
} catch (ForbiddenException ex) {
219220
logger.logRecordBuilder()
220-
// let's assume it's really unexpected for this application - service does not have access to the underlying storage.
221+
// let's assume it's really unexpected for this application - the service does not have access to the underlying storage.
221222
.severityNumber(Severity.ERROR)
222223
.addAttribute(AttributeKey.stringKey("com.example.content.id"), contentId)
223224
// by default SDK will record stack trace for this exception since the severity is ERROR
@@ -346,7 +347,7 @@ final class InstrumentedRecordInterceptor<K, V> implements RecordInterceptor<K,
346347
.setSeverity(Severity.ERROR)
347348
.addAttribute("messaging.message.id", record.getId())
348349
...
349-
.addException(ex)
350+
.addException(exception)
350351
.setBody("Consumer error")
351352
.emit();
352353
// ..
@@ -358,7 +359,7 @@ See the [corresponding Java (tracing) instrumentation](https://github.com/open-t
358359

359360
## Prototypes
360361

361-
TODO (at least prototype in the language that does not have exceptions).
362+
TODO (at least two prototypes: one in a language that does and other in the one that does not have exceptions).
362363

363364
## Prior art and alternatives
364365

0 commit comments

Comments
 (0)