What is a one sentence summary of your feature request?
Add an option to use the host server’s hostname instead of the container ID in logs for better SIEM integration and easier correlation.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
Currently, logs forwarded from containers include the container ID, which is dynamic and does not provide meaningful context for SIEM analysis. My idea is to introduce a configuration option that allows users to include the hostname of the host server in the logs instead of the container ID. This would enable security teams to correlate events more effectively, troubleshoot issues faster, and maintain consistency across nodes and services. The feature could be implemented in Fluentd/Fluent Bit or within the log forwarding configuration as a toggle or environment variable.
The problem is that container IDs are not helpful for SIEM correlation because they change frequently and do not map to physical or virtual hosts. Hostnames provide a stable and meaningful identifier that aligns with enterprise security practices. This solution is best because it requires minimal changes (just a configuration option) and significantly improves log usability for monitoring and incident response.
How do you currently solve the challenges you have by not having this feature?
Currently, we attempt workarounds like hardcoding hostnames in configuration files or passing environment variables manually (e.g., HOST_HOSTNAME=${HOSTNAME} in docker-compose), but these approaches are error-prone, require manual intervention on every node, and do not scale well across large environments.
This is possibly something that can be done without a product change as the log forwarding update has a dedicated config file, fluent.conf, which is used to set destination parameters for receiving server/SIEM.
The challenge here is fluentd’s plugins and dependencies have changed over the years so it’s been work to keep up with that, which was initially done via the Customer Success team and not R&D.
Hi Don,
Thank you for the update and for the detailed context around the logging configuration and the fluentd plugin changes.
I wanted to share that I’ve already worked closely with Support and we tried all available configuration options to get the hostname included in the logs — including using $hostname and attempting to pass a more “friendly” hostname through the default fields. Unfortunately, none of the available combinations achieved the desired result, and modifying the default field for this purpose isn’t technically feasible at the moment.
Given these limitations, I submitted this as a feature request so that native hostname support can be implemented directly in the product rather than depending on fluentd behavior or custom workarounds.
I appreciate your insights and the documentation link — it’s helpful background. Please let me know if there are any additional options we should revisit or if R&D needs any further details from my side.