[V1][Metrics][Plugin] Add plugin support for custom StatLoggerBase implementations

[ptovam]

Purpose

✨ Add Support for Custom Stat Logger Plugins

This PR introduces support for registering custom StatLoggerBase implementations through Python entry-points, using the plugin group vllm.stat_logger_plugins.

This allows users to inject custom metric loggers into the vLLM runtime without modifying internal code.

🔧 What’s New

• Added support for a new plugin group: vllm.stat_logger_plugins
• Plugins should return a class that subclasses StatLoggerBase.
• These plugin loggers are automatically loaded and used in addition to the built-in ones.

📍 Example: Registering a Custom Logger
In your package’s pyproject.toml or setup.py, declare:

[project.entry-points."vllm.stat_logger_plugins"]
my_custom_logger = "mylogger.stat_logger:MyStatLogger"

Test Plan

To validate the plugin mechanism, a dummy stat logger plugin was implemented and tested using the following commands:

pip install tests/plugins/vllm_add_dummy_stat_logger/
pytest -vs tests/plugins_tests/test_stats_logger_plugins.py
pip uninstall -y tests/plugins/vllm_add_dummy_stat_logger/

Test Result

All tests passed

(Optional) Documentation Update

Updated docs/design/plugin_system.md to document the new plugin type:

• Described vllm.stat_logger_plugins as a supported plugin group
• Clarified plugin value definition to allow functions or modules

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[gemini-code-assist]

Code Review

This pull request introduces a plugin system for custom StatLoggerBase implementations, which is a great addition for enhancing observability. The implementation is generally well-done, including tests and documentation updates. However, I've found a critical issue in the plugin loading logic that could lead to an engine crash if a plugin is not a class. Additionally, there's an inconsistency in the documentation regarding the plugin's entry point type. My feedback aims to address these issues to improve the robustness and clarity of this new feature.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @ptovam.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[njhill]

@ptovam you may want to update this now that #20952 is merged.

The behaviour now is that custom stats loggers will augment the built-in ones unless disable_log_stats=True.

[ptovam]

Hi @njhill, thanks! Updated — let me know if this aligns well.

[mergify]

Documentation preview: https://vllm--22456.org.readthedocs.build/en/22456/

[njhill]

Thanks @ptovam, looks great. I just have one comment.

[njhill]

Thanks @ptovam