The SHOW TRACE FOR SESSION statement returns details about how CockroachDB executed a statement or series of statements recorded during a session. These details include messages and timing information from all nodes involved in the execution, providing visibility into the actions taken by CockroachDB across all of its software layers.
You can use SHOW TRACE FOR SESSION to debug why a query is not performing as expected, to add more information to bug reports, or to generally learn more about how CockroachDB works.
Statement traces can be obtained in plaintext, JSON, and Jaeger-compatible formats by activating statement diagnostics on the DB Console Statements Page or running EXPLAIN ANALYZE (DEBUG).
Usage overview
SHOW TRACE FOR SESSION returns messages and timing information for all statements recorded during a session. It's important to note the following:
SHOW TRACE FOR SESSIONonly returns the most recently recorded traces, or for a currently active recording of traces.- To start recording traces during a session, enable the
tracingsession variable viaSET tracing = on;. - To stop recording traces during a session, disable the
tracingsession variable viaSET tracing = off;.
- To start recording traces during a session, enable the
Recording traces during a session does not effect the execution of any statements traced. This means that errors encountered by statements during a recording are returned to clients. CockroachDB will automatically retry individual statements (considered implicit transactions) and multi-statement transactions sent as a single batch when retry errors are encountered due to contention. Also, clients will receive retry errors required to handle client-side retries. As a result, traces of all transaction retries will be captured during a recording.
Required privileges
For SHOW TRACE FOR SESSION, no privileges are required.
Syntax
Parameters
| Parameter | Description |
|---|---|
COMPACT |
If specified, fewer columns are returned by the statement. See Response for more details. |
KV |
If specified, the returned messages are restricted to those describing requests to and responses from the underlying key-value storage layer, including per-result-row messages. For SHOW KV TRACE FOR SESSION, per-result-row messages are included only if the session was/is recording with SET tracing = kv;. |
Trace description
CockroachDB's definition of a "trace" is a specialization of OpenTracing's definition. Internally, CockroachDB uses OpenTracing libraries for tracing, which also means that it can be easily integrated with OpenTracing-compatible trace collectors; for example, Jaeger, Lightstep, and Zipkin are already supported.
| Concept | Description |
|---|---|
| trace | Information about the sub-operations performed as part of a high-level operation (a query or a transaction). This information is internally represented as a tree of "spans", with a special "root span" representing a whole SQL transaction in the case of SHOW TRACE FOR SESSION. |
| span | A named, timed operation that describes a contiguous segment of work in a trace. Each span links to "child spans", representing sub-operations; their children would be sub-sub-operations of the grandparent span, etc. Different spans can represent (sub-)operations that executed either sequentially or in parallel with respect to each other. (This possibly-parallel nature of execution is one of the important things that a trace is supposed to describe.) The operations described by a trace may be distributed, that is, different spans may describe operations executed by different nodes. |
| message | A string with timing information. Each span can contain a list of these. They are produced by CockroachDB's logging infrastructure and are the same messages that can be found in node log files except that a trace contains message across all severity levels, whereas log files, by default, do not. Thus, a trace is much more verbose than logs but only contains messages produced in the context of one particular traced operation. |
To further clarify these concepts, let's look at a visualization of a trace for one statement. This particular trace is visualized by Jaeger. The image shows spans and log messages. You can see names of operations and sub-operations, along with parent-child relationships and timing information, and it's easy to see which operations are executed in parallel.
Response
SHOW TRACE FOR SESSION response may change in future versions.CockroachDB outputs traces in linear tabular format. Each result row represents either a span start (identified by the === SPAN START: <operation> === message) or a log message from a span. Rows are generally listed in their timestamp order (i.e., the order in which the events they represent occurred) with the exception that messages from child spans are interleaved in the parent span according to their timing. Messages from sibling spans, however, are not interleaved with respect to one another.
The following diagram shows the order in which messages from different spans would be interleaved in an example trace. Each box is a span; inner-boxes are child spans. The numbers indicate the order in which the log messages would appear in the virtual table.
+-----------------------+
| 1 |
| +-------------------+ |
| | 2 | |
| | +----+ | |
| | | | +----+ | |
| | | 3 | | 4 | | |
| | | | | | 5 | |
| | | | | | ++ | |
| | +----+ | | | |
| | +----+ | |
| | 6 | |
| +-------------------+ |
| 7 |
+-----------------------+
Each row contains the following columns:
| Column | Type | Description |
|---|---|---|
timestamp |
timestamptz | The absolute time when the message occurred. |
age |
interval | The age of the message relative to the beginning of the trace (i.e., the beginning of the statement execution in the case of SHOW TRACE FOR <stmt> and the beginning of the recording in the case of SHOW TRACE FOR SESSION. |
message |
string | The log message. |
tag |
string | Meta-information about the message's context. This is the same information that appears in the beginning of log file messages in between square brackets (e.g, [client=[::1]:49985,user=root,n1]). |
location |
string | The file:line location of the line of code that produced the message. Only some of the messages have this field set; it depends on specifically how the message was logged. The --vmodule flag passed to the node producing the message also affects what rows get this field populated. Generally, if --vmodule=<file>=<level> is specified, messages produced by that file will have the field populated. |
operation |
string | The name of the operation (or sub-operation) on whose behalf the message was logged. |
span |
int | The index of the span within the virtual list of all spans if they were ordered by the span's start time. |
COMPACT keyword was specified, only the age, message, tag and operation columns are returned. In addition, the value of the location columns is prepended to message.Examples
Trace a session
> SET tracing = on;
SET TRACING
> SHOW TRACE FOR SESSION;
timestamp | age | message | tag | location | operation | span
--------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------+--------------------------------------+-------------------+-------
2021-04-13 19:56:00.201326+00:00:00 | 00:00:00 | === SPAN START: session recording === | | | session recording | 0
2021-04-13 19:56:00.20135+00:00:00 | 00:00:00.000024 | === SPAN START: sync === | | | sync | 1
2021-04-13 19:56:00.2014+00:00:00 | 00:00:00.000074 | [NoTxn pos:13] executing Sync | [n1,client=127.0.0.1:61235,hostssl,user=root] | sql/conn_executor.go:1478 | sync | 1
2021-04-13 19:56:00.20153+00:00:00 | 00:00:00.000204 | === SPAN START: exec stmt === | | | exec stmt | 2
2021-04-13 19:56:00.201562+00:00:00 | 00:00:00.000236 | [NoTxn pos:14] executing ExecStmt: SHOW LAST QUERY STATISTICS | [n1,client=127.0.0.1:61235,hostssl,user=root] | sql/conn_executor.go:1478 | exec stmt | 2
2021-04-13 19:56:00.201583+00:00:00 | 00:00:00.000257 | executing: SHOW LAST QUERY STATISTICS in state: NoTxn | [n1,client=127.0.0.1:61235,hostssl,user=root] | sql/conn_executor_exec.go:75 | exec stmt | 2
...
(68 rows)
Trace conflicting transactions
In this example, we use two terminals concurrently to generate conflicting transactions.
In terminal 1, create a table:
> CREATE TABLE t (k INT);Still in terminal 1, open a transaction and perform a write without closing the transaction:
> BEGIN;> INSERT INTO t VALUES (1);Press enter one more time to send these statements to the server.
In terminal 2, turn tracing on:
> SET tracing = on;Still in terminal 2, execute a conflicting read:
> SELECT * FROM t;You'll see that this statement is blocked until the transaction in terminal 1 finishes.
Back in terminal 1, finish the transaction:
> COMMIT;In terminal 2, you'll see the completed read:
k +---+ 1 (1 row)Still in terminal 2, stop tracing and then view the completed trace:
> SET tracing = off;> SHOW TRACE FOR SESSION;timestamp | age | message | tag | location | operation | span --------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------+-----------------------------------------------------------+-----------------------------------+------- 2021-04-13 18:55:43.094235+00:00:00 | 00:00:00 | === SPAN START: session recording === | | | session recording | 0 2021-04-13 18:55:43.094244+00:00:00 | 00:00:00.000009 | === SPAN START: sync === | | | sync | 1 2021-04-13 18:55:43.094286+00:00:00 | 00:00:00.000051 | [NoTxn pos:43] executing Sync | [n1,client=127.0.0.1:60668,hostssl,user=root] | sql/conn_executor.go:1478 | sync | 1 2021-04-13 18:55:43.094436+00:00:00 | 00:00:00.000201 | === SPAN START: exec stmt === | | | exec stmt | 2 2021-04-13 18:55:43.094473+00:00:00 | 00:00:00.000238 | [NoTxn pos:44] executing ExecStmt: SHOW LAST QUERY STATISTICS | [n1,client=127.0.0.1:60668,hostssl,user=root] | sql/conn_executor.go:1478 | exec stmt | 2 2021-04-13 18:55:43.094486+00:00:00 | 00:00:00.000251 | executing: SHOW LAST QUERY STATISTICS in state: NoTxn | [n1,client=127.0.0.1:60668,hostssl,user=root] | sql/conn_executor_exec.go:75 | exec stmt | 2 2021-04-13 18:55:43.094497+00:00:00 | 00:00:00.000262 | === SPAN START: sync === | | | sync | 3 ... (200 rows)
See also
Was this helpful?
