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

nsqadmin: show total queue depth #1021

Open
danbf opened this issue Apr 9, 2018 · 6 comments
Open

nsqadmin: show total queue depth #1021

danbf opened this issue Apr 9, 2018 · 6 comments

Comments

@danbf
Copy link
Contributor

danbf commented Apr 9, 2018

having an at a glance summary counter for total queue depth would be nice when doing maintenance on nodes so it would be clear when a machine had no more traffic so it could be shutdown/rebooted ensuring that the machine didn't loose any items when shutdown.

right now one has to scroll through a list channels and scan them to see if they are down to a depth of zero.

@judwhite
Copy link
Contributor

judwhite commented Apr 9, 2018

@danbf I agree cluster/node depth at the topic or channel level, and overall depth for a cluster/node, is helpful in many scenarios, not limited to shutdown.

We extract this information from the API but it would be helpful to have in nsqadmin (also, seeing pause status at a glance would be helpful).

The UX might be tricky when you consider large clusters; we only run with 8 main nsqd nodes.

There may be multiple incremental improvements we can make. Do you have specific ideas for how this would work/look?

@danbf
Copy link
Contributor Author

danbf commented Apr 12, 2018

no ideas, just desire, and it should be at the top of the node view in nsqadmin /nodes/172.19.32.135:4151

@mreiferson mreiferson changed the title nsqadmin: at a glance summary counter for total queue depth nsqadmin: show total queue depth Apr 26, 2018
@zzmg
Copy link

zzmg commented Jan 10, 2019

you can use this api : http://:4171/api/topics/topic_name to find out
all topic:http://
:4171/api/topics/

@dudleycarr
Copy link
Contributor

I've taken a stab at aggregating metrics in the node view at the node and topic levels. Please see the screenshot below.

I'm looking for some feedback:

  1. Does the set of metrics aggregated for a topic and the node make sense? Some metrics are obviously valid to aggregate. Others might be misleading to aggregate.
  2. Does it make sense to aggregate at both the topic and node level?
  3. Is this helpful in the node view, or is it distracting in an already dense view?

Some design decisions:

  1. Aggregations have a gray-colored background.
  2. Aggregate columns line up with columns with the same name at either the topic or channel level.
  3. A paused column was introduced since that seems helpful in aggregate for both topics and channels.
  4. Aggregations are displayed at the top of each level (node and topic). However, they could be footers by level. I personally think it makes sense at the top of each level.

A couple of observations about the node view unrelated to the aggregations. Thoughts and feedback would be welcome here as well:

  1. I think it would be preferable to right-align all the columns with numeric values. It makes visually comparing values in a column simpler. Columns like depth that contain a graph at the topic level but not at the channel level do not line up.
  2. By design, the node view is dense, given the amount of information to display. It might be helpful to add some vertical whitespace between topics to break it up just a bit while maintaining the overall density of information.
SCR-20231025-melw

@mreiferson
Copy link
Member

Thanks @dudleycarr, very impressed and thankful for you digging in to all these old nsqadmin issues!

My overall feedback is, I'm curious how it would turn out if there was a way to offer an "expanded" view that contained the full detail present in your screenshot, and when "contracted" could show a summary for the workflows where one is interested in the aggregate view.

To your point, this page is already dense, so just adding more (regardless of styling) may still make it difficult to glean the information one is looking for. I think that trying to separate the use cases a bit might make this easier?

@dudleycarr
Copy link
Contributor

Happy to help and thanks for taking a look!

I think the idea of separating the use cases makes sense. I'll try adding an aggregate view that will show the aggregate views with channel and channel client rows collapsed by default. nsqadmin users can then have the option to drill down in the aggregate view. Worth a shot and then we can revisit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants