Reject a TLS-only destination for Docker GELF TCP output

Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient.

Source fact: documented behavior

The Graylog Extended Format logging driver documentation is the primary reference.

Docker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only.

What the source does not establish

This article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect.

Applicability questions

• Does the receiving input require TLS?
• Which URI scheme and port does the proposed driver configuration select?
• Do the chosen options apply to that transport?
• Where will the operator verify that the actual receiver retained the test message?

DSE recommendation: agree the endpoint contract before deployment

DSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition.

For a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection.

Review selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material.

Define an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention.

Verification and evidence

Proposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment.

Generate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery.

Official references

• Graylog Extended Format logging driver — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.