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

refactor: Use standard OTel SDK env vars #1142

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

austindrenski
Copy link
Member

@austindrenski austindrenski commented Jan 8, 2024

Closes: #1141


Note

Fully aware that this neither sufficient nor suitable as is, but opening as a companion to #1141 to provide a starting point for discussion/consideration.

@austindrenski austindrenski requested a review from a team as a code owner January 8, 2024 23:28
Copy link

netlify bot commented Jan 8, 2024

Deploy Preview for polite-licorice-3db33c canceled.

Name Link
🔨 Latest commit ab8020e
🔍 Latest deploy log https://app.netlify.com/sites/polite-licorice-3db33c/deploys/659e031b955d330008ff2320

@austindrenski austindrenski force-pushed the try-using-only-standard-otel-env-vars branch 4 times, most recently from 1cf9cdf to ab2e71f Compare January 8, 2024 23:50
@austindrenski austindrenski force-pushed the try-using-only-standard-otel-env-vars branch 10 times, most recently from a8a0560 to 6d99c91 Compare January 10, 2024 01:36
Copy link

codecov bot commented Jan 10, 2024

Codecov Report

Attention: 34 lines in your changes are missing coverage. Please review.

Comparison is base (55dc8cf) 73.53% compared to head (ab8020e) 73.04%.

Files Patch % Lines
core/pkg/telemetry/builder.go 58.97% 31 Missing and 1 partial ⚠️
core/pkg/runtime/from_config.go 0.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1142      +/-   ##
==========================================
- Coverage   73.53%   73.04%   -0.49%     
==========================================
  Files          32       32              
  Lines        3113     3135      +22     
==========================================
+ Hits         2289     2290       +1     
- Misses        717      740      +23     
+ Partials      107      105       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@austindrenski austindrenski force-pushed the try-using-only-standard-otel-env-vars branch 2 times, most recently from 9624a97 to f01ad47 Compare January 10, 2024 01:48
@austindrenski austindrenski force-pushed the try-using-only-standard-otel-env-vars branch from f01ad47 to ab8020e Compare January 10, 2024 02:38
@austindrenski
Copy link
Member Author

Full transparency, I'm still relatively new to golang, so please take everything I've written here with a grain of salt.

That said, I think this is in a decent place for a first round of reviews.

Areas of concern/in need of feedback:

  • Should telemetry wire-up ever return errors?
    • OTel SDKs tend to err on the side of never break the app no matter what
    • Existing behavior returns errors in some cases.
    • But on some new code paths I've opted to log debug messages instead of returning errors, based on the rationale that if we're deferring to the OTel SDK for wire-up, then we should defer to its style of graceful failure too.
    • Mostly asking this question for my edification in the event that this is something the project already has a strong opinion on.
  • The tests are passing...but I also may have broken the intent of one or more of the tests.
    • Some of the tests were related to the above should we error question, so just looking for feedback here on what the project/org expects in terms of coverage/quality in tests (on both fronts, I expect what is currently here will probably need some work).
  • Do we/anyone have a well-defined/formal integration environment? Are the unit tests that environment? How would we know if I've borked something subtle here?

Anyways, please have at it and let me know what you think 🙇

(and again, I'm still new to golang, so if you see garbage code, please call it out for being garbage code, rather get the feedback sooner rather than later lol)

@beeme1mr
Copy link
Member

I think this is a good idea, but I would prefer to make this a non-breaking change. We can mark the arguments as deprecated and completely remove them at a later point. I think we can make the existing arguments and environment variables into the official OTel environment variables.

@austindrenski
Copy link
Member Author

I think this is a good idea, but I would prefer to make this a non-breaking change. We can mark the arguments as deprecated and completely remove them at a later point. I think we can make the existing arguments and environment variables into the official OTel environment variables.

Okay, that makes sense. I started this PR just as a sample to gauge interest, so went in axe swinging, but can definitely scale back the frontend changes.

I'll take another pass to bring those frontend flags/envs back and try to get everything aligned with @thisthat's comments in #1141 (comment).

@austindrenski
Copy link
Member Author

FYI waylaid by some other priorities, but this is still on my radar.

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.

[FEATURE] flagd should use standard OTel SDK env vars
2 participants