API Traffic Tab
In the API Traffic tab, the message traffic of the API Proxy can be viewed and filtered, and log records of each message can be examined.
Each of the log records shown in the table belongs to a request coming from a client to this API Proxy and the response message given to that request. The following operations can be performed on this message.
Since WebSocket and gRPC requests are kept as data coming to and going from Apinizer, there are only 2 areas in these types of API Proxies.
Routing Address
This field holds the address information where the relevant API Proxy is routed. If this field is empty, it indicates that the request did not go to the backend address.
Services using Apinizer as backend are shown with the "apinizer://" prefix, it will write exactly "apinizer://<COMPONENT_NAME>/<METHOD_NAME>".
This also applies to proxies where routing is closed to prevent going to backend.
Possible values are;
| Routing Address | Condition |
|---|---|
apinizer://mirror.routing/<METOT_ADI> | API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy or No-Spec API and Routing option is closed and Mirror option is open |
apinizer://specresponse.routing/<METOT_ADI> | API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy or No-Spec API and Routing option is closed and Mirror option is closed |
apinizer://db2api.apicreator/<METOT_ADI> | API Proxy type DB2API |
apinizer://script2api.apicreator/<METOT_ADI> | API Proxy type Script2API |
apinizer://mockapi.apicreator/<METOT_ADI> | API Proxy type Mock API |
apinizer://connector/<METOT_ADI> | API Proxy type Connector |
apinizer://maintenance | API Proxy in maintenance mode |
apinizer://cache/<METOT_ADI> | In any API Proxy type and Caching is open |
http://<BACKEND_ADRESİ>/<METOT_ADI> or https://<BACKEND_ADRESİ>/<METOT_ADI> | API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy, No-Spec API or KPS and Routing option is open |
apinizer://spec | API Proxy type Swagger 2.x, OpenAPI/Swagger 3.0.x, WSDL, Reverse Proxy, No-Spec API and access to spec address |
| (Empty) | Request cannot go to backend address for various reasons |
Filtering
Search can be performed in 2 different types (Basic, Advanced) with the More options option
In the Basic tab, filtering is applied to records with determined criteria such as a specific time range, endpoint, or HTTP method.
In the Advanced tab, users can create nested filters.
Search can be performed with the following options in the Advanced tab.
Detailed View
The first one in the menu at the end of the row of the request message to be examined opens a window displaying the log records of that message.
In the window that opens, it is seen that logs are divided into sections related to message flow. When the name of the section to be examined (for example, the Request From Client to API Proxy section) is clicked, log records related to this area are displayed. By default, the Overview section is open.
Routing Diagnostics
If a request to the backend has routing diagnostic signals, a Routing Diagnostics section is shown in the Detailed View window.
This section is only shown for requests that go to the backend; requests served from cache or that never reach the backend (mock, maintenance mode, etc.) do not show this section.
| Field | Description |
|---|---|
| Failure Reason | If the request failed, the classified failure reason (Pool Timeout, Connect Timeout, DNS Failure, TLS Handshake Failure, Read Timeout, Backend/Client Closed, No Healthy Upstream, Circuit Open, Retries Exhausted, Upstream HTTP Error, Unknown) |
| Confidence | The reliability level of the classification (High/Medium/Low) |
| Probable Cause | An automatically generated explanation based on the failure reason |
| Exception | If present, the exception class and detail that caused the failure |
| Recommended Action | A suggestion generated from the available signals to help resolve the issue |
| Phase Timing | The duration (ms) of each of: selection, DNS, TCP connect, TLS handshake, time to first byte (TTFB), body read, and pool wait |
| Upstream Status (raw) | The raw HTTP status code returned by the backend (may differ from the code returned to the client, e.g. if a policy changed it) |
| Upstream IP:Port | The backend address the request was actually sent to |
| Connection Reused | Whether the connection was reused from the pool |
| Response Reached (TTFB) | Whether at least one byte of the response was received from the backend |
| Gateway Worker | The Worker pod/host that processed the request |
| Client Write (ms) | Time spent writing the response to the client |
| Pool | The connection pool's instantaneous state: leased, pending, available, and maximum connection counts |
| Configured Timeouts | The connect, read, and pool-lease (connection-request) timeout values (ms) configured for the API Proxy |
Combined with the timeout and connection pool settings configured on the Routing tab, this information helps you quickly pinpoint the root cause of a routing problem. For an aggregate routing diagnostics summary for this API Proxy, see the Analytics tab.
JSON View
The button below the Detailed View button displays log records in JSON format.
The visual containing the dialog opened when JSON View is clicked is shown below:
Key values in this field are written in a readable format, not as they are in the log file, to facilitate reading.
For example, the "apiProxyId" value is kept as "api" in the log record, when the log record is downloaded, the actual log record will be displayed.
For the actual log file format, you can examine the "Template Data Structure Table" on the Elasticsearch Manual ILM Policy and Template Creation page.
Download
It is also possible to download log records for more detailed examination.
Quick Test
The Quick Test button on the relevant row opens the Test Console formatted so that the sent request can be tested immediately by resending it.
"Quick Test" button must be enabled in general settings to be visible.