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

ui: surface debug pages for users #20690

Closed
dianasaur323 opened this issue Dec 13, 2017 · 19 comments
Closed

ui: surface debug pages for users #20690

dianasaur323 opened this issue Dec 13, 2017 · 19 comments
Assignees
Labels
A-webui-general Issues on the DB Console that span multiple areas or don't have another clear category. C-investigation Further steps needed to qualify. C-label will change.
Milestone

Comments

@dianasaur323
Copy link
Contributor

dianasaur323 commented Dec 13, 2017

cc @josueeee your requested user stories for the debug page in 2.0

  • I want to know how my nodes are configured (node diagnostics page) - reports/nodes
  • I want to know which ranges are causing problems (problem ranges report) - /reports/problemranges
  • I want to know if my nodes can talk to each other on the network (network diagnostics page) - reports/network
  • I want to check if my certificates are configured properly (certificates page) - reports/certificates/local
  • [New] I want to see what my localities are (locality tree)
  • [New] I want to check my zone configs (replica matrix)

Usability

  • Flag this feature as "experimental / beta"
  • Segment debug options into standard and advanced
  • Link to user contract on what it means for a feature to be experimental

and cc @BramGruneir for thoughts. For context, we don't have a lot of time to brush the debug pages up, so this is incredibly limited in scope. Basically trying to highlight what would be most useful to users who are not CockroachDB experts.

@dianasaur323 dianasaur323 added this to the 1.2 milestone Dec 13, 2017
@couchand
Copy link
Contributor

If we're gonna expose these maybe we should just put a link to /debug in the sidebar (what if the cockroach secretly linked to debug?) and let them just browse them all? If we mark them advanced/experimental it's probably okay if they're rough around the edges?

@BramGruneir
Copy link
Member

BramGruneir commented Dec 13, 2017 via email

@dianasaur323
Copy link
Contributor Author

dianasaur323 commented Dec 14, 2017 via email

@tbg
Copy link
Member

tbg commented Dec 14, 2017

Persona-wise, I think this is really going after the developer who is
testing CockroachDB and trying to get it to work, not for the DBA who is
debugging CockroachDB on a daily basis

My intuition runs mostly contrary to that. The debug pages are the stuff that only makes sense if you're extremely familiar with the inner workings of the system. If there are parts of the debug pages that you think are valuable to beginners, I would advise pulling them out of the /debug space (they can still be linked to from there) and working them into the actual UI. The node, network and security pages strike me as candidates. The rest don't.

@dianasaur323
Copy link
Contributor Author

@tschottdorf I actually think we are totally aligned. I agree that the pages you listed are the most important ones for beginners which is why I marked them as focus areas in the acceptance criteria.

I guess what I should clarify is that I think we should expose these in a way that a beginner could use them, and hide the more advanced options either under a different grouping or in an expansion menu so that beginners know where to look first.

@couchand
Copy link
Contributor

couchand commented Jan 2, 2018

One other thought: if they're hidden/undocumented, it's reasonable for us to deprioritize bug reports. Given the length of our bug list, that might be a useful feature. OTOH, since they're generally really useful for us developing the system, we probably want to prioritize bug reports anyway.

@dianasaur323
Copy link
Contributor Author

@couchand that's a good point. We probably shouldn't take on the burden of making this super user-friendly until we decide to prioritize it. I think @josueeee is coming up with an approach during his free friday time, so we should be able to at least get something out there, and mark it as experimental or something.

@dianasaur323
Copy link
Contributor Author

dianasaur323 commented Jan 31, 2018

ok, based on our convo from yesterday, it seems like we are agreed that we should move forward with this, with the caveat that we really need to clear up the debt we have around being able to support these pages through automated testing (message received!).

@josueeee I added some new user stories since it appears that we may need to stick in zone configs in the debug pages, and we also have @couchand's nifty localities page. fyi @vilterp re zone config matrix. Let's merge as a debug page and revisit if we have time?

@Amruta-Ranade do you know how we document experimental features right now?

@Amruta-Ranade
Copy link
Contributor

