Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Admin UI Statements page - Reference doc #3300

Merged
merged 6 commits into from
Jun 28, 2018
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions _includes/sidebar-data-v2.1.json
Original file line number Diff line number Diff line change
Expand Up @@ -1485,6 +1485,12 @@
"/${VERSION}/admin-ui-jobs-page.html"
]
},
{
"title": "Statements Page",
"urls": [
"/${VERSION}/admin-ui-statements-page.html"
]
},
{
"title": "Custom Chart Debug Page",
"urls": [
Expand Down
110 changes: 110 additions & 0 deletions v2.1/admin-ui-statements-page.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
---
title: Statements Page
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a summary: field to the front-matter. That's used as the page's meta description for SEO.

toc: false
---

The **Statements** page helps you identify the frequently executed or high latency [SQL statements](sql-statements.html). The **Statements** page also allows you to drill down to the details of an individual SQL statement by clicking on the statement to view the **Statement Details** page.

To view the **Statements** page, open [http://localhost:8080/#/statements](http://localhost:8080/#/statements) in your browser (replacing `localhost` and `8080` with your node's host and port).

<div id="toc"></div>

{{site.data.alerts.callout_danger}}
**This feature is a work in progress**. It will change leading up to the v2.1 release.
{{site.data.alerts.end}}

## Limitations

- If you have multiple applications running on the cluster, the **Statements** page shows cumulative parameter values across all applications, while the **Statements Details** page shows the values for the first application only.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, it's worse than the first clause says. The Statements page doesn't aggregate in this alpha release, so it shows a row for each of the applications. The problem here is that there isn't a way to tell which application is which. I'm not sure the best way to document that. 😞

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be useful to link to documentation about setting the application, but as far as I can tell it's not really documented on it's own, just briefly on the cluster setting itself and then randomly mentioned elsewhere.

- The **Statements** page provides the SQL statement details only for the [gateway node](architecture/sql-layer.html#overview). To view the details for other nodes, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) from that node and navigate to `http://<node address>:8080/#/statements` from the browser.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the link to the architecture docs is a bit confusing here. Perhaps we can pull in the description of a gateway node to this doc while still having a link? So adding something like "...only for statements sent to the node to which the Admin UI is connected, also known as the gateway node." My construction is a bit awkward, but pulling more of the info onto the page would avoid the user needed to go elsewhere to understand what this means in practice.

- The **Statements** page displays the details of the SQL statements executed only within a specified time interval. By default, the time interval is set to one hour; however, you can customize the interval using the [`diagnostics.reporting.interval`](cluster-settings.html#settings) cluster setting.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be really clear here: this is not a one hour moving window, but rather something that is completely reset once an hour so that at the end of the hour you will see 0 statements on this page after all of them are wiped.


## Understanding the Statements page

### SQL statement fingerprint

Whenever possible, the **Statements** page displays the details of SQL statement fingerprints instead of individual SQL statements.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this is a little bit confusing. The way I think about it is that there are some statements where the fingerprint happens to be the same as the statement itself, notably when they contain no constant values. We're still using the fingerprint. But this sentence makes it sound less orderly or something...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@couchand Hmmm....right. So effectively, even if the fingerprint is the statement itself, it is still a fingerprint. I think I can remove the "Whenever possible" part. Right?


A statement fingerprint is a grouping of similar SQL statements in their abstracted form by replacing the parameter values with `_`. Grouping similar SQL statements as fingerprints helps you quickly identify the frequently executed SQL statements and their latencies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace "parameter values" with "literal values". Not clear what "parameter" means in this context.


A statement fingerprint is generated when two or more statements have the same abstractions. For example, the following statements have the same abstractions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "A statement fingerprint is generated when two or more statements are the same after any literal values in them (e.g. numbers and strings) are replaced with underscores. For example, the following statements have the same once their numbers have been replaced with underscores"


`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (192, 891, 20)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (784, 452, 78)`

Thus they can have the same fingerprint:

`INSERT INTO new_order(product_id, customer_id, no_w_id) VALUES (_, _, _)`

The following statements are different enough to not have the same fingerprint:

`INSERT INTO orders(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, 11, 11098)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, 11098)`
`INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, $3)`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've opened cockroachdb/cockroach#27052 to track the idea to use placeholders for fingerprints. Pending the way that gets resolved these examples may move up to the block above!


### Parameters

The **Statements** page displays the execution time, count, and mean rows and latency for each statement fingerprint. By default, the statement fingerprints are sorted by their execution time; however, you can sort the table by count, mean rows, and mean latency.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These terms are defined below, but we use "execution time" here and "time" below; we should be consistent to make sure users understand what this metric is/what default sort behavior is.


The following details are provided for each statement fingerprint:

Parameter | Description
-----|------------
Statement | The SQL statement or the fingerprint of similar SQL statements.
Time | The cumulative time taken to execute the SQL statement (or multiple statements having the same fingerprint).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my part, repeating the parenthetical every time starts to feel excessive.

Copy link
Contributor

@jseldess jseldess Jun 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This description leaves me a little confused:

  • If it's a fingerprint, does Time tell you the cumulative time for all of the statements grouped as the fingerprint, or for each individual statement? If the former, is it an average?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since some of the other fields mention "average", I'm wondering if that's really the case here, too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should rename this column to "total time" or "cumulative time". It's average time * count (both already columns in their own right).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I wouldn't say "the SQL statement (or multiple statements having the same fingerprint)" — it's always a fingerprint, it's just that sometimes there's only one statement with that fingerprint.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree and think that would remove some of my confusion. We define fingerprint above, so we can just use that term, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely want to revisit the phrasing later. The reason I worded it this way was because "execute the statement fingerprint" felt weird because we don't execute the fingerprint, but multiple SQL statements with the same fingerprint. Can't think of a way to convey that without stating it explicitly. Suggestions welcome :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean. Maybe:

The cumulative time taken to execute the SQL statements represented by the fingerprint.

@vilterp, when you say that average time is already a column, do you mean Mean Latency?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, Mean Latency. We're just doing users a favor by multiplying two columns already on the page.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah..I think the docs need to be more explicit in explaining that to the users. Will work on that in the follow-up PR.

Count | The total number of times the SQL statement (or multiple statements having the same fingerprint) is executed. <br><br>The execution count is displayed in numerical value as well as in the form of a horizontal bar. The bar is color-coded to indicate the ratio of runtime success (indicated by blue) to runtime failure (indicated by red) of the execution count for the fingerprint. The bar also helps you compare the execution count across all SQL fingerprints in the table. <br><br>You can sort the table by count.
Mean Rows | The average number of rows returned or affected while executing the SQL statement (or multiple statements having the same fingerprint). <br><br>The number of mean rows is displayed in numerical value as well as in the form of a horizontal bar. The bar helps you compare the mean rows across all SQL fingerprints in the table. <br><br>You can sort the table by mean rows.
Mean Latency | The average service latency of the SQL statement (or multiple statements having the same fingerprint). <br><br> The mean latency is displayed in numerical value as well as in the form of a horizontal bar. The bar is color-coded to indicate the latency across the execution phases: parse (indicated by red), plan (indicated by yellow), execute (indicated by blue), and overhead (indicated by red). The bar also helps you compare the mean latencies across all SQL fingerprints in the table. <br><br>You can sort the table by mean latency.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any docs on these phases that we can link to?


To view additional details of a statement fingerprint, click on the statement fingerprint in the **Statement** column to see the **Statement Details** page.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense for this to be in the "Statement" row of the table above?


## Statement Details page

The **Statement Details** page displays the details of the execution count, latency by phase, row count, and statistics for the selected statement fingerprint.

### Execution count

The **Execution Count** table provides information about the following parameters in numerical values as well as bar graphs:

Parameter | Description
-----|------------
First Attempts | The cumulative number of first attempts to execute the SQL statement (or multiple statements having the same fingerprint).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, the term "cumulative" here and below feels a little confusing, perhaps because of the way the rest of the sentence is phrased. What does that term really add?

Retries | The cumulative number of retries to execute the SQL statement (or multiple statements having the same fingerprint).
Max Retries |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tbd?

Total |

### Latency by phase

The **Latency by Phase** table provides the mean and standard deviation values of the service latency for each execution phase (parse, plan, run, and overhead) for the SQL statement (or multiple statements having the same fingerprint). The table provides the service latency details in numerical values as well as bar graphs. The bar graphs are color-coded per execution phase:

Phase | Color code
-----|------------
Parse | Red
Plan | Yellow
Run | Blue
Overhead | Red
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's also a row for "Overall", which in the alpha has the numbers but no bar.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


### Row count

The **Row Count** table provides the mean and standard deviation values of cumulative count of rows returned or affected by the SQL statement (or multiple statements having the same fingerprint). The table provides the service latency details in numerical values as well as a bar graph.

### Statistics

The statistics box on the right-hand side of the **Statements Details** page provides the following details for the statement fingerprint:

Parameter | Description
-----|------------
Total time | The cumulative time taken to execute the SQL statement (or multiple statements having the same fingerprint).
Execution count | The total number of times the SQL statement (or multiple statements having the same fingerprint) is executed.
Executed without retry | The total number of times the SQL statement (or multiple statements having the same fingerprint) is executed successfully on the first attempt.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the percentage of statements, not the total number.

Mean service latency | The average service latency of the SQL statement (or multiple statements having the same fingerprint).
Mean number of rows | The average number of rows returned or affected while executing the SQL statement (or multiple statements having the same fingerprint).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you planning on adding a section on the little table below that statistics box?

Copy link

@piyush-singh piyush-singh Jun 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The table @couchand mentioned in his comments

image

## See also

- [Troubleshooting Overview](troubleshooting-overview.html)
- [Support Resources](support-resources.html)
- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)