Protect switching SSM log levels from INFO to ALL more and add CLI to query current log levels

Switching from SSM log level INFO to ALL has the potential to slow down the cluster signifantly. It has caused two S2 (S1 is highest) in the last 3 years. Both were due to human error due to lack of knowledge (not knowing about the impact of it, or that it should only be enabled for a short period of time). Some protection in the product would help to mitigate the risk from the human factor.

1. It could not be turned on so easily as it can be turned on today or inadvertantly - considering that it has severe performance impact to the cluster.

With regards to implementation it could be either promting a warning about potential impact and/or asking for confirmation.

2. CLI query for the actual/current log level would eleminate the need of parsing SSM logs for the actual log level after a dynamic log level change.

Needed By

Quarter

Post comment

Guest

Jul 17, 2026
Hi Donat, hopefully you remember this issue. There are two requirements. The first is clear, to warn users when increasing the log level of the ssm. The second requirement is not that clear. We are proposing the following, please let me know if this satisfies the requirement.

Proposed Behaviour for Requirement 2
The new CLI query is intended to report the current ssm_all log level only.
Proposed command
```
soamlog ssm_all <app_name> -v
```
Expected behaviour
- The command returns the current overall SSM log level for the running application based on the most recent soamlog command or default if the level in log4cxx file is active.
- If the log level has been changed using soamlog ssm_all, the command returns that level.
- If no dynamic change has been made since SSM started, it returns default.
Example:
```
SSM log level for application 'myApp': DEFAULT
```
or
```
SSM log level for application 'myApp': LOG_DEBUG
```
Out of scope
- Reporting the levels of individual class loggers (there can be hundreds of them).
- Dumping all logger states.
- Querying SIM or other daemons
The intention is to let an administrator verify the current ssm_all runtime log level without having to inspect the SSM logs.
Reply
Hide replies

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.

Please enter your email address

RELATED IDEAS

Protect switching SSM log levels from INFO to ALL more and add CLI to query current log levels

Proposed command

Expected behaviour

Out of scope