Ravitej,
I am sorry that the logs are limited in this regard. I thought there was a way to correlate those admin activity entries, though I am not set up to confirm it now.
Typically, you would use Audit data from the database for these types of Admin activities.
However, our container form factor uses an enriched log format that moves this audit data level of detail out of the database in into stdout as described here: https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/ContainerGateway11-2/administer-the-gateway/enriched-logging-in-json-format.html
This can be used to log the enriched data to a file on non-container formfactors, as described in https://knowledge.broadcom.com/external/article?articleId=261049. I have limited experience with this and cannot promise that this will give you everything your looking for, but it is where I would start.
Here is an example of an entry where i created a new services called "test":
{"package":"com.l7tech.server.admin","level":"INFO","log":{"action":"Object Changed","client-ip":"192.168.50.186","entity":"test","entity-classname":"com.l7tech.gateway.common.service.PublishedService","id":"b67c6345-c96e-4434-9da1-f2e1f617217e","message":"PublishedService #4598e6568ac7729e3387650725cf256e (test) updated (set policy)","node-id":"CJyiOP4wWhY46NleprSmtKAgMNRRHbcD","type":"admin","user":"admin","user-id":"0000000000000000fffffffffffffffe:00000000000000000000000000000003","listen-port":"Default HTTPS (9443)"},"time":"2026-01-02T20:23:28.147+0000"}
Its a little bit harder to parse since it's in JSON... but if you pretty print it you get:
{
"package": "com.l7tech.server.admin",
"level": "INFO",
"log": {
"action": "Object Changed",
"client-ip": "192.168.50.186",
"entity": "test",
"entity-classname": "com.l7tech.gateway.common.service.PublishedService",
"id": "b67c6345-c96e-4434-9da1-f2e1f617217e",
"message": "PublishedService #4598e6568ac7729e3387650725cf256e (test) updated (set policy)",
"node-id": "CJyiOP4wWhY46NleprSmtKAgMNRRHbcD",
"type": "admin",
"user": "admin",
"user-id": "0000000000000000fffffffffffffffe:00000000000000000000000000000003",
"listen-port": "Default HTTPS (9443)"
},
"time": "2026-01-02T20:23:28.147+0000"
}
And you clearly see that it identifies all of the critical information about what happened.
As a downside, I believe this will impact all of your logging, so tooling you have built around the old log format will need to be reworked for the JSON formatted logging.
I hope that helps!
-------------------------------------------
Original Message:
Sent: Jan 01, 2026 02:58 AM
From: Ravitej Reddy
Subject: To capture user related activities (login/logout) in separate log files
Hi Joseph,
We have tested the current configuration, and it is successfully capturing login and logout events. However, we are facing an issue with tracking admin‑level operations. When any user performs actions such as creating, modifying, or deleting APIs-or making changes to any cluster‑wide properties-the logs do not capture which specific user executed these actions.
We need an alternative approach or configuration that can capture detailed user identifiers for all admin‑initiated operations. This will help ensure that every action, especially administrative changes, can be fully audited and traced back to the responsible user

Thanks,
Ravitej Reddy
Original Message:
Sent: Feb 27, 2025 02:23 PM
From: Joseph Fry
Subject: To capture user related activities (login/logout) in separate log files
What gets written to the log file is determined by the configuration of your log sink.
By default, the ssg log sink includes both "Category=Audits" and Category="Gateway Log" with no additional filters.
If you want a log with just admin activities (in the logs as com.l7tech.server.admin) including log in/outyou could try a log sink like below. In my testing it gets the login and logout events, and other admin events.

Keep in mind that your log.levels Cluster Wide Property plays a big role in what actually hits the log sinks. For example if you had modified it and set "com.l7tech.level = Warning" the log in/out messages would never reach the log sink filters. In that case you would need to add a log.levels line like "com.l7tech.server.admin.level = INFO" to ensure those messages make it to the sink.
I hope this makes sense?
Original Message:
Sent: Feb 27, 2025 03:27 AM
From: Kuldeep H
Subject: To capture user related activities (login/logout) in separate log files
SSG logs are combination of application bootup/api request/response & processed logs and other events performed at gateway store in a common log file such as ssg. We are looking for solution to capture only use login/logout information (also login through LDAP authentication) and user changes such as create/update/delete to a separate log file which should contain these information. Team, Please provide your view on this topic.