Skip to content
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

Add support for reading prometheus endpoint #20

Closed

Conversation

yaacov
Copy link
Member

@yaacov yaacov commented May 21, 2017

Description
Add support for reading Prometheus endpoint

If prometheus endpoint exist, read metrics from prometeus

@yaacov
Copy link
Member Author

yaacov commented May 21, 2017

@miq-bot add_label compute/containers, wip

cc// @simon3z @cben @moolitayer @zeari

@miq-bot
Copy link
Member

miq-bot commented May 21, 2017

@yaacov Cannot apply the following label because they are not recognized: compute/containers

@miq-bot miq-bot added the wip label May 21, 2017
@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch 9 times, most recently from 9e3e6d7 to 849ade5 Compare May 21, 2017 18:36
@simon3z
Copy link
Contributor

simon3z commented May 22, 2017

@yaacov let's split this in 3 parts (2 of which we can actually merge):

  1. evaluate if we can replace the complex computation of cpu_usage_rate_average(based on the cpu time and the number of cores) with the machine/x/node_utilization
  2. extract the framework about collection that you did here (to generalize hawkular/prometheus)
  3. prometheus implementation (as WIP) leveraging the refactor/framework of point 2

@yaacov
Copy link
Member Author

yaacov commented May 28, 2017

@yaacov let's split this in 3 parts (2 of which we can actually merge):

  • evaluate if we can replace the complex computation of cpu_usage_rate_average(based on the cpu time and the number of cores) with the machine/x/node_utilization
  • extract the framework about collection that you did here (to generalize hawkular/prometheus)
  • prometheus implementation (as WIP) leveraging the refactor/framework of point 2

@simon3z @moolitayer

extract the framework about collection that you did here (to generalize hawkular/prometheus)

Moved to #25

evaluate if we can replace the complex computation of cpu_usage_rate_average(based on the cpu time and the number of cores) with the machine/x/node_utilization

Implementation depend on #25.

@simon3z
Copy link
Contributor

simon3z commented May 30, 2017

evaluate if we can replace the complex computation of cpu_usage_rate_average(based on the cpu time and the number of cores) with the machine/x/node_utilization

Implementation depend on #25.

@yaacov I'd rather not have the new metrics depending on a refactor if possible. I want to backport them in the cleanest way possible.

@miq-bot
Copy link
Member

miq-bot commented Jun 8, 2017

This pull request is not mergeable. Please rebase and repush.

@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch from 849ade5 to bc1f8a6 Compare June 11, 2017 15:13
@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch 2 times, most recently from ac2367f to b0b08f7 Compare June 11, 2017 15:26
@yaacov yaacov mentioned this pull request Jun 11, 2017
@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch 2 times, most recently from 8791308 to b3b8ced Compare June 15, 2017 12:10
@miq-bot
Copy link
Member

miq-bot commented Jul 5, 2017

This pull request is not mergeable. Please rebase and repush.

@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch from b3b8ced to 470b865 Compare July 6, 2017 11:02
@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch 4 times, most recently from d2f0a86 to d9e1450 Compare July 11, 2017 14:48
@simon3z
Copy link
Contributor

simon3z commented Jul 11, 2017

@yaacov should we add the prometheus spec tests as well?

@yaacov
Copy link
Member Author

yaacov commented Jul 11, 2017

should we add the prometheus spec tests as well?

@simon3z 👍 I will

@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch 2 times, most recently from 8a023e9 to c17ccbc Compare July 12, 2017 10:31
@yaacov yaacov force-pushed the read-prometheus-metrics-endpoint branch from c17ccbc to afd4bb8 Compare July 12, 2017 10:34
@miq-bot
Copy link
Member

miq-bot commented Jul 12, 2017

Some comments on commit yaacov@afd4bb8

spec/models/manageiq/providers/kubernetes/container_manager/metrics_capture_spec.rb

  • ⚠️ - 131 - Detected allow_any_instance_of. This RSpec method is highly discouraged, please only use when absolutely necessary.
  • ⚠️ - 138 - Detected allow_any_instance_of. This RSpec method is highly discouraged, please only use when absolutely necessary.
  • ⚠️ - 153 - Detected allow_any_instance_of. This RSpec method is highly discouraged, please only use when absolutely necessary.
  • ⚠️ - 160 - Detected allow_any_instance_of. This RSpec method is highly discouraged, please only use when absolutely necessary.

