Pat, please file a ticket with support for this kind of RFE.  It looks like quite a bit of work is required to get this integrated (including upstream) and so we need a business justification for that.

It looked like the upstream bug has a patch for the relevant behavior.

I'll reach out for getting an appropriate support case file.

Upstream docs (http://httpd.apache.org/docs/trunk/mod/mod_log_config.html#customlog) suggest this has already been added to trunk somehow despite status of that upstream bug.

~~~
Syntax: CustomLog file|pipe|provider format|nickname [env=[!]environment-variable| expr=expression]
...
*provider*
    Modules implementing ErrorLog providers can also be used as a target for CustomLog messages. To use ErrorLog provider as a target, "provider:argument" syntax must be used. You can for example use mod_journald or mod_syslog as a provider:

    # CustomLog logging to journald
    CustomLog "journald" "%h %l %u %t \"%r\" %>s %b"

    # CustomLog logging to syslog with "user" facility
    CustomLog "syslog:user" "%h %l %u %t \"%r\" %>s %b"
~~~

I didn't look into the code behind it (or even checkout trunk and test), but man if it's something that gets stable and backported to upstream's 2.4, wow we *have* to backport it to RHEL's httpd24. It would make life so much easier for so many people.

Yes, Jan wrote mod_journald and pushed it upstream, which provides both access logging and error logging via journald.  See also bug 1168956.

The big problem with this is that there is a severe performance impact to logging via journald at the moment due to a kernel restriction.  We don't want to add this to RHEL httpd unless the journald/kernel side is also resolved.

For us it would be really great if the second module "mod_syslog" would be provided in RHEL7 to log directly to rsyslog without the way over /usr/bin/logger and journald.

On high load server (>1000 req/s) the way over the default logger crash the logging (httpd -> logger -> journald -> rsyslog). With the module the direct way from httpd to rsyslog would be really nice.

At the moment we have to use a script instead of the logger to log directly to rsyslog. Thanks to Ryan to help us to improve the performance of that way.

This feature would be super useful on my end.

Could the enhanced logging be provided as a Tech Preview feature with known performance problems?  I've no real preference between syslog and journald, but I would very much like to see this in my production environment.

Just swinging back around on this one.

Sorry.  The patches are in trunk, I'll revive the effort to get them backported to 2.4.x and we can look at pulling them into RHEL7 httpd.

Awesome! Any chance they'll make it into RHEL8 too?

Just swinging back around...

It does not appear to be feasible to backport syslog support for CustomLog.  However, I have found a way to backport journald support, though without the structured logging support used in upstream 2.5's mod_journald.

I am therefore adjusting the RFE to cover just journald.  mod_journald will be supported once there is a stable (e.g. 2.6) release which we can package as a new module stream.

The syntax supported is:

  CustomLog journald:priority format|nickname

where "priority" is a priority string as in LogLevel http://httpd.apache.org/docs/2.4/mod/core.html#loglevel
Only priorities up to debug are permitted (the syslog/journald interfaces do not support trace* levels)

(In reply to Joe Orton from comment #28)
> The syntax supported is:
> 
>   CustomLog journald:priority format|nickname
> 
> where "priority" is a priority string as in LogLevel
> http://httpd.apache.org/docs/2.4/mod/core.html#loglevel
> Only priorities up to debug are permitted (the syslog/journald interfaces do
> not support trace* levels)

Were there any documentation backported?

No; in fact overriding the priority level is not possible with the extensions to mod_log_config and mod_journald from trunk/2.5, which will always default to the INFO level for transfer logs (and maps error log levels to the appropriate level from httpd internal log level).

Not sure where best to document this, release notes is maybe sufficient?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: httpd:2.4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4751