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

feat(opentelemetry-exporter-prometheus): export PrometheusSerializer #3034

Merged
merged 5 commits into from
Jun 17, 2022

Conversation

matschaffer
Copy link
Contributor

@matschaffer matschaffer commented Jun 13, 2022

Which problem is this PR solving?

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #3033

Short description of the changes

Exports PrometheusSerializer from opentelemetry-exporter-prometheus

Type of change

Please delete options that are not relevant.

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

The existing test has been switched to include PrometheusSerializer from the package-level export.

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@matschaffer matschaffer requested a review from a team June 13, 2022 06:09
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jun 13, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@codecov
Copy link

codecov bot commented Jun 13, 2022

Codecov Report

Merging #3034 (a56beed) into main (5f9ef51) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #3034   +/-   ##
=======================================
  Coverage   92.64%   92.64%           
=======================================
  Files         187      187           
  Lines        6169     6169           
  Branches     1303     1303           
=======================================
  Hits         5715     5715           
  Misses        454      454           
Impacted Files Coverage Δ
...ry-exporter-prometheus/src/PrometheusSerializer.ts 95.12% <100.00%> (ø)

@vmarchaud
Copy link
Member

@matschaffer I don't think thats an issue to re-use it however you'll need to add a entry in experimetanl/CHANGELOG.md and sign the CLA so we can accept the contribution !

@matschaffer
Copy link
Contributor Author

Thanks @vmarchaud ! Should be all set on those points.

@weyert
Copy link
Contributor

weyert commented Jun 13, 2022

Can’t you use the request handler that’s available on PrometheusExporter?

I am using exporter. getMetricsRequestHandler(req, res)

@matschaffer
Copy link
Contributor Author

@weyert I tried that but didn't see a good way to map from the KibanaResponseFactory API (https://github.com/elastic/kibana/blob/fa89c459ac71a9c911a5a2cc486dd3eff120d484/src/core/server/http/router/response.ts#L117) to ServerResponse.

Similarly I wasn't sure how to cleanly pass in the unused IncomingMessage without an ugly as any.

Can you share the code you ended up using?

@weyert
Copy link
Contributor

weyert commented Jun 14, 2022

Oh sorry, I am not well versed in Kibana but I had a quick look and at first sight it looked
like you could use: https://github.com/elastic/kibana/blob/fa89c459ac71a9c911a5a2cc486dd3eff120d484/src/core/server/http/router/router.ts#L338

I am using it with Express so having less of a problem but I am doing something like:

this_app.use((req, res) => {
    If (this._exporter) {
           this.exporter.getMetricsRequestHandler(req, res)
    } else {
          res.status(404).json({ message: ‘Not OK })
    }
})

@matschaffer
Copy link
Contributor Author

Thanks! I'll give another crack at it today.

It feels like a bit of extra overhead to have a server-off PrometheusExporter as compared to a reusable PrometheusSerializer. But maybe the smaller public API surface area is worth that trade off.

@weyert
Copy link
Contributor

weyert commented Jun 14, 2022

Yeah, that’s why I am using the handler and the prevent the server form starting to avoid a second server instance just for th metrics endpoint. That was my main reason for introducing the method in the past

@matschaffer
Copy link
Contributor Author

matschaffer commented Jun 14, 2022

@vmarchaud @weyert so while getMetricsRequestHandler is handy for express cases, I don't think I can use it in a Kibana API. There are services upstream of me that need to ensure appropriate headers on responses as well.

To use that API I'd have to feed it an instantiated ServerResponse then read back & parse just the body to pass into KibanaResponseFactory.

As such I'd like to propose we merge this API. That will enable me to use the PrometheusSerializer directly from my own kibana-compatible version of the PrometheusExporter.

As shown on elastic/kibana#128755 (comment), the approach is functional but it'd be great not to have to fork PrometheusSerializer into the kibana repo to do so.

Thanks in advance!

@weyert
Copy link
Contributor

weyert commented Jun 14, 2022

No worries, I just tried to unblock you . Happy with the PR myself. I have approved it as an outsider ;)

Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

I'm good with exposing the PrometheusSerializer. But I still would like to minimize the surfaced interfaces, i.e. hide all methods as private and leave the basic PrometheusSerializer.serialize as public.

Would you mind taking that part of the work? Or I can help to do the chore.

@matschaffer
Copy link
Contributor Author

matschaffer commented Jun 15, 2022

@legendecas easy enough. I'll put it on my list for tomorrow. Thanks for the feedback 🧡

@matschaffer
Copy link
Contributor Author

@legendecas does the project have any typical strategy for testing private methods? I was thinking I'll try updating the tests to work via the serialize method.

Some other ideas are:

  • Remove the direct testing: this would leave PrometheusSerializer with only 2 its
  • Use protected and test a public subclass: doesn't really address concern of public API size
  • Use serializer['...']() to route around the type check failures: seems a little "dirty"

@matschaffer
Copy link
Contributor Author

Initial attempts at testing via serialize are looking good so far.

@legendecas
Copy link
Member

@matschaffer generally options 1 and 3 are both fine. We already have practices on 3, i.e. testing with the bracket accessing, as it still preserves type information and TypeScript can properly check the type conformance.

@matschaffer
Copy link
Contributor Author

Thanks for the quick reply! Testing via serialize worked out well I think. Just needed to introduce a helper to skip the comments it adds. Have a look and let me know what you think!

@matschaffer matschaffer force-pushed the export-prometheus-serializer branch from 4b3ac64 to 050ac63 Compare June 16, 2022 02:50
@matschaffer matschaffer force-pushed the export-prometheus-serializer branch from 1c45233 to fb7b15d Compare June 17, 2022 05:25
Using underscore prefix to communicate intention for JS consumers. Also leverage bracket accessing to directly test private methods.
@matschaffer matschaffer requested a review from legendecas June 17, 2022 05:31
Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you for your work on this!

@dyladan dyladan merged commit 3cc40d7 into open-telemetry:main Jun 17, 2022
@matschaffer
Copy link
Contributor Author

Thanks @dyladan !

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.

[opentelemetry-exporter-prometheus] Export PrometheusSerializer
5 participants