-
Notifications
You must be signed in to change notification settings - Fork 898
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
Fix queueing of historical metrics collection #14695
Conversation
088e8d3
to
fc88644
Compare
@@ -177,6 +177,8 @@ def perf_capture(interval_name, start_time = nil, end_time = nil) | |||
|
|||
if start_range.nil? | |||
_log.info "#{log_header} Skipping processing for #{log_target} as no metrics were captured." | |||
# Set the last capture on to end_time to prevent forever queueing up the same collection range | |||
update_attribute(:last_perf_capture_on, end_time) if last_perf_capture_on.nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, although I think we want update
or update_attributes
so it does validations I believe
@@ -49,7 +49,7 @@ def perf_capture_queue(interval_name, options = {}) | |||
cb = nil | |||
if interval_name == 'historical' | |||
start_time = Metric::Capture.historical_start_time if start_time.nil? | |||
end_time = Time.now.utc if end_time.nil? | |||
end_time = Time.now.utc.end_of_day # Ensure no more than one historical collection is queue up in the same day |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor typo: queued
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be Time.tomorrow.beginning_of_day
@@ -49,7 +49,7 @@ def perf_capture_queue(interval_name, options = {}) | |||
cb = nil | |||
if interval_name == 'historical' | |||
start_time = Metric::Capture.historical_start_time if start_time.nil? | |||
end_time = Time.now.utc if end_time.nil? | |||
end_time = Time.now.utc.end_of_day # Ensure no more than one historical collection is queue up in the same day |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious why this happens... I would think the thing that queues up the historicals would put start/end pairs for every record.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, should this be an ||=
. If an end_time is passed in, why wouldn't we honor it?
@gtanzillo @blomquisg Here's what I was talking about on the call, when I said that captures should never be open-ended for the start_time: https://github.com/ManageIQ/manageiq/pull/14695/files#diff-98e67a56bb0805013a9953cc93e47389R138 (seems it's only for hourly captures) |
- Set end_time to the end of the current day before queueing historical collection to allow put match and update existing queue item - Set last_perf_capture_on to end time when no metrics were available to prevent constantly queueing the same historical range. https://bugzilla.redhat.com/show_bug.cgi?id=1436034
fc88644
to
155ddd6
Compare
items = split_capture_intervals("historical", last_perf_capture_on, realtime_cut_off) | ||
end | ||
# push realtime item to the front of the array | ||
items.unshift([interval_name, realtime_cut_off]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we only want to do this when the time is outside the realtime_cut_off
that is, I think something like
realtime_cut_off = 4.hours.ago.utc.beginning_of_day
if last_perf_capture_on && last_perf_capture_on < realtime_cut_off
items = [[interval_name, realtime_cut_off]] +
split_capture_intervals("historical", last_perf_capture_on, realtime_cut_off)
else
items = [interval_name]
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case of VMware this will be fine, I think. Since the max we can get from the provider is 4.hours
of data. However, for Hawkular, I think this breaks, since the max we can get from the provider is 7.days
.
So, without a start date, I think it will try to get the maximum amount of data available. But, I'm not positive.
Edit
And, that leads us back to the "we should fix this in perf_capture
instead of perf_capture_queue
" discussion...
@@ -78,15 +86,17 @@ def perf_capture_queue(interval_name, options = {}) | |||
if msg.nil? | |||
qi[:priority] = priority | |||
qi.delete(:state) | |||
qi[:miq_callback] = cb if cb | |||
if cb and item_interval == "realtime" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer &&
over and
;)
@@ -177,6 +187,8 @@ def perf_capture(interval_name, start_time = nil, end_time = nil) | |||
|
|||
if start_range.nil? | |||
_log.info "#{log_header} Skipping processing for #{log_target} as no metrics were captured." | |||
# Set the last capture on to end_time to prevent forever queueing up the same collection range | |||
update_attribute(:last_perf_capture_on, end_time) if interval_name == 'realtime' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be update_attributes
instead of update_attribute
I think we still need to make the intervals here https://github.com/gtanzillo/manageiq/blob/8b5bf7441789c5c1c829ff40edea1b3728440acf/app/models/metric/ci_mixin/capture.rb#L28 in |
The specs should test * a single day (where the realtime queue item should have no end time) * realtime over multiple days (where the older queue items are historical) * multiple attempts to queue realtime metrics for a single object in the same 20-minute window
The |
Checked commits gtanzillo/manageiq@155ddd6~...004569f with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 spec/models/metric/ci_mixin/capture_spec.rb
|
Fix queueing of historical metrics collection (cherry picked from commit 1f13f1b) https://bugzilla.redhat.com/show_bug.cgi?id=1441204
Euwe backport details:
|
Fix queueing of historical metrics collection (cherry picked from commit 1f13f1b) https://bugzilla.redhat.com/show_bug.cgi?id=1441203
Fine backport details:
|
if interval_name == 'historical' | ||
start_time = Metric::Capture.historical_start_time if start_time.nil? | ||
end_time ||= 1.day.from_now.utc.beginning_of_day # Ensure no more than one historical collection is queue up in the same day | ||
items = split_capture_intervals(interval_name, start_time, end_time) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
@@ -78,15 +89,17 @@ def perf_capture_queue(interval_name, options = {}) | |||
if msg.nil? | |||
qi[:priority] = priority | |||
qi.delete(:state) | |||
qi[:miq_callback] = cb if cb | |||
if cb && item_interval == "realtime" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see this before. very nice
qi | ||
elsif msg.state == "ready" && (task_id || MiqQueue.higher_priority?(priority, msg.priority)) | ||
qi[:priority] = priority | ||
# rerun the job (either with new task or higher priority) | ||
qi.delete(:state) | ||
if task_id | ||
existing_tasks = (((msg.miq_callback || {})[:args] || []).first) || [] | ||
qi[:miq_callback] = cb.merge(:args => [existing_tasks + [task_id]]) | ||
qi[:miq_callback] = cb.merge(:args => [existing_tasks + [task_id]]) if item_interval == "realtime" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can get rid of the check on upgrading priority, then it will be easier to go over to put_unless_exists
.
Real-time will potentially still need this
Fix queueing of historical metrics collection (cherry picked from commit 1f13f1b) https://bugzilla.redhat.com/show_bug.cgi?id=1441204
https://bugzilla.redhat.com/show_bug.cgi?id=1436034
/cc @Fryguy @blomquisg @kbrock @jrafanie