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

cli: debug zip returns incomplete data #32647

Closed
tbg opened this issue Nov 27, 2018 · 2 comments
Closed

cli: debug zip returns incomplete data #32647

tbg opened this issue Nov 27, 2018 · 2 comments
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Milestone

Comments

@tbg
Copy link
Member

tbg commented Nov 27, 2018

This code here queries various table against a single node, but it should query them on all nodes.

For the gossip-based tables this is less of a problem than for the metrics, which are strictly per node. I'm looking at an issue right now where the debug zip metrics of all nodes would've been really helpful, but I only have the metrics of one node.

cockroach/pkg/cli/zip.go

Lines 210 to 222 in 9f44f85

for _, item := range []struct {
query, name string
}{
{"SELECT * FROM crdb_internal.gossip_liveness;", gossipLivenessName},
{"SELECT * FROM crdb_internal.gossip_network;", gossipNetworkName},
{"SELECT * FROM crdb_internal.gossip_nodes;", gossipNodesName},
{"SELECT * FROM crdb_internal.node_metrics;", metricsName},
{"SELECT * FROM crdb_internal.gossip_alerts;", alertsName},
} {
if err := dumpTableDataForZip(z, sqlConn, item.query, item.name); err != nil {
return errors.Wrap(err, item.name)
}
}

@tbg tbg added the C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. label Nov 27, 2018
@tbg tbg added this to the 2.2 milestone Nov 27, 2018
@tbg tbg added this to Incoming in KV via automation Nov 27, 2018
@tbg
Copy link
Member Author

tbg commented Dec 21, 2018

cc @dsaveliev who's taking a look at this.

I just realized this is a bit more complex than it seems. For example, to query node_metrics for another node, you'd naively need to open SQL connections to other nodes, which is not generally possible.

Instead, we should grab /_status/vars which contains pretty much the same information. In the long run, if we use SQL for more of this information, we need facilities inside of SQL that allows proxying data from other nodes, but this is less urgent.

@tbg
Copy link
Member Author

tbg commented Mar 28, 2019

#36167

@tbg tbg closed this as completed Mar 28, 2019
KV automation moved this from Incoming to Closed Mar 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Projects
None yet
Development

No branches or pull requests

1 participant