-
Notifications
You must be signed in to change notification settings - Fork 626
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
Add IDs Generator as Configurable Property of Auto Instrumentation #1404
Conversation
1c7fe9b
to
75ff8a6
Compare
75ff8a6
to
fcfcbf1
Compare
62bde4f
to
fc1224f
Compare
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.
Thanks! This is great.
A couple small changes, but looking really good!
@@ -47,6 +47,19 @@ def parse_args(): | |||
""", | |||
) | |||
|
|||
parser.add_argument( | |||
"-g", |
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.
do we need a shortflag? IMO it's better to keep those to more general configuration, like version, help, etc.
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.
Sure I agree with you! I had a hard time thinking of a letter, and so I don't think it'll be as easy to use as I had hoped, will use just the long version.
ids_generator_impl = None | ||
|
||
for id_generator in iter_entry_points("opentelemetry_ids_generator"): | ||
if id_generator.name == ids_generator_name.strip(): |
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 deviate from the behavior of the exporters and perform a strip on the passed generator name?
Although it helps in a rare handful of cases, I think it's better to just perform no mutation on user input.
Alternatively, exporter and ids_generator should have the same mutation: strip both or strip none. It's minor, but the most confusing thing to a user is inconsistency.
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 was actually under the impression that exporter did strip the value:
Lines 48 to 49 in 8660dea
for exp in exporter.split(","): | |
name = exp.strip() |
Either way I think stripping the value is a good idea, I would expect
opentelemetry-instrument --ids-generator aws_xray
and
opentelemetry-instrument --ids-generator aws_xray
to work the same. But not sure if my second example would have whitespace to begin with 😅
...lemetry-instrumentation/src/opentelemetry/instrumentation/auto_instrumentation/components.py
Show resolved
Hide resolved
@patch.dict( | ||
environ, {"OTEL_SERVICE_NAME": "my-random-ids-generator-test-service"} | ||
) | ||
def test_trace_init_default_random_ids_generator(self): |
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.
is it worth testing the environment variable configuring the ids_generator?
If you don't, there's a risk that someone may modify that code to not work, and we'd have no way of validating programmatically.
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.
Yes it is worth it, I was just unfamiliar with how to do so but I agree it's worth it :) I've spent quite some time learning how to do it and finally figured out how to add it because I also think it's a useful add! Please let me know what you think!
self.assertIsInstance(provider, Provider) | ||
self.assertIsInstance(provider.ids_generator, RandomIdsGenerator) | ||
self.assertIsInstance(provider.processor, Processor) | ||
self.assertIsInstance(provider.processor.exporter, OTLPExporter) |
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 verify things like the exporter, processor, provider? It's a bit harder to see what this test is trying to verify, when you include assertions for things that aren't related.
I'd argue if you are worried about those, they should be split out into smaller tests. It helps future developers more quickly find what behavior has regressed.
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 can go either way with this, I think it's useful to know that in a test where "I changed only one thing" the other parts of the functionality here still work.
However cleanliness is nice if I remove the rest of the checks, so I have removed them!
9401751
to
70e885f
Compare
70e885f
to
2c60b89
Compare
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.
Looks good, only question i have is non-blocking
@@ -70,6 +82,8 @@ def load_config_from_cli_args(args): | |||
environ["OTEL_EXPORTER"] = args.exporter | |||
if args.service_name: | |||
environ["OTEL_SERVICE_NAME"] = args.service_name | |||
if args.ids_generator: | |||
environ["OTEL_IDS_GENERATOR"] = args.ids_generator |
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.
there should be a proposal to the spec around this env variable
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.
Will follow up with this soon!
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, thanks!
Description
As a follow up to #1036, this PR adds a parameter to the
opentelemetry-instrument
executable to allow the IDs Generator to be configurable.This is a necessary part for auto instrumentation with backends which need custom IDs, because once the
opentelemetry-instrument
executable sets up theTracerProvider
, it is too late for the instrumented downstream application to configure the IDs.Type of change
Please delete options that are not relevant.
Checklist: