This documentation is for WSO2 Enterprise Service Bus version 4.8.1 . View documentation for the latest release.

All docs This doc

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 <ESB_HOME>/bin/ directory) and set it to true.

    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/CentOSsh wso2server.sh -DenableCorrelationLogs=true
    On Windowswso2server.bat -DenableCorrelationLogs=true

Now when you start the ESB server, the correlation.log file is created in the <ESB_HOME>/repository/logs/ directory.

...

The detail recorded in a log entry is described below.

Time Stamp

The time at which the log is created.

Code Block
titleExample
2018-11-30 15:27:27,269
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.

Code Block
titleExample
correlationID
Thread name

The identifier of the thread.

Code Block
titleExample
HTTP-Listener I/O dispatcher-5
Duration

The duration (given in milliseconds) depends on the type of log entry:

  • If the state in the log entry is ROUND-TRIP LATENCY, the duration corresponds to the total time duration since the incoming message was received by the ESB until the response message is sent back to the client.
  • If the state in the log entry is BACKEND LATENCY, the duration corresponds to the total time taken by the backend to process the message.
  • For all other log entries, the duration corresponds to the time gap between the current log entry and the immediately previous log entry. That is, the time taken for the HTTP request to move from one state to another.
Code Block
titleExample
7
Call type

There are two possible call types:

  • HTTP call type identifies logs that correspond to either BACKEND LATENCY or ROUND-TRIP LATENCY states. That is, in the case of an individual request, one log will be recorded to identify back-end latency, and another log for round-trip latency. Since these two logs relate to HTTP calls between the ESB and external clients, they are categorized using the HTTP call type.
  • HTTP State Transition call type identifies logs that correspond to the state transitions in the HTTP transport related to a particular message.
Connection name

This is a name that is generated to identify the connection between the ESB and the external client.

Code Block
titleExample
http-incoming-17
Method type

The HTTP method used for the request.

Code Block
titleExample
POST

Anchor
connection_URL
connection_URL
Connection URL

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.

Code Block
titleExample
/healthcare/categories/surgery/reserve
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.

  • REQUEST_HEAD: All HTTP headers in the incoming request are being read/ or being written to the backend.
  • REQUEST_BODY: The body of the incoming request is being read/ or being written to the backend.
  • REQUEST_DONE: The request is completely read (content decoded)/ or is completely written to the backend.
  • BACKEND LATENCY: The response message is received by the ESB. This status corresponds to the total time taken by the backend to process the message.
  • RESPONSE_HEAD: All HTTP headers in the response message are being read/ or being written to the client.
  • RESPONSE_BODY: The body of the response message is being read/ or being written to the client.
  • RESPONSE_DONE: The response is completely read/ or completely written to the client.
  • ROUND-TRIP LATENCY: The response message is completely written to the client. This status corresponds to the total time taken by the HTTP request to compete the round trip (from the point of receiving the HTTP request from a client until the response message is sent back to the client).