-
Notifications
You must be signed in to change notification settings - Fork 649
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
Fix to run the Auto instrumentation example in the docs #1435
Conversation
merging from opentelemetry/master
This PR is a solution to fix issue open-telemetry/opentelemetry-specification#1432 |
Modifying the README.rst accordingly.
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! the DictGetter change looks good, see my notes on the -e none.
merging from upstream/master
merging from origin/master
…s per review comments.
@@ -373,6 +373,7 @@ def __init__( | |||
out: typing.IO = sys.stdout, | |||
formatter: typing.Callable[[Span], str] = lambda span: span.to_json() | |||
+ os.linesep, | |||
**kwargs |
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.
This change will be required else the code in init_tracing method
provider.add_span_processor(
BatchExportSpanProcessor(exporter_class(**exporter_args))
)
fails with error "unexpected argument" service name.
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.
got it! thanks.
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.
thank you!
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.
Shouldn't we only add service_name
as an argument?
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 could add a default parameter service_name=None. I thought of adding **kwargs because in future if additional parameters get passed, we might have to come back and change again.
I could still go ahead and make the change suggested. Please let me know.
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.
**kwargs is more robust but this service_name
requirement is restriction placed on the constructors by an external component (auto-instrumentation), which is not ideal. If changes happen in the future if we want to pass additional configurable parameters via auto-instrumentation, all of these parameters must be added to the separate exporters that currently are supported (zipkin, jaeger, etc.), so this would have to be addressed regardless. For now, it is better to keep these parameters explicit so we know which ones are available and are needed to exist for this auto-instrumentation feature.
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.
@lzchen ok got it. Will make the changes.
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.
@lzchen - The tests seems to fail with an error "GitHub Actions has encountered an internal error when running your job.
". I ran all the tests locally (except pypy3) and they were passing.
Any pointers to understand whether its my failure or a general failure would be helpful.
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.
Great! Thanks for the change.
…rter since some py35-exporter-zipkin test were failing.
@lzchen , Thanks for re-triggering the tests 👍 . All the tests have passed. Please let me know if there is anything I need to do before merging the pull request? |
opentelemetry-sdk/setup.cfg
Outdated
console_span = opentelemetry.sdk.trace:ConsoleSpanExporter | ||
console_metrics = opentelemetry.sdk.metrics:ConsoleMetricsExporter |
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.
This fails when testing locally, with the following error:
ImportError: module 'opentelemetry.sdk.trace' has no attribute 'ConsoleSpanExporter'
Currently, there's no ConsoleSpanExporter
import in opentelemetry/sdk/trace/__init__.py
, so the line should be changed to:
console_span = opentelemetry.sdk.trace.export:ConsoleSpanExporter
This is not required for the metrics one, as ConsoleMetricsExporter
exists in opentelemetry/sdk/metrics/__init__.py
, but could be changed too, to avoid issues in the future.
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 think the issue exists for ConsoleMetricsExporter as well so that would also have to be changed.
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.
The changes have been made. @lzchen could you please review and let me know your thoughts?
opentelemetry-sdk/src/opentelemetry/sdk/trace/export/__init__.py
Outdated
Show resolved
Hide resolved
fix the unit tests for the above change.
New test
update the setup.cfg to the correct path of ConsoleMetricsExporter
merging from master
span_json = json.loads(self.formatter(span)) | ||
span_json.update({"service_name": self.service_name}) | ||
self.out.write(json.dumps(span_json, indent=4)) |
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 there any guarantee that the user will always provide a formatter
that converts the span to JSON? Otherwise, a formatter like lambda span: repr(span)
will break this logic.
I don't see an easy way to inject the service_name in the response of span.to_json()
, unless the Span
class is refactored, or Span.attributes
is used (but that would mutate the Span object).
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.
we cannot inject anything to the span after its closed. If my understanding is correct consolespanexporter is only for writing output to the console (for debugging) and its not going to be used in production. i think this could be the reason the the formatter is assigned that way so that it just put the output to the console.
Having said this , my understanding is pretty limited wrt to the project as am pretty to new to it.
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.
@adamantike
That is a good point. The only reason why we needed service_name
is because the auto-instrumentation requires it to exist in the constructor of configured exporters here. We might want to revisit this restriction as to not have to enforce constructors to be a certain way. The usage of service_name
is not mandatory, so for now @dmarar you can just remove the assignment, but just keep it in the constructor.
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 @lzchen will revert the changes.
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 for the clarification, @lzchen!
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.
@lzchen, I have made the necessary changes. Could you please take a look?
merging from upstream master
merging from origin master
"telemetry.sdk.language": "python", | ||
"telemetry.sdk.name": "opentelemetry", | ||
"telemetry.sdk.version": "0.16b1", | ||
"service.name": "" |
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.
"service.name": "" |
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.
@lzchen , this change is not done by me. it comes from the init_tracing code in components.py :
def init_tracing(
exporters: Sequence[SpanExporter], ids_generator: trace.IdsGenerator
):
service_name = get_service_name()
provider = TracerProvider(
resource=Resource.create({"service.name": service_name}),
ids_generator=ids_generator(),
)
trace.set_tracer_provider(provider)
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.
The outputs should be the same for auto-instrumented and manually instrumented. Since you removed service_name
from appearing in the console export, it shouldn't appear for either example.
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.
@lzchen , there was mistake in that output snapshot in previous comment, the service.name was coming irrespective of my change.
The change I made adds an additional "service_name" to the output (please see the output) ( which i removed as per your suggestion)
The code in the init_tracing hasnt been touched by me for any of the changes I did.
My apologies that i realised it very late that output in the previous comment was incorrect.
Please note that "service.name" is not added in the server output if server_instrument.py is run.
Thank you @lzchen, @toumorokoshi . Appreciate your time in reviewing and providing inputs. |
Description
The auto-instrumentation example given in the docs does not work as expected.
The changes were made to make the example work as expected.
Fixes # (issue)
Auto-instrumentation example fix.
Fixes open-telemetry/opentelemetry-specification#1432
Type of change
Code
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Does This PR Require a Contrib Repo Change?
No
Answer the following question based on these examples of changes that would require a Contrib Repo Change:
The OTel specification has changed which prompted this PR to update the method interfaces of
opentelemetry-api/
oropentelemetry-sdk/
The method interfaces of
opentelemetry-instrumentation/
have changedThe method interfaces of
test/util
have changedScripts in
scripts/
that were copied over to the Contrib repo have changedConfiguration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in
pyproject.toml
isort.cfg
.flake8
When a new
.github/CODEOWNER
is addedMajor changes to project information, such as in:
README.md
CONTRIBUTING.md
Yes. - Link to PR:
No.
Checklist: