[Feature]Log Format Normalization and Trace Log Optimization

[qwes5s5]

Motivation

💡 If this PR is a Cherry Pick, the PR title needs to follow the format by adding the [Cherry-Pick] label at the very beginning and appending the original PR ID at the end. For example, [Cherry-Pick][CI] Add check trigger and logic(#5191)

💡 如若此PR是Cherry Pick，PR标题需遵循格式，在最开始加上[Cherry-Pick]标签，以及最后面加上原PR ID，例如[Cherry-Pick][CI] Add check trigger and logic(#5191)

Currently, the project utilizes highly fragmented logging formats. There are four primary log formats in use, which complicates unified log collection, parsing, and filtering:

1. Standard/Legacy Format

• Format String: %(levelname)-8s %(asctime)s %(process)-5s %(filename)s[line:%(lineno)d] %(message)s
• Example: INFO 2026-02-04 08:14:43,669 17777 serving_chat.py[line:697] release ...

2. Trace/Custom Format

• Format String: [%(asctime)s] [%(levelname)-8s] (%(filename)s:%(funcName)s:%(lineno)d) %(message)s
• Example: [2026-02-04 08:03:57,914] [INFO ] (engine_client.py:add_requests:296) [thread=140074076656064] ...

3. Uvicorn Access Format

• Format String: [%(asctime)s] [%(process)d] [INFO] %(message)s
• Example: [2026-02-04 08:03:57,914] [17777] [INFO] ...

4. Colorlog Uvicorn Format

• Format String: [%(log_color)s%(asctime)s] [%(levelname)+8s] %(reset)s - %(message)s%(reset)s
• Example: [2026-02-04 08:03:57,914] [ INFO] - ...

Furthermore, trace logs currently fail to capture the trace_id received from upstream requests. This leads to a lack of correlation between upstream and downstream logs, making end-to-end request tracking difficult.

Modifications

• Standardize Log Formats: Unify all log outputs into the format %(levelname)-8s %(asctime)s %(process)-5s %(filename)s[line:%(lineno)d] %(message)s to facilitate efficient log collection and parsing.
• Implement Distributed Tracing: Establish end-to-end trace context management and append trace_id metadata to all trace logs to enable request correlation across the entire lifecycle.

Usage or Command

Accuracy Tests

Checklist

• Add at least a tag in the PR title.
  • Tag list: [[FDConfig],[APIServer],[Engine], [Scheduler], [PD Disaggregation], [Executor], [Graph Optimization], [Speculative Decoding], [RL], [Models], [Quantization], [Loader], [OP], [KVCache], [DataProcessor], [BugFix], [Docs], [CI], [Optimization], [Feature], [Benchmark], [Others], [XPU], [HPU], [GCU], [DCU], [Iluvatar], [Metax]]
  • You can add new tags based on the PR content, but the semantics must be clear.
• Format your code, run pre-commit before commit.
• Add unit tests. Please write the reason in this PR if no unit tests.
• Provide accuracy results.
• If the current PR is submitting to the release branch, make sure the PR has been submitted to the develop branch, then cherry-pick it to the release branch with the [Cherry-Pick] PR tag.

[paddle-bot]

Thanks for your contribution!

[codecov-commenter]

Codecov Report

❌ Patch coverage is 90.78947% with 7 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (develop@2b4748d). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
fastdeploy/__init__.py	88.88%	1 Missing and 2 partials ⚠️
fastdeploy/logger/formatters.py	50.00%	0 Missing and 2 partials ⚠️
fastdeploy/engine/common_engine.py	66.66%	0 Missing and 1 partial ⚠️
fastdeploy/entrypoints/openai/api_server.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             develop    #6370   +/-   ##
==========================================
  Coverage           ?   67.91%           
==========================================
  Files              ?      391           
  Lines              ?    52810           
  Branches           ?     8228           
==========================================
  Hits               ?    35864           
  Misses             ?    14326           
  Partials           ?     2620           

Flag	Coverage Δ
GPU	67.91% <90.78%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Jiang-Jia-Jun]

在其它代码中使用日志工具的代码是否能简化，而不依赖复杂的配置

[Jiang-Jia-Jun]

为何需要单在WorkerProcess里面有这么大段的日志处理代码？

[qwes5s5]

为何需要单在WorkerProcess里面有这么大段的日志处理代码？

因为worker使用的paddle的日志框架，为了解决 Paddle 框架日志格式和FD自有的日志格式不一致的问题，需要在import paddle之前进行拦截和格式注入

[Jiang-Jia-Jun]

看起来这部分操作处理与worker_process的主功能是无关的。能否移到log下去作为一个功能函数（并给出明确的说明什么要有这个函数的存在），同时在worker_process仅调用

[qwes5s5]

看起来这部分操作处理与worker_process的主功能是无关的。能否移到log下去作为一个功能函数（并给出明确的说明什么要有这个函数的存在），同时在worker_process仅调用

军哥你看现在可以吗，worker_processor开头那一大段注入放到和fastdeploy平级的tools文件夹下了（不能放在fastdeploy下，fastdeploy一导入就会引入paddle导致注入失效），tools文件夹下不可以的话，就得新建一个和fastdeploy平级的文件夹了（和fastdeploy平级的log文件夹不是必然存在的，而且是放日志文件的，有的用户已经养成习惯会定期删除这个文件夹，如果放在这里感觉有点怪）