Skip to content

Commit c5ec6b9

Browse files
committed
Add comment from the PR
1 parent c09192c commit c5ec6b9

File tree

2 files changed

+39
-2
lines changed

2 files changed

+39
-2
lines changed

opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py

Lines changed: 38 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@
2121
import traceback
2222
from os import environ
2323
from time import time_ns
24-
from typing import Any, Callable, Optional, Tuple, Union
24+
from typing import Any, Callable, Optional, Tuple, Union # noqa
2525

2626
from opentelemetry._logs import Logger as APILogger
2727
from opentelemetry._logs import LoggerProvider as APILoggerProvider
@@ -476,6 +476,43 @@ def _translate(self, record: logging.LogRecord) -> LogRecord:
476476
timestamp = int(record.created * 1e9)
477477
span_context = get_current_span().get_span_context()
478478
attributes = self._get_attributes(record)
479+
# This comment is taken from GanyedeNil's PR #3343, I have redacted it
480+
# slightly for clarity:
481+
# According to the definition of the Body field type in the
482+
# OTel 1.22.0 Logs Data Model article, the Body field should be of
483+
# type 'any' and should not use the str method to directly translate
484+
# the msg. This is because str only converts non-text types into a
485+
# human-readable form, rather than a standard format, which leads to
486+
# the need for additional operations when collected through a log
487+
# collector.
488+
# Considering that he Body field should be of type 'any' and should not
489+
# use the str method but record.msg is also a string type, then the
490+
# difference is just the self.args formatting?
491+
# The primary consideration depends on the ultimate purpose of the log.
492+
# Converting the default log directly into a string is acceptable as it
493+
# will be required to be presented in a more readable format. However,
494+
# this approach might not be as "standard" when hoping to aggregate
495+
# logs and perform subsequent data analysis. In the context of log
496+
# extraction, it would be more appropriate for the msg to be
497+
# converted into JSON format or remain unchanged, as it will eventually
498+
# be transformed into JSON. If the final output JSON data contains a
499+
# structure that appears similar to JSON but is not, it may confuse
500+
# users. This is particularly true for operation and maintenance
501+
# personnel who need to deal with log data in various languages.
502+
# Where is the JSON converting occur? and what about when the msg
503+
# represents something else but JSON, the expected behavior change?
504+
# For the ConsoleLogExporter, it performs the to_json operation in
505+
# opentelemetry.sdk._logs._internal.export.ConsoleLogExporter.__init__,
506+
# so it can handle any type of input without problems. As for the
507+
# OTLPLogExporter, it also handles any type of input encoding in
508+
# _encode_log located in
509+
# opentelemetry.exporter.otlp.proto.common._internal._log_encoder.
510+
# Therefore, no extra operation is needed to support this change.
511+
# The only thing to consider is the users who have already been using
512+
# this SDK. If they upgrade the SDK after this change, they will need
513+
# to readjust their logging collection rules to adapt to the latest
514+
# output format. Therefore, this change is considered a breaking
515+
# change and needs to be upgraded at an appropriate time.
479516
severity_number = std_to_otel(record.levelno)
480517
if isinstance(record.msg, str) and record.args:
481518
body = record.msg % record.args

opentelemetry-sdk/tests/logs/test_export.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -199,7 +199,7 @@ def test_simple_log_record_processor_different_msg_types(self):
199199
"CRITICAL",
200200
),
201201
(["list", "of", "strings"], "WARNING"),
202-
({"key": "value"}, "ERROR")
202+
({"key": "value"}, "ERROR"),
203203
]
204204
emitted = [
205205
(item.log_record.body, item.log_record.severity_text)

0 commit comments

Comments
 (0)