-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
RFC admin: hierarchical stats viewer #18670
Conversation
Signed-off-by: Joshua Marantz <[email protected]>
…n't wind up inserting and then deleting most of the candidate elements. Signed-off-by: Joshua Marantz <[email protected]>
…adouts Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
… trial. Signed-off-by: Joshua Marantz <[email protected]>
…xcessive number of comparisons. Signed-off-by: Joshua Marantz <[email protected]>
… stringified stat-name, which is faster to compare than the StatName. We only need to hold the ones that are in the top-K so it won't add memory pressure beyond what we need for the page. Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
/retest |
Retrying Azure Pipelines: |
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
I think for only solving browser memory, the existing filtering on the stats endpoint would be sufficient to reduce the results size in a flexible way. I'm assuming you took this approach because on the server side, using a regex to filter all the stats is expensive. Is that correct? One alternative idea to allow more flexibility in which stats are grouped together: Let the user define a list of groups in their bootstrap config, and use existing filtering methods to add stats to zero or more groups (selected at stat creation time), and add an api for querying by group name. My concern with this approach is that we're tying an external admin API to an internal code API used for managing lifetimes. |
/wait-any |
You are right: browser memory is solved with filtering, but there's 2 issues:
And still doesn't solve server-side memory bloat (with |
Adding another way to get stats won't solve that problem. I think the only way to solve that is to by default have a limit on the number of stats returned, with a query parameter to override.
Yeah, I think improving that webpage would be an easy win in that case. Have the link by default get
Agreed. I think it makes a lot of sense to have a way to reduce server resources for fetching huge numbers of stats. |
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Commit Message: Make the HTML view for stats a compile-time option, defaulting to on. This PR doesn't change any code-paths, but it moves the HTML support into a separate file, compiled into //source/server/admin:admin_lib. In the future, and admin_html_lib will be added, built only when admin-html is not disabled. That will allow envoyproxy/envoy#19546 and ultimately envoyproxy/envoy#18670 to proceed. To disable, compile with `--define=admin_html=disabled`, in which case the admin `"/"` endpoint will just print that the thml mode was disabled. Additional Description: This PR is a step toward solving envoyproxy/envoy#18675 Risk Level: low -- this just moves code around and doesn't change it at all. Testing: //test/..., both with and without `--define=admin_html=disabled` Docs Changes: included Release Notes: included Platform Specific Features: n/a Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
Signed-off-by: Joshua Marantz <[email protected]>
actually I'm going to close this again. Having worked hard on making filtering relatively fast, I think the flat view is probably OK. What's really needed more (based on recent experience) is to be able to sort by recency or frequency of changes, which can be done in the browser by polling json. I'll start a new PR for that. Fortunately the support for this will all be buried in the admin-html conditional compilation and will not affect envoy-mobile. |
Commit Message: Adds default hierarchical view for admin stats accessed by clicking 'stats' from the admin home page. Note that the existing /stats API is unchanged.
This is not ready for approval/submit yet as the new endpoints lack unit tests, and the UI (if we keep it) is ugly (unstyled). But I wanted to get some comments on the concept, particularly as it relates to solving #18675 before I clean all that up.
Also needed before this PR can be merged:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
Fixes: #18675