Product observability enables rapid debugging of product issues. The ESB profile of WSO2 Enterprise Integrator (WSO2 EI) enables observability using correlation logs. Correlation logs allow you to monitor individual HTTP requests from the point that a message is received by the ESB until the corresponding response message is sent back to the original message sender. That is, the complete round trip of an HTTP message (client → ESB → back-end → ESB → client) can be tracked and anlyzed using a log file.
When correlation logs are enabled for the ESB server, a separate log file named correlation.log is created in the <EI_HOME>/repository/logs/ directory. Every HTTP message that flows through the ESB and between the ESB and external clients undergoes several state changes. A new log entry is created in the correlation.log file corresponding to the state changes in the round trip of a single HTTP request. A correlation ID assigned to the incoming HTTP request is assigned to all the log entries corresponding to the request. Therefore, you can use this correlation ID to easily locate the logs relevant to the round trip of a specific HTTP request and, thereby, analyze the behaviour of the message flow.
| Note | ||
|---|---|---|
To use this feature in the current version of WSO2 EI, you need to get the latest product updates for your product. This feature is available as a product update from 2018-11-24 onwards.
|
...
If you want correlation logs to be enabled every time the server starts, add the following system property to the product start-up script (stored in the
<EI_HOME>/bin/directory) and set it totrue.Code Block -DenableCorrelationLogs=true \
Alternatively, you can pass the system property at the time of starting the server by executing the following command:
On Linux/MacOS/CentOS sh integrator.sh-DenableCorrelationLogs=trueOn Windows integrator.bat-DenableCorrelationLogs=true
Now when you start the ESB server, the correlation.log file is created in the <EI_HOME>/repository/logs/ directory.
...
| Time Stamp | The time at which the log is created.
| |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Correlation ID | Each log contains a correlation ID, which is unique to the HTTP request. A client can send the correlation ID in the header of the HTTP request. If this correlation ID is missing in the incoming request, the ESB will generate one for the request. The HTTP header that carries the correlation ID is configured in the ESB.
| |||||||||||
| Thread name | The identifier of the thread.
| |||||||||||
| Duration | The duration (given in milliseconds) depends on the type of log entry:
| |||||||||||
| Call type | There are two possible call types:
| |||||||||||
| Connection name | This is a name that is generated to identify the connection between the ESB and the external client.
| |||||||||||
| Method type | The HTTP method used for the request.
| |||||||||||
| The connection URL of the external client with which the message is being communicated. For example, if the message is being read from the client, the connection URL corresponds to the client sending the message. However, if the message is being written to the backend, the URL corresponds to the backend client.
| |||||||||||
| HTTP state | Listed below are the state changes that a message goes through when it flows through the ESB, and when the message flows between the ESB and external clients. Typically, a new log entry is generated for each of the states. However, there can be two separate log entries created for one particular state (except for BACKEND LATENCY and ROUND-TRIP LATENCY) depending on whether the message is being read (from the sender) or written (to the backend). You can identify the two separate log entries from the connection URL explained above.
|