@miq-bot
Copy link
Member

miq-bot commented Jul 12, 2017

Checked commit yaacov@afd4bb8 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
9 files checked, 0 offenses detected
Everything looks fine. ⭐

@yaacov
Copy link
Member Author

yaacov commented Jul 12, 2017

@yaacov should we add the prometheus spec tests as well?

@simon3z 👍 specs added

a. specs found error in pod collection, fixed [ labels changed current prometheus deployment ]
b. update error handling to work with both pre 4.0.0 and post 4.0.0. versions of hawkular client [56]

@simon3z simon3z requested review from cben and moolitayer July 12, 2017 13:51
@@ -57,7 +58,11 @@ def perf_collect_metrics(interval_name, start_time = nil, end_time = nil)
"[#{start_time}] [#{end_time}]")

begin
context = CaptureContext.new(target, start_time, end_time, INTERVAL)
context = if ems && ems.connection_configurations.prometheus.try(:endpoint)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you defined a method called prometheus_endpoint. Can you use that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no we can not use it here :-(
it's a chicken and egg problem, to use it we need a context, but if we do not have a context we can't use it :-(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So move it to the manager and the capture context

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moving functionality around just for the sake of moving it is pointless, is their a reason for moving it ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you clearly need this function in a wider scope then the capture context (for example to determine which context to create) then you won't have to copy it in different places.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(for example to determine which context to create)

you give this case as an example for wider scope ?

Copy link

@moolitayer moolitayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@yaacov
Copy link
Member Author

yaacov commented Jul 12, 2017

Please split it to ease reviewers work - one for refactor related stuff (moving stuff around, renaming etc) and one for new functionality

We already tried that [1] I do not think we should do that again.

[1] #25

@yaacov
Copy link
Member Author

yaacov commented Jul 12, 2017

metrics collection is supposed to be disabled unless we have an endpoint named hawkular

than we should fix the ems.supports_metrics? [1] function, we can do that in a new PR.

[1] https://github.com/ManageIQ/manageiq-providers-kubernetes/blob/master/app/models/manageiq/providers/kubernetes/container_manager_mixin.rb#L18

@moolitayer
Copy link

We already tried that [1] I do not think we should do that again.

[1] #25

I'm not asking that to create extra work for you.
Reviewing many changes takes a lot of time (and I have my own assignments on top of that).
If the changes are clearly separated so that I don't have to figure out what is being copied and what is new functionality that is a lot easier. I promise you that with smaller changes we will get better code quality.

@yaacov
Copy link
Member Author

yaacov commented Jul 12, 2017

I'm not asking that to create extra work for you.

@simon3z @moolitayer

I did not think so :-) it's a matter of time usage and priorities -

  1. we have two other PR's that wait for this one to be merged [1] [2] they are also high priority.
  2. this PR depend on Prometheus version and the way Promethean is deployed, for example the pod labelling changed in the last month ( because of new version or relabeling [3] ) . We will have a lot of bugs on this new functionalty. we can not wait for the prometheus deployment to be finalized.

New functionality, especially of this size, will come with bugs, and we will fix them when we find them -

  1. first will be fixing the [4] supports_metrics? bug :-)

[1] ManageIQ/manageiq-ui-classic#1677
[2] #47
[3] https://github.com/zgalor/scripts/blob/master/openshift/prometheus_template.yaml#L238
[4] https://github.com/ManageIQ/manageiq-providers-kubernetes/blob/master/app/models/manageiq/providers/kubernetes/container_manager_mixin.rb#L18

@yaacov
Copy link
Member Author

yaacov commented Jul 13, 2017

I promise you that with smaller changes we will get better code quality.

Yes, but:

xkcd

https://xkcd.com/844/

@yaacov
Copy link
Member Author

yaacov commented Jul 13, 2017

#59 fixes the supports_metrics? bug

@moolitayer
Copy link

@yaacov I've asked to move a few files to a different PR so that review is more effective - I do it all the time. I will not approve this pull request as it is.

@yaacov
Copy link
Member Author

yaacov commented Jul 13, 2017

I will not approve this pull request as it is.

Ok :-)

@yaacov
Copy link
Member Author

yaacov commented Jul 13, 2017

@simon3z as you requested in todays meeting, this PR is closed in favour of #62, since the Prometheus part depend on #62 being merged, I will post it once #62 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants