-
Notifications
You must be signed in to change notification settings - Fork 768
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
GRRafana: Add support to query Client Breakdown Statistics #870
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This abstract class encapsulates a single metric that can be fetched from a FS-based GRR deployment. For instance, such a metric can be "Mean Resident Memory MB". This class is created so that we can introduce metrics which aren't targeted at individual clients alone, but also multiple clients (statistics page in GRR).
Tests were fixed/enhanced for the previous behaviour (only Client Load Stats). I will nxt added unit tests for the aggregated statistics that were added to GRRafana.
- Changed days buckets to constant _FLEET_BREAKDOWN_DAY_BUCKETS - Added a comment on conversion from MiB to MB - Changed some variable names to be consistent and more clear
panhania
reviewed
Oct 21, 2020
* Import package abc itself instead of methods out of it * Callable type mentions full arg/return types * Hide attributes by using underscores
* _Datapoint is now a NamedTuple * Renamed AVAILABLE_METRICS_DICT to AVAILABLE_METRICS_BY_NAME * Changed all 'extend's to AVAILABLE_METRICS_LIST with a more readable loop * Using context manager in testing for KeyError
panhania
requested changes
Oct 26, 2020
* Ignore override code issues and add TODO * Make __init__ not abstract * Use FrozenSet instead of frozenset
PTAL @panhania |
panhania
approved these changes
Oct 28, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR extends GRRafana HTTP server introduced in #832 by adding new metrics that can be fetched.
These new metrics are the ones that appear in GRR's Statistics page (for reference, you can check out one of the metrics fetched within this page here).
The metrics introduced to the server (and Grafana, in turn) are:
All metrics are available in the interface for 1, 7, 14 and 30 days, and are shown in a table format (similar to the way it currently is in the Statistics page within GRR AdminUI).
In order to support this new metric (which unlike Client Load Stats in #859, which must be provided with a GRR Client ID), we GRRafana to support multiple types of metrics. So we have introduced the abstract Metric class to encapsulate the appropriate logic.
Note that this PR may make the different cron jobs that build
FleetStats
objects and push them to the datastore obsolete. As Grafana issues a request to GRRafana, the latter will callCountClientPlatformReleasesByLabel
(for example) the build the correspondingFleetStats
object that will encapsulate the data. Then GRRafana will process it and send it back to Grafana.Also note that in a future PR, we'd like to cache the results of the queries within GRRafana, as they may get quite time consuming with many labels and data.