Hi Praty,
By default, the ssg log will record both Gateway Log and Audit events to the same log file. So if an event is generated that is of Category=Gateway Log OR Category=Audit, then it will write it to the ssg log file. This has no bearing on whether the Audit events are written to the database or not. The Gateway Audit Event viewer looks up audits that are written to the database. The audit-sink and audit-lookup policy will define how to handle audits being written to and looked up from the database. By default, it will write and lookup the audits from the local database.
Based on the information above, out of the box, Audit events will both be written to the database as well as written to the ssg log file. However, they are written out slightly differently. As you see in the Gateway Audit Event viewer, the audits have a relational aspect to it, meaning you can filter on different fields, search based on timestamps, you can see the Audit Details that are associated with an Audit Message. The audits that are written to the ssg log are just written line by line, and are just listed chronologically, and there is no relational aspect to it in the way that you have with the Gateway Audit Event viewer.
If you remove Category=Audit from the ssg log file, you will no longer see the audit entries in the ssg log, but you will still see the audits in the Gateway Audit Event viewer.
You mention that you have a service specific log file that has a filter like so:
Category=Audit
Service=Example
This would mean that an entry will be written to that log file only if an event is of Category=Audit AND if that event is associated with that service ("Example"). Let me know if this information is helpful, and whether you'd like some additional clarification or information.
Thanks,
Gopinath