The content of the request log file varies slightly, depending upon whether it is treating Presentation API queries or Web services invocations.
Note
If a field is not relevant to the query in question, the request log entry for that query contains a dash (-) in that location.
Each entry has the following 14 columns:
[Timestamp] [Client IP Address] [HTTP Exchange ID] [Response Size] [Total Request Time] [Total Processing Time] [HTTP Return Code] [Number of Results] [Queue Status] [Thread ID] [Query String] [Query Body] [HTTP Headers]
These entries are listed in the order of the timestamp. Because of this, the entries are listed in the response order, not in the request order. The following table describes the log entries in more detail:
|
Column |
Presentation API Queries or Web Services Invocations |
Description |
|---|---|---|
|
Timestamp |
Both |
Time stamp indicating the time the request was completed, in milliseconds, since the epoch (January 1, 1970, 00:00:00 UTC). For example: 1208947882000=2008-04-23 10:51:22 AM GMT The time is recorded in GMT (not the localized time of the server). You can convert it using a UTC epoch converter utility, such as UTC. |
|
Client IP |
Both |
IP address of the requesting client. |
|
HTTP Exchange ID |
Both |
Unique query identifier. This identifier allows you to correlate Dgraph request log items with error messages in the Dgraph log. In addition, it is used by the MDEX Server Statistics page to compose most expensive query statistics.
NoteThe identifier is only unique within a single Dgraph instance, and is not persistent across Dgraph shutdown.
|
|
Response Size |
Both |
Number of bytes written to the client. May be less than or equal to the intended result size, for example, due to a premature session end. |
|
Total Request Time |
Both |
The request lifetime, in milliseconds. Equal to the total amount of time between when the Dgraph reads the request from the network and finishes sending the result. May include queuing time, such as time spent waiting for earlier requests to be completed. NoteIn previous releases, the request lifetime ended when the connection was closed. If connection close did not time out, this lifetime would include the time to transport the response to the client, and the time for the client to read the response. Starting with 6.1.0, the request lifetime ends when the response has been successfully delivered to the socket layer.
|
|
Total Processing Time |
Both |
Processing time, in milliseconds. Equal to the total computation time required for the Dgraph to handle the request, excluding network and wait time. This value gives an accurate measure of how expensive the request was to compute, given current system state. (That is, if the machine in question was busy with other threads or processes, the time may be longer than on an otherwise unused machine.) For any given query, Processing Time is always smaller than Total Request Time. |
|
HTTP Status Code |
Both |
The HTTP return code. A status code of 200 (OK) is returned if the request was successful. For details on other codes that can appear in this field, see the table below. |
|
Number of Results |
Presentation API Queries |
Number of results from your query (or "
NoteThis number reflects the number of results, not necessarily
the number of results returned. That is, this is the number of results from
your query, not accounting for your
|
|
Queue Status |
Both |
The number of queries in the queue that have not started processing yet. The number is calculated before the current query is enqueued, and therefore the current query is not included.
NoteStarting with the MDEX Engine version 6.1.2, this column
does not report the number of query threads that are idle because there is no
longer a one-to-one relationship between threads and queries. Specifically,
when you specify the
|
|
Thread ID |
Both |
The thread ID of the thread that was assigned
the request (or “ |
|
Query String |
Both |
The URL of the Presentation API query or of the Web service. |
|
Query Body |
Web Services Invocations |
The URL-encoded POST body of the query. The actual entry in the request log is a single token, even though POST body can contain multiple lines of text. Logging information includes the session ID (sid), request ID (rid), customized log entries, and the request component (reqcom). The request component is the class that made the MDEX Engine query. |
|
HTTP Headers |
Both |
The URL-encoded HTTP headers that were sent with the query. The actual entry in the request log is a single token, even though HTTP headers can contain multiple lines of text. |
Related links
