Trace within Zowe is a bit confusing. Different components, such as Gateway and Application-Server seems to have different ways of tracing.

As I understand it, you set a global switch for a components trace, restart Zowe, then use a REST API to set or reset subcomponents.

It took me a day or so to be able to change the trace of Zowe components!

There is Zowe documentation on Troubleshooting Zowe API Mediation Layer. Which is incomplete, and missing useful documentation.

The syntax of the logging commands is here

List the existing traces

The documentation says

GET scheme://hostname:port/application/loggers

This didn’t work for me because I was using port 7554. After I tried all of the Zowe ports, the following worked

"https://10.1.1.2:7558/application/loggers"

Where 7558 is the port for zaas.

This returned one long string, with many logical lines of output. For example:

{
    "levels": [
        "OFF",
        "ERROR",
        "WARN",
        "INFO",
        "DEBUG",
        "TRACE"
    ],
    "loggers": {
        "ROOT": {
            "configuredLevel": "INFO",
            "effectiveLevel": "INFO"
        },
        "_org": {
            "configuredLevel": null,
            "effectiveLevel": "INFO"
        },
        "_org.springframework": {
            "configuredLevel": null,
            "effectiveLevel": "INFO"
        },
...
       
    },
    "groups": {
        "web": {
            "configuredLevel": null,
            "members": [
                "org.springframework.core.codec",
                "org.springframework.http",
                "org.springframework.web",
                "org.springframework.boot.actuate.endpoint.web",
                "org.springframework.boot.web.servlet.ServletContextInitializerBeans"
            ]
        },
        "sql": {
            "configuredLevel": null,
            "members": [
                "org.springframework.jdbc.core",
                "org.hibernate.SQL",
                "org.jooq.tools.LoggerListener"
            ]
        }
    }
}

• 434 lines for org.springframework….
• 36 lines for com.netflix….
• 286 line for io….
• 63 lines for org.apache…
• 57 lines for org.hibernate
• 68 lines for org.ehcache
• 109 lines for org.zowe.apiml.

Selecting one record type

I used a Bash script

#!/bin/bash 
url="https://10.1.1.2:7558/application/loggers/org.zowe.apiml.zaas.security"
certs="--cert colinpaice.pem --cert-key colinpaice.key.pem"
verify="--verify no"
https GET ${url} $certs  $verify

gave

{
    "configuredLevel": "null",
    "effectiveLevel": "DEBUG"
}

This means org.zowe.apiml.zaas.security was configured as null, but one of org.zowe, org.zowe.apiml, or org.zowe.apiml.zaas was set to DEBUG, and all of the definitions below it were set to DEBUG.

If I set the value of org.zowe.apiml.zaas.security to WARN, then set the value of org.zowe.apiml.zaas to DEBUG, the value of org.zowe.apiml.zaas.security stayed at WARN.

{
    "configuredLevel": "WARN",
    "effectiveLevel": "WARN"
} 

Updating a value

It took me a while to get a script to update the value.

url="https://10.1.1.2:7558/application/loggers/org.zowe.apiml.zaas.security"
certs="--cert colinpaice.pem --cert-key colinpaice.key.pem"
verify="--verify no"
echo -n '{"configuredLevel": "WARN"}'  |  https POST ${url}  $certs  $verify
echo "================="
https GET ${url} $certs  $verify

This pipes the update {“configuredLevel”: “WARN”} into the https command. This returned no data. If it fails it may return a message.

Changing the hierarchy

Logically changing a value for a.b.c to ZZZZ works as follows

for every element under a.b.c
   if the element's value is null 
   then set element's value = ZZZZ
   else do nothing