-
Notifications
You must be signed in to change notification settings - Fork 410
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 Prometheus Exporter: Step 3 - PrometheusExporter class #263
Conversation
Codecov Report
@@ Coverage Diff @@
## master #263 +/- ##
=======================================
Coverage 94.59% 94.59%
=======================================
Files 146 146
Lines 6629 6629
=======================================
Hits 6271 6271
Misses 358 358 |
*/ | ||
void PrometheusExporter::Shutdown() noexcept | ||
{ | ||
is_shutdown_ = true; |
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.
Is Shutdown called from a different thread? Should there be a lock here?
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.
After looking into it, it seems as though Shutdown() will never be called by the controller in the SDK, since the Metrics Exporter Interface does not require a shutdown function - is there any benefit to keeping this in? If yes, then it seems we might need a lock here.
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.
What does the specification say about exporter shutdowns?
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.
It seems that it is not required for metrics exporters currently, but is required for span exporters. Here is the requirement for span exporters, but looking at the shutdown function in the ostream metrics exporter, it is mentioned but not required.
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.
At some point this might be nice to have. I think Ryan was saying that e.g. Envoy wants to be able to handle SIGHUP by completely shutting everything down, changing the config, and then bringing it back up.
Maybe the right answer is to punt on Shutdown for now and just leave a TODO? Idk.
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.
Maybe we can comment the shutdown function out, and add a TODO comment once the metrics specification adds a requirement for a shutdown?
@reyang The CI/CMake test isn't passing the check here- the unit tests for this class all fail, and after further testing, it seems as if they fail independent of the actual outcome of the test. There seems to be a problem within the CI setup but after trying to debug it for the better part of a day I cannot seem to reproduce the error locally, so I was wondering if you might have any insight into this. Additionally, the bazel valgrind test fails but it seems as if this is due to something within the otlp exporter test, so I think we can safely ignore this. |
@erichsueh3 |
@lalitb thanks for the suggestion, I've made the changes but unfortunately it seems like I'm still running into the same problem. |
@erichsueh3 Seems issue is easily reproducible with below set of commands locally from root directory of your repo clone ( i.e, running test within ubuntu docker container )
Can you try debugging using these steps in case this is test case issue, else I will look into it. |
Seems like I was able to reproduce this locally now, and it still seems that regardless of what a test case's body is, the test will fail. For example, a test body that looks like
still fails. |
@erichsueh3 no worries I will look into it further. If there are further pending PRs dependend on this one, you can comment out prometheus test cpp from cmake so that these tests are ignored for now. This will allow you for merge request. We will debug and add it back once fixed. Thanks for your contributions :) |
Sorry to post on an old / closed issue, just curious if there is any interest in getting this across the finish line? Looks like its abandoned from an internship ending. I know in one of the discussions (#952) it was mentioned that metrics was still be redesigned - but in the meantime, its been useful to us to have a Prometheus exporter. We're actually using code based on this PR currently. I / our team at @rapidrobotics would be able to work on any changes needed to get this in and support it if there is interest. Happy to jump on a call to discuss what needs to be done if so. Also happy going forward to make adjustment as needed if / when the metrics stuff does change. |
@compscidr metrics specs is now stable, and implementation work is ongoing. Feel free to join the community meeting and we can discuss further. |
@esigo Seems I can't reopen this PR as it is targeted to the old |
This PR implements the PrometheusExporter class and its header, source, test, and build files. This class is derived from the Metrics Exporter Interface and allows for export of Prometheus metrics data.
This PR is one in a series of PRs that aims to add a full implementation of a Prometheus Exporter within the OpenTelemetry C++ library.
Note to reviewers: Please keep in mind that this PR is dependent on the Metrics Exporter Interface PR (#240), the Prometheus Collector Implementation PR (#282 ), and the Prometheus Exporter Utils PRs (#280) so codecov tests may not fully pass.