@dianasaur323 We document them as regular features and mark them as "Experimental" (example: https://www.cockroachlabs.com/docs/stable/import.html)

@dianasaur323
Copy link
Contributor Author

@Amruta-Ranade I see - could we discuss writing up a short "user contract" of what users can expect when a feature is experimental, and link to that documentation?

@Amruta-Ranade
Copy link
Contributor

@dianasaur323 Yes.

@dianasaur323
Copy link
Contributor Author

dianasaur323 commented Jan 31, 2018 via email

@BramGruneir
Copy link
Member

How do the debug pages fit in as Experimental exactly? The pages themselves are fully functional and keeping the working is a priority as we use them for debugging.

They are an advanced feature, but definitely not experimental.

@dianasaur323
Copy link
Contributor Author

I'm glad you asked this question - we are actually hashing out exactly what experimental means, and you will hear an update about it over the next couple weeks.

Short answer is that experimental means we make no guarantees about the UI, how long they will persist in that state, and how polished they are. We don't want to take on the burden of maintaining backwards compatibility on these pages. We will likely start pulling info surfaced in these pages into other components in the admin UI over the next couple releases.

@BramGruneir
Copy link
Member

My point is that that is very different than import. Import was experimental because it was not complete and fairly flakey. And experimental fits that perfectly.

The UI for the debug pages is clunky and functional, but not in that much flux. They could use some polish and some styling, but I don't think they're going anywhere and being overhauled in any meaningful way in the short or even longer term.
So with that, what does a guarantee about the UI mean? Do we have a guarantee about the rest of the UI? Do we have any type of commitment to not alter, update or move pages between releases?

@vilterp vilterp changed the title ui: surface debug page for users ui: surface debug pages for users Feb 6, 2018
@couchand couchand modified the milestones: 2.0, 2.1 Mar 6, 2018
@dianasaur323
Copy link
Contributor Author

Popping over to @piyush-singh

@couchand couchand added C-investigation Further steps needed to qualify. C-label will change. A-webui-general Issues on the DB Console that span multiple areas or don't have another clear category. labels Apr 24, 2018
@piyush-singh
Copy link

piyush-singh commented Oct 4, 2018

@vilterp following up with some tentative copy as discussed:

Top of the page: The following pages are meant for advanced monitoring and troubleshooting. Note that these are experimental and subject to change.
Custom TS chart - Create custom chart of time series data.
Localities - Check node localities for your cluster.
Data Dist - View data distribution across nodes, databases, and tables and verify zone configurations.
Latency Matrix - Check latencies between all nodes in your cluster.
Cluster Settings - View all cluster settings.
Problem Range report - View unavailable, under-replicated, and slow ranges in your cluster.

@vilterp vilterp self-assigned this Oct 4, 2018
@Amruta-Ranade
Copy link
Contributor

Here's the link to the docs page for the custom metrics chart: https://www.cockroachlabs.com/docs/stable/admin-ui-custom-chart-debug-page.html

@Amruta-Ranade
Copy link
Contributor

Edits for note at the top of the page:
The following pages are meant for advanced monitoring and troubleshooting. Note that the pages are experimental and undocumented. If you find an issue, let us know through these channels .

craig bot pushed a commit that referenced this issue Oct 10, 2018
31195: sql: fixed flakey tests for cancelled/errored schema changes r=eriktrinh a=eriktrinh

TestBackfillError had the async schema changer execute immediately,
before the synchronous one could see the error.

TestCancelSchemaChange had the GC TTL set to 0 during the SELECT.

Fixes #31175, #31177

Release note: None

31218: ui: surface debug pages r=couchand a=couchand

Add a (somewhat muted) link in the sidebar for the debug pages, an informational note about the provisional status of the pages, and a snazzy top panel for the ones we want to call attention to.

<img width="1351" alt="screen shot 2018-10-10 at 4 38 29 pm" src="https://user-images.githubusercontent.com/793969/46764652-062ebb80-ccab-11e8-990a-4123a1e3f0a5.png">

Closes #20690

Co-authored-by: Erik Trinh <[email protected]>
Co-authored-by: Andrew Couch <[email protected]>
Co-authored-by: Pete Vilter <[email protected]>
@craig craig bot closed this as completed in #31218 Oct 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-webui-general Issues on the DB Console that span multiple areas or don't have another clear category. C-investigation Further steps needed to qualify. C-label will change.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants