Why does a SELinux problem get reported in /var/log/messages?

I have found a SELinux problem with logrotate. I’m just wondering why it was reported in /var/log/messages, and not in /var/log/audit/audit.log. I assumed that any SELinux issue gets logged into audit.log. Can anyone explain the reason?

I encountered this behaviour on a RHEL 8 system. Found entry in messages:

Nov 22 03:23:14 itsrv2489 setroubleshoot[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6. For complete SELinux messages run: sealert -l 2c99b2ca-3bf0-486d-b1c3-54bc6e87105e
Nov 22 03:23:14 itsrv2489 platform-python[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that logrotate should be allowed read access on the g6 directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate#012# semodule -X 300 -i my-logrotate.pp#012

These two lines from above formatted by me:

Nov 22 03:23:14 itsrv2489 setroubleshoot[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6. 
For complete SELinux messages run: 
sealert -l 2c99b2ca-3bf0-486d-b1c3-54bc6e87105e

Nov 22 03:23:14 itsrv2489 platform-python[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that logrotate should be allowed read access on the g6 directory by default.

Then you should report this as a bug.
You can generate a local policy module to allow this access.

allow this access for now by executing:
# ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate
# semodule -X 300 -i my-logrotate.pp

Usually I see such entries in /var/log/audit/audit.log.

Update: Finally I’ve found out, that audit.log was rotated itself and since it was very large some records were dropped. That’s the reason why I could not find the key word ‘logrotate’ in those audit log files. I modified /etc/audit/auditd.conf to disable rotation and on the next day I was able to find ‘logrotate’ in the audit.log (gets triggered by cron job, once a day).