|
21 | 21 | import traceback
|
22 | 22 | from os import environ
|
23 | 23 | from time import time_ns
|
24 |
| -from typing import Any, Callable, Optional, Tuple, Union |
| 24 | +from typing import Any, Callable, Optional, Tuple, Union # noqa |
25 | 25 |
|
26 | 26 | from opentelemetry._logs import Logger as APILogger
|
27 | 27 | from opentelemetry._logs import LoggerProvider as APILoggerProvider
|
@@ -476,6 +476,43 @@ def _translate(self, record: logging.LogRecord) -> LogRecord:
|
476 | 476 | timestamp = int(record.created * 1e9)
|
477 | 477 | span_context = get_current_span().get_span_context()
|
478 | 478 | 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. |
479 | 516 | severity_number = std_to_otel(record.levelno)
|
480 | 517 | if isinstance(record.msg, str) and record.args:
|
481 | 518 | body = record.msg % record.args
|
|
0 commit comments