|
| 1 | +# Tracing |
| 2 | + |
| 3 | +Tracing can be used to troubleshoot query performance problems and can be |
| 4 | +enabled per request. When enabled, it provides detailed request information |
| 5 | +related to internal, server-side operations. Those operations are stored in |
| 6 | +tables under the `system_traces` keyspace. |
| 7 | + |
| 8 | +## Enabling |
| 9 | + |
| 10 | +Tracing can be enabled per request for both statements (`CassStatement`) and |
| 11 | +batches (`CassBatch`). |
| 12 | + |
| 13 | +### Enable Tracing on a Statement (`CassStatement`) |
| 14 | + |
| 15 | +```c |
| 16 | +const char* query = "SELECT * FROM keyspace1.table1"; |
| 17 | +CassStatement* statement = cass_statement_new(query, 0); |
| 18 | + |
| 19 | +/* Enable tracing on the statement */ |
| 20 | +cass_statement_set_tracing(statement, cass_true) |
| 21 | + |
| 22 | +/* ... */ |
| 23 | +``` |
| 24 | +
|
| 25 | +### Enable Tracing on a Batch (`CassBatch`) |
| 26 | +
|
| 27 | +``` |
| 28 | +CassBatch* batch = cass_batch_new(CASS_BATCH_TYPE_UNLOGGED); |
| 29 | + |
| 30 | +/* Enable tracing on the batch */ |
| 31 | +cass_batch_set_tracing(batch, cass_true) |
| 32 | + |
| 33 | +/* ... */ |
| 34 | +``` |
| 35 | +
|
| 36 | +## Tracing Identifier |
| 37 | +
|
| 38 | +When tracing is enabled, a request's future (`CassFuture`) will provide a unique |
| 39 | +tracing identifier. This tracing identifier can be used by an application to |
| 40 | +query tables in the `system_traces` keyspace. |
| 41 | +
|
| 42 | +```c |
| 43 | +CassUuid tracing_id; |
| 44 | +if (cass_future_tracing_id(future, &tracing_id) == CASS_OK) { |
| 45 | + /* Use `tracing_id` to query tables in the `system_trace` keyspace */ |
| 46 | +} else { |
| 47 | + /* Handle error. If this happens then either a request error occurred or the |
| 48 | + * request type for the future does not support tracing. |
| 49 | + */ |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +**Note**: The driver does not return the actual tracing data for the request. The |
| 54 | +application itself must use the returned tracing identifier to query the tables. |
| 55 | + |
| 56 | +## Configuration |
| 57 | + |
| 58 | +By default, when tracing is enabled, the driver will wait for the query's tracing |
| 59 | +data to become available in the server-side tables before setting the request's |
| 60 | +future. The amount of time it will wait, retry, and the consistency level of the |
| 61 | +tracing data can be controls by setting `CassCluster` configuration options. |
| 62 | + |
| 63 | +```c |
| 64 | +CassCluster* cluster = cass_cluster_new(); |
| 65 | + |
| 66 | +/* Wait a maximum of 15 milliseconds for tracing data to become available */ |
| 67 | +cass_cluster_set_tracing_max_wait_time(cluster, 15); |
| 68 | + |
| 69 | +/* Wait 3 milliseconds before rechecking for the tracing data */ |
| 70 | +cass_cluster_set_tracing_retry_wait_time(cluster, 3); |
| 71 | + |
| 72 | +/* Check the tracing data tables using consistency level ONE */ |
| 73 | +cass_cluster_set_tracing_consistency(cluster, CASS_CONSISTENCY_ONE); |
| 74 | + |
| 75 | +/* ... */ |
| 76 | +``` |
0 commit comments