Project

General

Profile

Feature #36675

Tasks #36451: mgr/dashboard: Scalability testing

Bug #36453: mgr/dashboard: Some REST endpoints grow linearly with OSD count

mgr/dashboard: Provide API endpoint providing minimal health data

Added by Zack Cerza about 2 months ago. Updated 21 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
dashboard/backend
Target version:
Start date:
11/01/2018
Due date:
% Done:

100%

Source:
Tags:
scalability
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

Currently the dashboard polls both /api/summary and /api/dashboard/health every 5s. The latter endpoint returns a large amount of data, but the amount needed to actually render the dashboard is quite small by comparison.

I think it would make sense to get rid of /api/dashboard/health and replace it with e.g. /api/health/full and /api/health/minimal.

Another idea would be to merge the minimal health data into /api/summary, but that might warrant more discussion.

A caveat here is that /api/dashboard/health currently provides logging data which will be moving out as a result of #24571 - perhaps the solution to that piece is to simply move that data out to a new /api/logs endpoint.


Related issues

Related to mgr - Bug #34320: mgr/dashboard: Read/Write OPS in pool stats always show 0 Won't Fix 08/29/2018

History

#1 Updated by Lenz Grimmer about 2 months ago

Zack Cerza wrote:

Currently the dashboard polls both /api/summary and /api/dashboard/health every 5s. The latter endpoint returns a large amount of data, but the amount needed to actually render the dashboard is quite small by comparison.

I think these endpoints are a verbatim copy of the ones used by the original read-only dashboard. They likely haven't been modified when dashboard v2 was initially created.

I think it would make sense to get rid of /api/dashboard/health and replace it with e.g. /api/health/full and /api/health/minimal.

And the content of /api/health/minimal would be defined by the requirements of the dashboard landing page?

Another idea would be to merge the minimal health data into /api/summary, but that might warrant more discussion.

A caveat here is that /api/dashboard/health currently provides logging data which will be moving out as a result of #24571 - perhaps the solution to that piece is to simply move that data out to a new /api/logs endpoint.

Sounds like a good idea to me. The current /api/dashboard/health endpoint seems to be a tad bit too bloated...

#2 Updated by Zack Cerza about 2 months ago

An update on what my WIP has changed so far, along with some thoughts:

  1. /api/health/full provides what /api/dashboard/health used to report, minus logs.
    • This isn't used by anything, yet.
  2. /api/health/minimal provides just what the dashboard landing page needs, and no more.
    • Since I am preserving the original format to avoid unnecessary compatibility breaks, certain fields look a bit awkward. For example, the only thing we need to know about pools is the count - so that piece looks like "pools": [{}, {}, {}]
  3. /api/logs/all provides audit_log and clog.
    • I'm not sure if we would ever want one log and not the other. If so, I'll add separate endpoints. If not, we might prefer to just use /api/logs for both, dropping the /all.
  4. /api/dashboard is gone.

Of course I'm open to any feedback on these items. I'm very close to submitting a PR, and am happy to make further changes.

#3 Updated by Zack Cerza about 2 months ago

  • % Done changed from 50 to 80

#4 Updated by Zack Cerza about 2 months ago

  • Status changed from In Progress to Need Review
  • % Done changed from 80 to 100

#5 Updated by Lenz Grimmer about 1 month ago

  • Tracker changed from Bug to Feature

#6 Updated by Lenz Grimmer about 1 month ago

  • Related to Bug #34320: mgr/dashboard: Read/Write OPS in pool stats always show 0 added

#7 Updated by Lenz Grimmer about 1 month ago

Just wondering: is the issue mentioned in #34320 somehow related to this work? Or have these pool metrics been obtained via a different API endpoint?

#8 Updated by Zack Cerza about 1 month ago

Lenz Grimmer wrote:

Just wondering: is the issue mentioned in #34320 somehow related to this work? Or have these pool metrics been obtained via a different API endpoint?

I hadn't seen that issue - I don't think they're related at all.

#9 Updated by Lenz Grimmer about 1 month ago

  • Pull request ID set to 24900

#10 Updated by Lenz Grimmer 27 days ago

  • Target version set to v14.0.0

#11 Updated by Lenz Grimmer 21 days ago

  • Status changed from Need Review to Resolved

Also available in: Atom PDF