API requests not captured in the Edge UI

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

Symptom

The following image shows API requests are not captured in the Edge UI when a trace session is started:

Error Message

No error messages will be displayed in the Edge UI when this problem occurs.

Possible Causes

The following table shows possible causes for a failure to capture API requests in Edge UI Trace:

Cause	Description	Troubleshooting Instructions Applicable For
Requests not processed by the Message Processor	API requests must be processed by Edge's component Message Processor in order to capture trace. If an API request fails to reach Apigee Edge, fails at the entry point to Edge (i.e., Router) or fails before it is processed by the Message Processor, then the trace cannot be captured.	Edge Public and Private Cloud Users
API Proxy Not Found in The Classification Tree	Apigee Message Processors use a Routing Rule definition called Classification Tree for dispatching requests based on the hostname, base path, revision, and environment of the incoming request. If the relevant API proxy is removed for some reason from the Classification Tree, the Trace transactions may not populate.	Edge Private Cloud Users

Cause: Requests not processed by the Message Processor

Diagnosis

To capture an API request in a Trace session, the API request must be processed by Edge's component Message Processor. There are several reasons why an API request may not be captured in a Trace transaction.

For example, if an API request fails to reach Apigee Edge, fails at the entry point to Edge (i.e., Router) or fails before it gets processed by the Message Processor, then the trace cannot be captured. Each of these scenarios is outlined in greater detail below.

Scenario 1: Requests fail to reach Apigee Edge

Cause

In this scenario, the error may be caused by a DNS resolution or network connectivity issue. If so, you may see the following error when running this command:
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
Resolution

You can verify DNS configuration with the following command:
```
dig hostName
```
You can verify network connectivity with the following command:
```
telnet hostName port
```

Scenario 2: Requests fail at the Apigee Edge Router

Cause

In this scenario, the error may be caused by a TLS/SSL handshake failure. If so, you may see one of the following errors:
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
You may also see an SSL certificate error.
Resolution

Refer to the following playbooks to troubleshoot and resolve these issues:

TLS/SSL Handshake Failures

400 Bad Request - SSL Certificate Error

Scenario 3: Requests cannot be processed by Message Processor

Cause

In this scenario, the Apigee Message Processor cannot find the API Proxy for the specified virtual host and path. As a result, you may see one of the following errors:

HTTP/1.1 404 Not Found

{
  "fault":{
    "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
    "detail":{
      "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
    }
  }
}

Resolution

Refer to this playbook to troubleshoot and resolve this issue: 404 Unable to identify proxy for host.

Cause: API Proxy Not Found in The Classification Tree

Diagnosis

If a Message Processor cannot find an API proxy in its Classification Tree, then any API requests to that specific proxy will not be shown in Trace sessions in the Edge UI.

Follow the steps below to determine if this is the case:

Log in to each of the Message Processors and check to see if the specific revision of the requested API is deployed in the relevant environment of the Message Processor using the following command:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Example Output:

The command above will output a list of deployed revisions. For example, if revision 12 is deployed then you will see the following output:
```
[ "12" ]
```
Unless you are encountering intermittent HTTP 404 errors, you are likely to see that the specific revision is deployed.
Read the Classification Tree and check for the existence of the API proxy name using the following command:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Repeat Steps 1 and 2 for each Message Processor. If the given API proxy name is missing from the Classification Tree of any of the Message Processors, then follow the resolution given below.

Resolution

Please follow the steps below to resolve this issue. Make sure to take any precautions necessary to avoid production outages that may occur from restarting Message Processors while experiencing high request loads.

Log in to each of the Message Processor hosts that are missing the specific API proxy in the Classification Tree and use the command below to restart the Message Processor:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Once restarted, use the command below to wait until it becomes active:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready

Once the Message Processor is ready, verify the availability of the API proxy using the following command:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Example Output:

The command above will output a list of deployed revisions. For example, if revision 12 is deployed then you will see the following output:
```
[ "12" ]
```
Unless you are encountering intermittent HTTP 404 errors, you are likely to see that the specific revision is deployed.
Read the Classification Tree and verify the existence of the API proxy name using the following command:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
If the problem still persists, go to Must Gather Diagnostic Information.

Must Gather Diagnostic Information

If the problem persists after following the instructions above, please gather the following diagnostic information and share it with Apigee Edge Support:

Diagnostic Information Type	Command
Output of trace session command	curl -v `management-server-host`:8080/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiProxyName`/revisions/`revisionNumber`/debugsessions -u `user`
Management Server log	/opt/apigee/var/log/edge-management-server/logs/system.log
Message Processor logs	/opt/apigee/var/log/edge-message-processor/logs/system.log
Output of `telnet`/`netcat` commands from Management Server to Message Processor	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
Output of netstat command on the Message Processor(s)	netstat -an > netstat.txt
Output listing revisions deployed for the specific API Proxy on all Message Processor(s)	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
Classification Tree output on all Message Processor(s)	curl -i http://localhost:8082/v1/classification/tree