-
Notifications
You must be signed in to change notification settings - Fork 112
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
Consider to add OpenTelemetry support #1208
Comments
@qiaoleiatms thanks for bringing this up. I have been in talks about something like this with the buildpacks team myself. I presume you'd want OpenTelemetry tracing (rather than metrics or logs)? |
Hi @joshwlewis thanks for checking this. To me, the priority is:
With the metrics, we're able to have a quick overview on the service availability |
@qiaoleiatms @joshwlewis thanks for starting this conversation. I think the ideal next step would be to start an RFC so we can formalize how this would be integrated within the lifecycle, pack, and buildpacks. Would either of you be interested in starting this and pushing it forward? Edit: we put this on the agenda for tomorrow's Working Group meeting which is at 2p UTC this week. |
Some related work from Paketo folks |
@natalieparellano already submitted a PR for RFC |
Summary
For a better monitoring on the running state of build service which leveraging buildpacks library, please consider add OpenTelemetry support on phases
Here's the golang version SDK of OpenTelemetry:
https://opentelemetry.io/docs/instrumentation/go/
Proposal
Context
We're running build service to enable multi-language build support in multi-tenant environment. Sometimes part of the users may encounter failures when a BP is not able to download the dependencies due to network connection issue. While sometime, the overall build is extreme slow.
For a better understanding on the service availability and detailed statistics of BP, please consider add OpenTelemetry support
The text was updated successfully, but these errors were encountered: