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

Consider to add OpenTelemetry support #1208

Open
qiaoleiatms opened this issue Sep 26, 2023 · 5 comments
Open

Consider to add OpenTelemetry support #1208

qiaoleiatms opened this issue Sep 26, 2023 · 5 comments
Labels

Comments

@qiaoleiatms
Copy link

qiaoleiatms commented Sep 26, 2023

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

  1. Need to know the success/fail for each phase.
  2. For detect phase, need to know which BP pass the detection and which is not.
  3. For build phase, besides the success/fail and also the time duration for each BP.
  4. For export phase, besides the success/fail and also the time duration.
  5. Telemetry should be disabled by default, and enabled by a "OPEN_TELEMTRY_ENABLED=true" (or whatever provided) flag
  6. Telemetry endpoint should be available to be configured over another flag, such as OPEN_TELEMETRY_ENDPOINT

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

@qiaoleiatms qiaoleiatms changed the title Considering to add OpenTelemetry support Consider to add OpenTelemetry support Sep 26, 2023
@joshwlewis
Copy link
Member

@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)?

@qiaoleiatms
Copy link
Author

Hi @joshwlewis thanks for checking this. To me, the priority is:

  1. metrics
  2. tracing
  3. logs

With the metrics, we're able to have a quick overview on the service availability

@natalieparellano
Copy link
Member

natalieparellano commented Sep 27, 2023

@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.

@jjbustamante
Copy link
Member

Some related work from Paketo folks

@qiaoleiatms
Copy link
Author

qiaoleiatms commented Oct 9, 2023

@natalieparellano already submitted a PR for RFC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants