-
Notifications
You must be signed in to change notification settings - Fork 56
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 get prometheus data to run snafu #173
Add get prometheus data to run snafu #173
Conversation
/rerun all |
/rerun all |
Results for SNAFU CI Test
|
Results for SNAFU CI Test
|
/rerun all |
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.
Overall structure of the code is good, I think. I like get_valid_es_document code reuse.
This is missing documentation - how does the benchmark developer switch over to this? How does the user make use of it? What are advantages of doing it this way for the user? Since most kubernetes users are familiar with Prometheus, I think we have to provide some justification for doing things this way. If the answer is short put it in README.md but if not, put it in a separate .md and reference it in README.md, right?
What kinds of prometheus data can you handle, and if you see data that you can't handle, do you alert the user to it and handle it without crashing?
BTW, I could be wrong in my inline comments but I think others might have similar questions, at a minimum comments or documentation should explain right?
Results for SNAFU CI Test
|
Results for SNAFU CI Test
|
Results for SNAFU CI Test
|
/rerun all |
Results for SNAFU CI Test
|
Results for SNAFU CI Test
|
/rerun all |
Results for SNAFU CI Test
|
I don't have write access, someone will have to resolve the conflict with run_snafu.py. @aakarshg |
@acalhounRH I'll give a quick try |
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 want to see how well Grafana dashboards are going to work with this, I talked with Alex, we need to get to the point where we are looking at real queries from some benchmark and seeing how well prom data integrates into elastic search. but we have to start doing something to kick the InfluxDB habit + copying prometheus data by hand, this seems like a good start. I want to see a better way to get a comprehensive current list of prom metrics, don't understand how to do that yet. Some documentation of how this is done would be nice.
Hey this is a rebase issue, so you'll need to pull down the pr and the master branch and do a rebase ( fixing the merge conflicts ). |
/rerun all |
Hey @acalhounRH, I added some commits to this PR required to solve the dependency issues you're hitting. |
Results for SNAFU CI Test
|
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Results for SNAFU CI Test
|
Thx Raul! |
Hey @acalhounRH, in addition to linting issues there are code issues as well:
Can you please take a look? |
Will start fixing those issue, thanks for the help with resolving those dependency issues. |
set disable_ssl to true remove rate of change reference included initialization of logger
Results for SNAFU CI Test
|
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Results for SNAFU CI Test
|
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Results for SNAFU CI Test
|
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Results for SNAFU CI Test
|
Took a look at the smallfile CI test and its not obvious what exactly was the issue. Could anyone take a look? is this another dependency issue? |
/rerun all |
Results for SNAFU CI Test
|
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.
LGTM!
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.
LGTM
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.
LGTM
Added code to get Prometheus data and index it into Elasticsearch. Note this PR enables the functionality but does not use it. follow-on PRs will address specific tool triggers for Prometheus data collection.
Expected data flow would be that at the conclusion of a sample loop, the tool wrapper would yield a tuple (action, "get_prometheus_trigger"), this would trigger the collection of Prometheus data.
"action"(dict) would contain the following:
test_config would contain the sample specific test parameters that align to the current time window.
@jtaleric @bengland2 @dry923 @aakarshg