-
Notifications
You must be signed in to change notification settings - Fork 471
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
Changes from 3 commits
bf9441d
9d5fbb4
2b4ef7a
527b3fa
2aa1506
abb8e1a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,110 @@ | ||
--- | ||
title: Statements Page | ||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. 😞 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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... There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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)` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For my part, repeating the parenthetical every time starts to feel excessive. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This description leaves me a little confused:
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see what you mean. Maybe:
@vilterp, when you say that average time is already a column, do you mean There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct, There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The table @couchand mentioned in his comments |
||
## See also | ||
|
||
- [Troubleshooting Overview](troubleshooting-overview.html) | ||
- [Support Resources](support-resources.html) | ||
- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints) |
There was a problem hiding this comment.
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.