-
Notifications
You must be signed in to change notification settings - Fork 821
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
feat: make prometheus config preventServerStart optional #1375
feat: make prometheus config preventServerStart optional #1375
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1375 +/- ##
=======================================
Coverage 93.18% 93.18%
=======================================
Files 156 156
Lines 4854 4854
Branches 986 986
=======================================
Hits 4523 4523
Misses 331 331
|
*/ | ||
startServer?: boolean; | ||
startServer: boolean; |
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.
Why did you make this configuration option required? Should it not just default to 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.
The reason startServer
defaults to false have been stated at the description of the PR "it grabs a port on the host computer. This type of thing is best left explicit so the user is not surprised" -- which is copy-pasted from previous Gitter chat history I considered as a fair reason (unfortunately Gitter doesn't provide chat history links).
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 am leaning towards default to true, prometheus is meant to be scraped in most cases. The default port of 9464
is meant for this as per https://github.com/prometheus/prometheus/wiki/Default-port-allocations
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 believe the gitter chat @legendecas referenced was actually me :)
Think I see this one both ways. It is unfortunate that we have to grab a port, but the exporter really is useless without it so I would say it's probably ok to just do it.
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 would argue that boolean parameter should be ever required. By default anything what is boolean and is not defined is simply false
, we should not change it, In js if user doesn't define config we will have "an object undefined exception", I don't see any reason why we should have it. And just writing everywhere
startServer: false
doesn't look very intuitive why would you even want that
@@ -68,17 +68,13 @@ describe('PrometheusExporter', () => { | |||
} | |||
); | |||
}); | |||
|
|||
it('should not start the server by default', () => { |
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 this test is still relevant , if user doesn't provide anything (when using in pure js for example) the server should not start right ?
@@ -59,7 +58,7 @@ export class PrometheusExporter implements MetricExporter { | |||
* @param config Exporter configuration | |||
* @param callback Callback to be called after a server was started | |||
*/ | |||
constructor(config: ExporterConfig = {}, callback?: () => void) { | |||
constructor(config: ExporterConfig, callback?: () => void) { |
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 this should not be changed, if in js user will not define any config we don't want the error "object is undefined" to be thrown.
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.
@legendecas any update here?
Maybe a better option is to rename |
@legendecas what do you think about inverting the name to |
serverless? 😄 |
I'm good with that, will do a quick update late today. But I'm wondering what the use case will be if we set |
@legendecas we could just remove the option entirely, but then there is no way for the user to stop the exporter from grabbing a port. The usecase is admittedly entirely theoretical, but one could imagine a user that wants to defer server start until some precondition is met like waiting for a port to become available. |
# Conflicts: # packages/opentelemetry-exporter-prometheus/src/prometheus.ts # packages/opentelemetry-exporter-prometheus/test/PrometheusExporter.test.ts
@dyladan @obecny @naseemkullah @mayurkale22 the |
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
is this still a breaking change now @dyladan ? |
…elemetry#1375) * fix(instrumentation-fs): fix instrumentation of `fs/promises` * Revert "fix(instrumentation-fs): fix instrumentation of `fs/promises`" This reverts commit 90d9f0d68960ef647bbe5b7347ad6c97f936651e. * fix(instrumentation-fs): fix instrumentation of `fs/promises` * chore(instrumentation-fs): fix lint error * chore(instrumentation-fs): hard-code `R_OK` value for node 14 * chore(instrumentation-fs): fix supported version for `fs/promises` * chore(instrumentation-fs): incorporate changes from open-telemetry#1332 * chore(instrumentation-fs): consolidate common test utilities --------- Co-authored-by: Haddas Bronfman <[email protected]>
Which problem is this PR solving?
There are a couple of reasons to leave thePrometheusExporterConfig.startServer
false
by default. First, it is async so we have another call that a user can do asynchronously so they can ensure it actually started. Second, it grabs a port on the host computer. This type of thing is best left explicit so the user is not surprised.However, by most situations (and in examples), the
startServer
config was mostly set totrue
. And it is quite easy to forget to set the config and failed to find the Prometheus working as expected. In this situation, it can be very helpful to start the server by default and provide an option to prevent the server from starting (grabbing a port from the host).Short description of the changes
startServer
is replaced bypreventServerStart
.