Troubleshooting API ML
Troubleshooting API ML
As an API Mediation Layer user, you may encounter problems with how the API ML functions. This article presents known API ML issues and their solutions.
#
Enable API ML Debug ModeUse debug mode to activate the following functions:
- Display additional debug messages for API ML
- Enable changing log level for individual code components
Important: We highly recommend that you enable debug mode only when you want to troubleshoot issues. Disable debug mode when you are not troubleshooting. Running in debug mode while operating API ML can adversely affect its performance and create large log files that consume a large volume of disk space.
Follow these steps:
Open the file
<Zowe install directory>/components/api-mediation/bin/start.sh
.Find the API Mediation Layer service, for which you want to enable the debug mode: discovery, catalog, or gateway.
Find the line that contains the
LOG_LEVEL=
parameter and set the value todebug
:LOG_LEVEL=debug
Restart Zowe™.
You have enabled the debug mode.
(Optional) Reproduce a bug that causes issues and review debug messages. If you are unable to resolve the issue, create an issue here.
Disable the debug mode. Find the
LOG_LEVEL
parameter, and change its current value to the defaultLOG_LEVEL=
one:LOG_LEVEL=
Restart Zowe.
You have disabled the debug mode.
#
Change the Log Level of Individual Code ComponentsYou can change the log level of a particular code component of the API ML internal service at run time.
Follow these steps:
Enable API ML Debug Mode as described in Enable API ML Debug Mode. This activates the application/loggers endpoints in each API ML internal service (Gateway, Discovery Service, and Catalog).
List the available loggers of a service by issuing the GET request for the given service URL:
GET scheme://hostname:port/application/loggers
Where:
scheme
API ML service scheme (http or https)
hostname
API ML service hostname
port
TCP port where API ML service listens on. The port is defined by the configuration parameter MFS_GW_PORT for the Gateway,
MFS_DS_PORT for the Discovery Service (by default, set to gateway port + 1), and MFS_AC_PORT for the Catalog (by default, set to gateway port + 2).
Exception: For the catalog you will able to get list the available loggers by issuing the GET request for the given service URL:
GET [gateway-scheme]://[gateway-hostname]:[gateway-port]/api/v1/apicatalog/application/loggers
Tip: One way to issue REST calls is to use the http command in the free HTTPie tool: https://httpie.org/.
Example:
HTTPie command:http GET https://lpar.ca.com:10000/application/loggers Output:{"levels":["OFF","ERROR","WARN","INFO","DEBUG","TRACE"], "loggers":{ "ROOT":{"configuredLevel":"INFO","effectiveLevel":"INFO"}, "com":{"configuredLevel":null,"effectiveLevel":"INFO"}, "com.ca":{"configuredLevel":null,"effectiveLevel":"INFO"}, ... }}
Alternatively, you extract the configuration of a specific logger using the extended GET request:
GET scheme://hostname:port/application/loggers/{name}
Where:
{name}
is the logger name
Change the log level of the given component of the API ML internal service. Use the POST request for the given service URL:
POST scheme://hostname:port/application/loggers/{name}
The POST request requires a new log level parameter value that is provided in the request body:
{ "configuredLevel": "level" }
Where:
level
is the new log level: OFF, ERROR, WARN, INFO, DEBUG, TRACE
Example:
http POST https://hostname:port/application/loggers/org.zowe.apiml.enable.model configuredLevel=WARN
#
Known Issues#
API ML stops accepting connections after z/OS TCP/IP stack is recycledSymptom:
When z/OS TCP/IP stack is restarted, it is possible that the internal services of API Mediation Layer (Gateway, Catalog, and Discovery Service) stop accepting all incoming connections, go into a continuous loop, and write a numerous error messages in the log.
Sample message:
The following message is a typical error message displayed in STDOUT:
2018-Sep-12 12:17:22.850. org.apache.tomcat.util.net.NioEndpoint -- Socket accept failed java.io.IOException: EDC5122I Input/output error.
.at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~.na:1.8.0..at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:478) ~.na:1.8.0..at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:287) ~.na:1.8.0..at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:455) ~.tomcat-coyote-8.5.29.jar!/:8.5.29..at java.lang.Thread.run(Thread.java:811) .na:2.9 (12-15-2017).
Solution:
Restart API Mediation Layer.
Tip: To prevent this issue from occurring, it is strongly recommended not to restart the TCP/IP stack while API ML is running.
#
SEC0002 error when logging in to API CatalogSEC0002 error typically appears when users fail to log in to API Catalog. The following image shows the API Catalog login page with the SEC0002 error.
The error is caused by failed z/OSMF authentication. To determine the reason authentication failed, open the ZWESVSTC joblog and look for a message that contains ZosmfAuthenticationProvider
. The following is an example of the message that contains ZosmfAuthenticationProvider
:
2019-08-05 11:25:03.431 ERROR 5 --- .0.0-7552-exec-3. c.c.m.s.l.ZosmfAuthenticationProvider : Can not access z/OSMF service. Uri 'https://ABC12.slv.broadcom.net:1443' returned: I/O error on GET request for "https://ABC12.slv.broadcom.net:1443/zosmf/info": ...
Check the rest of the message, and identify the cause of the problem. The following list provides the possible reasons and solutions for the z/OSMF authentication issue:
- Connection refused
- Missing z/OSMF host name in subject alternative names
- Invalid z/OSMF host name in subject alternative names
#
Connection refusedIn the following message, failure to connect to API Catalog occurs when connection is refused:
Connect to ABC12.slv.broadcom.net:1443 .ABC12.slv.broadcom.net/127.0.0.1. failed: EDC8128I Connection refused.; nested exception is org.apache.http.conn.HttpHostConnectException:
The reason for the refused connection message is either invalid z/OSMF configuration or z/OSMF being unavailable. The preceding message indicates that z/OSMF is not on the 127.0.0.1:1443 interface.
Solution:
#
Configure z/OSMFMake sure that z/OSMF is running and is on 127.0.0.1:1443 interface, and try to log in to API Catalog again. If you get the same error message, change z/OSMF configuration.
Follow these steps:
Locate the z/OSMF PARMLIB member IZUPRMxx.
For example, locate IZUPRM00 member in SYS1.PARMLIB.
Change the current
HOSTNAME
configuration toHOSTNAME('*')
.Change the current
HTTP_SSL_PORT
configuration toHTTP_SSL_PORT('1443')
.Important! If you change the port in the z/OSMF configuration file, all your applications lose connection to z/OSMF.
For more information, see Syntax rules for IZUPRMxx.
If changing the z/OSMF configuration does not fix the issue, reconfigure Zowe.
Follow these steps:
- Open
.zowe_profile
in the home directory of the user who installed Zowe. - Modify the value of the
ZOWE_ZOSMF_PORT
variable. - Reinstall Zowe.
#
Missing z/OSMF host name in subject alternative namesIn following message, failure to connect to API Catalog is caused by a missing z/OSMF host name in the subject alternative names:
Certificate for <ABC12.slv.broadcom.net> doesn't match any of the subject alternative names: ..; nested exception is javax.net.ssl.SSLPeerUnverifiedException: Certificate for <ABC12.slv.broadcom.net> doesn't match any of the subject alternative names: ..
Solutions:
Fix the missing z/OSMF host name in subject alternative names using the following methods:
Note: Apply the insecure fix only if you use API Catalog for testing purposes.
#
Secure fixFollow these steps:
Obtain a valid certificate for z/OSMF and place it in the z/OSMF keyring. For more information, see Configure the z/OSMF Keyring and Certificate.
Navigate to
$ZOWE_RUNTIME
and run the following command:bin/apiml_cm.sh --action trust-zosmf
2a. (Optional) If you do not use the default z/OSMF userid (IZUSVR) and keyring (IZUKeyring.IZUDFLT), issue the following command:
bin/apiml_cm.sh --action trust-zosmf--zosmf-userid ZOSMF_USER --zosmf-keyring ZOSMF_KEYRING
where;
--zosmf-keyring
and--zosmf-userid
- options that override the default userid and keyring accordingly.
#
Insecure fixFollow these steps:
- Set the value of the
VERIFY_CERTIFICATES
property tofalse
in$ZOWE_RUNTIME/scripts/internal/run-zowe.sh
to disable verification of certificates in Zowe. - Reinstall Zowe.
#
Invalid z/OSMF host name in subject alternative namesIn the following message, failure to connect to API Catalog is caused by an invalid z/OSMF host name in the subject alternative names:
Certificate for <ABC12.slv.broadcom.net> doesn't match any of the subject alternative names: [abc12.ca.com, abc12, localhost, abc12-slck, abc12-slck.ca.com, abc12-slck1, abc12-slck1.ca.com, abc12-slck2, abc12-slck2.ca.com, usilabc12, usilabc12.ca.com]; nested exception is javax.net.ssl.SSLPeerUnverifiedException: Certificate for <ABC12.slv.broadcom.net> doesn't match any of the subject alternative names: [abc12.ca.com, abc12, localhost, abc12-slck, abc12-slck.ca.com, abc12-slck1, abc12-slck1.ca.com, abc12-slck2, abc12-slck2.ca.com, usilabc12, usilabc12.ca.com]
Solutions:
Fix the invalid z/OSMF host name in the subject alternative names using the following methods:
#
Request a new certificateRequest a new certificate that contains a valid z/OSMF host name in the subject alternative names.
#
Change the ZOWE_EXPLORER_HOST variableChange ZOWE_EXPLORER_HOST
variable to fix the issue.
Follow these steps:
- Open .zowe_profile in the home directory of the user who installed Zowe.
- Change
ZOWE_EXPLORER_HOST
to a host name from the subject alternative names of the z/OSMF certificate. For example, issue the following command:export ZOWE_EXPLORER_HOST=SAN (change this to the correct one > in the code block).
- Reinstall Zowe.