Ceph » mgr » Dashboard

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...

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.

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?

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.