[RFC]: Log system refactoring

[Bounty-hunter]

Motivation.

The current logging system has several issues:

• Multiple logging mechanisms are mixed together (e.g., logging, print, and the vLLM logger), which leads to duplicate log outputs, and poor maintainability in the long term.

_logging.getLogger(__name__).debug(
    "[Stage-%s] Received batch size=%d, request_ids=%s",
    stage_id,
    len(batch_tasks),
    batch_request_ids,
)
print("--------------------------------", flush=True)
print(
    f"[Stage-{stage_id}] Received batch size={len(batch_tasks)}, request_ids={batch_request_ids}",
    flush=True,
)
print("--------------------------------", flush=True)

try:
    summary = metrics.build_and_log_summary(final_stage_id_for_e2e)
    logger.info("[Summary] %s", summary)
except Exception as e:
    logger.exception("[Orchestrator] Failed to build/log summary: %s", e)
finally:
    self.request_states.pop(request_id, None)

def build_and_log_summary(self, final_stage_id_to_prompt: dict[str, int]) -> dict[str, Any]:
    ...
    if self.enable_stats and self.stats_file:
        log_orchestrator_summary(self.stats_file, summary)
    if self.enable_stats and self.overall_stats_file:
        log_overall_summary(self.overall_stats_file, summary)
    return summary

• Logs from different stages are mixed together making it difficult to distinguish and analyze stage-specific behaviors.

INFO 12-24 01:51:22 [initialization.py:60] Created connector for 1 -> 2: SharedMemoryConnector
The argument `trust_remote_code` is to be used with Auto classes. It has no effect here and is ignored.
Unrecognized keys in `rope_scaling` for 'rope_type'='default': {'mrope_section'}
INFO 12-24 01:51:23 [model.py:637] Resolved architecture: Qwen2_5OmniModel
INFO 12-24 01:51:23 [model.py:1750] Using max model len 32768

Proposed Change.

• unifiled with vllm logger
• metric refactor

Feedback Period.

No response

CC List.

No response

Any Other Things.

No response

Before submitting a new issue...

• Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

[hsliuustc0106]

this is an important refactor which will make debugging easier

[yinpeiqi]

Currently, the logging system only prints output to the command line and does not persist detailed logs, such as the state of each request or the input/output token counts at each stage. Saving logs to a file is quite essential for monitoring system behavior, for example to identify which requests produce unexpectedly long outputs. Are there any plans to re-add this kind of file-based per-request logging support?

[Bounty-hunter]

Currently, the logging system only prints output to the command line and does not persist detailed logs, such as the state of each request or the input/output token counts at each stage. Saving logs to a file is quite essential for monitoring system behavior, for example to identify which requests produce unexpectedly long outputs. Are there any plans to re-add this kind of file-based per-request logging support?

I think "per-request logs" is definitely necessary, but "to a file" maybe not. If persistence is needed, you can redirect the output when starting vllm-omni to save logs to a file.

For per-request logging, by export VLLM_LOGGING_LEVEL=DEBUG, it provide more detailed request-level output for now. Since this RFC mainly focuses on refactoring the logging mechanism, it doesn’t modify the actual logging content. We’re glad to see you can enhancing the log details based on use cases. For example, similar to vLLM, with --enable-log-requests option, we can consider adding more detail about the request execution.

[yinpeiqi]

Agreed. whether "to a file" could manually operate by the user. But I think, we should expose an interface for the user to obtain the metrics, and the user could do analysis or print it by itself.

When I running the experiments, I want to obtain a json file of per-request logs and use script to analysis it. From this starting point, output to the commend line, or redirect the output to a file is not a feasible solution.

I suggest: in generate, stores the metrics after generation, e.g., self.metrics = metrics; and user could call omni_llm.get_metrics() or omni_llm.generate(..., return_metric=True) to obtain the metrics. And provide interface like metric.save_to_file(path) to users.

[Bounty-hunter]

Agreed. whether "to a file" could manually operate by the user. But I think, we should expose an interface for the user to obtain the metrics, and the user could do analysis or print it by itself.

When I running the experiments, I want to obtain a json file of per-request logs and use script to analysis it. From this starting point, output to the commend line, or redirect the output to a file is not a feasible solution.

I suggest: in generate, stores the metrics after generation, e.g., self.metrics = metrics; and user could call omni_llm.get_metrics() or omni_llm.generate(..., return_metric=True) to obtain the metrics. And provide interface like metric.save_to_file(path) to users.

Actually, the metrics—both per-request and overall—are somewhat messy and unclear. I had planned to do a refactor in Q1, and perhaps we could discuss it together.

[hsliuustc0106]

https://github.com/vllm-project/vllm-omni/blob/main/vllm_omni/entrypoints/omni_diffusion.py#L14

# TODO configure logging properly
logging.basicConfig(level=logging.INFO)  # <--- THIS IS BAD

The Bug: Calling logging.basicConfig() at the top level of a library module is a major "party foul" in Python development.

Consequence: If a user imports vllm_omni into their own application (which has its own logging setup), this line will override or conflict with their configuration. It might force logs to stderr when the user wanted them in a file, or change the log level globally for the entire application.

Fix: Remove this line entirely. Libraries should never configure the root logger; only the application entry point (the main script) should do that.