Cherry-pick #17719 to 7.x: [Metricbeat] Add aggregation aligner as a config param for stackdriver metricset in GCP #17979
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.
Cherry-pick of PR #17719 to 7.x branch. Original message:
What does this PR do?
aligner
config parameter for stackdriver metriset under metrics.cpu.utilization.avg
forALIGN_MEAN
,cpu.utilization.sum
forALIGN_SUM
andcpu.utilization.value
forALIGN_NONE
.metricbeat/docs/fields.asciidoc
to include mappings fromgooglecloud
module.data-*.json
files that are not generated by integration test TestData for each metricset.Why is it important?
ListMetricDescriptors API is used to get metadata sample period and ingest delay for each metric type once at the start of this module. If sample period is smaller than the collection period, aggregation will be used in
ListTimeSeries
API. By default, aligner isALIGN_NONE
. This means if user specify this Metricbeat collection period to be5m
and the metric type sample period is 60s, then Metricbeat will return 5 raw data points (1 for each minute) in one ListTimeSeries API call. This will save cost significantly if user does not mind the extra delay. If user wants to only return one aggregated metric per collection period, aligner can be specified, such asALIGN_MEAN
,ALIGN_SUM
and etc.Monitoring collects one measurement each minute (the sampling rate), but it can take up to 4 minutes before you can retrieve the data (latency). In order to make sure the collection is successful, we delay collection startTime and endTime for a number of minutes defined by
ingest delay
every time. Instead of hardcodingingest delay
to 4 minute, this is obtained fromListMetricDescriptors
API for each metric type.Assume
ingest delay = 4-minute
,sample period = 1-minute
andcollection period = 1-minute
, when querying GCP APItimeSeries.list
, the time interval changed to:Therefore, data collection will always have a delay. This is consistent with monitoring in GCP portal.
Assume
ingest delay = 4-minute
,sample period = 5-minute
, aggregation aligner isALIGN_MEAN
andcollection period = 5-minute
, when querying GCP APItimeSeries.list
, the time interval changed to:Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Two test cases here:
Use config below and you should see 5 metrics every 5 minutes:
and output event looks like this:
Use config below and you should see 1 metric every 1 minute:
and output event looks like this:
Related issues
TODOs
This PR is getting too big so I will list things need to be done in separate PRs:
Investigate distribution type value in google cloud:
beats/x-pack/metricbeat/module/googlecloud/stackdriver/response_parser.go
Line 99 in 95626b8
change aligner to
aligners
for a list of stringsmove
service
intometrics
config and change config to look like this:data.json
files for different metric types inside each metricset.