You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only JSON option today is a JSON-shaped LOG_FORMAT string, which README notes is not escape-safe — messages containing quotes or newlines break the line. Color codes are also always on, regardless of TTY, which adds noise in container logs.
What is the feature you are proposing to solve the problem?
Re-scoped after aidial-sdk 0.38.0 (release, docs/logging.md): the SDK now ships the JSON mode this issue originally proposed to build — escape-safe single-line records via DIAL_SDK_LOG_FORMAT=json, template overrides, auto-added OTEL correlation fields, and a public configure_root_logger() that routes all loggers through one env-selected console handler. The issue becomes an adoption task:
Migrate LoggingConfig from owning the formatter/handler to calling configure_root_logger(), keeping per-logger level pinning locally. Note the ordering inversion: today logging config must run before the app is built, while configure_root_logger() runs after and preserves non-console handlers — the OTLP export path (App logs are not exported when OTEL_LOGS_EXPORTER=otlp #433) must be re-verified.
Decide the fate of the legacy LOG_FORMAT / LOG_DATE_FORMAT env vars: bridge them into the SDK's LogConfig or deprecate them in favor of the DIAL_SDK_* variables.
Remove the deprecated OTEL_PYTHON_LOG_CORRELATION from deployment values — under 0.38 it double-logs SDK records and suppresses the new console takeover; trace-field injection now follows tracing itself, so nothing is lost.
Consolidated logging documentation as a dedicated document under docs/ (e.g. docs/logging.md) in the same PR, largely deferring to the SDK's document.
Field naming follows the SDK defaults (level, time, logger, process, message, otel*); this becomes the contract for the request-context fields (#439).
Out of scope (upstream behavior): TTY-aware color handling in text mode — the SDK text formatter forces colors on, and JSON mode makes the concern moot in containers. Can be raised upstream separately if it still matters.
What alternatives have you considered?
Building the JSON formatter locally, as originally scoped — superseded by aidial-sdk 0.38.0, which ships the same outcome upstream; a local implementation would duplicate it and drift. Documenting the LOG_FORMAT workaround's limits — it corrupts exactly the interesting records (tracebacks, quoted messages).
Additional information
Builds on the handler strategy from #433. Preceded by the aidial-sdk 0.38.x version bump. Upstream feature: epam/ai-dial-sdk#416.
QuickApps version
latest
What is the problem this feature will solve?
The only JSON option today is a JSON-shaped
LOG_FORMATstring, which README notes is not escape-safe — messages containing quotes or newlines break the line. Color codes are also always on, regardless of TTY, which adds noise in container logs.What is the feature you are proposing to solve the problem?
Re-scoped after aidial-sdk 0.38.0 (release, docs/logging.md): the SDK now ships the JSON mode this issue originally proposed to build — escape-safe single-line records via
DIAL_SDK_LOG_FORMAT=json, template overrides, auto-added OTEL correlation fields, and a publicconfigure_root_logger()that routes all loggers through one env-selected console handler. The issue becomes an adoption task:LoggingConfigfrom owning the formatter/handler to callingconfigure_root_logger(), keeping per-logger level pinning locally. Note the ordering inversion: today logging config must run before the app is built, whileconfigure_root_logger()runs after and preserves non-console handlers — the OTLP export path (App logs are not exported when OTEL_LOGS_EXPORTER=otlp #433) must be re-verified.LOG_FORMAT/LOG_DATE_FORMATenv vars: bridge them into the SDK'sLogConfigor deprecate them in favor of theDIAL_SDK_*variables.OTEL_PYTHON_LOG_CORRELATIONfrom deployment values — under 0.38 it double-logs SDK records and suppresses the new console takeover; trace-field injection now follows tracing itself, so nothing is lost.docs/(e.g.docs/logging.md) in the same PR, largely deferring to the SDK's document.Field naming follows the SDK defaults (
level,time,logger,process,message,otel*); this becomes the contract for the request-context fields (#439).Out of scope (upstream behavior): TTY-aware color handling in text mode — the SDK text formatter forces colors on, and JSON mode makes the concern moot in containers. Can be raised upstream separately if it still matters.
What alternatives have you considered?
Building the JSON formatter locally, as originally scoped — superseded by aidial-sdk 0.38.0, which ships the same outcome upstream; a local implementation would duplicate it and drift. Documenting the
LOG_FORMATworkaround's limits — it corrupts exactly the interesting records (tracebacks, quoted messages).Additional information
Builds on the handler strategy from #433. Preceded by the aidial-sdk 0.38.x version bump. Upstream feature: epam/ai-dial-sdk#416.