A request ID in one log line is useful. The same request ID across the parts of the system that handled the operation is much more useful. Without that connection, debugging a failure becomes a search through similar timestamps and hopeful guesses about which messages belong together.
The W3C Trace Context specification defines a standard way to carry trace information between services. You do not need to invent a completely new header format for every application. The practical benefit is continuity: a request can be followed through several components while each component still records its own part of the work.
I would also keep the user-facing support reference separate from anything sensitive. An identifier should help locate an operation without exposing credentials or dumping the request body into logs. Long-running jobs need to carry the relevant context forward too, otherwise the trace stops just before the part that failed. Make the link deliberate rather than relying on one process’s memory.
A useful support message lets somebody quote a reference and lets the engineer find the associated evidence. That closes the gap between “it failed” and a specific operation we can investigate. More logging is not automatically better; a reliable way to connect the right logs usually helps more.