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

Fix to run the Auto instrumentation example in the docs #1435

Merged
merged 24 commits into from
Dec 8, 2020

Conversation

dmarar
Copy link
Contributor

@dmarar dmarar commented Nov 29, 2020

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.

  • Bug fix (non-breaking change which fixes an issue)

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

  • Test A

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/ or opentelemetry-sdk/

  • The method interfaces of opentelemetry-instrumentation/ have changed

  • The method interfaces of test/util have changed

  • Scripts in scripts/ that were copied over to the Contrib repo have changed

  • Configuration 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 added

  • Major changes to project information, such as in:

    • README.md
    • CONTRIBUTING.md
  • Yes. - Link to PR:

  • No.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added
  • Documentation has been updated

@dmarar dmarar requested a review from a team as a code owner November 29, 2020 15:27
@dmarar dmarar requested review from toumorokoshi and hectorhdzg and removed request for a team November 29, 2020 15:27
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Nov 29, 2020

CLA Signed

The committers are authorized under a signed CLA.

@dmarar
Copy link
Contributor Author

dmarar commented Nov 29, 2020

This PR is a solution to fix issue open-telemetry/opentelemetry-specification#1432

Modifying the README.rst accordingly.
Copy link
Member

@toumorokoshi toumorokoshi left a 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.

docs/examples/auto-instrumentation/README.rst Outdated Show resolved Hide resolved
@@ -373,6 +373,7 @@ def __init__(
out: typing.IO = sys.stdout,
formatter: typing.Callable[[Span], str] = lambda span: span.to_json()
+ os.linesep,
**kwargs
Copy link
Contributor Author

@dmarar dmarar Nov 30, 2020

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it! thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you!

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

@toumorokoshi toumorokoshi left a 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.

@dmarar dmarar changed the title [WIP] Fix to run the Auto instrumentation example in the docs Fix to run the Auto instrumentation example in the docs Dec 1, 2020
@dmarar
Copy link
Contributor Author

dmarar commented Dec 3, 2020

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

Comment on lines 57 to 58
console_span = opentelemetry.sdk.trace:ConsoleSpanExporter
console_metrics = opentelemetry.sdk.metrics:ConsoleMetricsExporter
Copy link
Contributor

@adamantike adamantike Dec 4, 2020

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Comment on lines 386 to 388
span_json = json.loads(self.formatter(span))
span_json.update({"service_name": self.service_name})
self.out.write(json.dumps(span_json, indent=4))
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

@lzchen lzchen Dec 7, 2020

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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!

Copy link
Contributor Author

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?

@dmarar dmarar requested a review from lzchen December 4, 2020 19:18
"telemetry.sdk.language": "python",
"telemetry.sdk.name": "opentelemetry",
"telemetry.sdk.version": "0.16b1",
"service.name": ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"service.name": ""

Copy link
Contributor Author

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)

Copy link
Contributor

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.

Copy link
Contributor Author

@dmarar dmarar Dec 8, 2020

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)
auto-instru-example1

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.

@lzchen lzchen added the Skip Changelog PRs that do not require a CHANGELOG.md entry label Dec 8, 2020
@lzchen lzchen merged commit 5450e6d into open-telemetry:master Dec 8, 2020
@dmarar
Copy link
Contributor Author

dmarar commented Dec 8, 2020

Thank you @lzchen, @toumorokoshi . Appreciate your time in reviewing and providing inputs.

@dmarar dmarar deleted the auto-instru-example-fix branch December 8, 2020 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Skip Changelog PRs that do not require a CHANGELOG.md entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[docs] auto-instrumentation example needs to be updated.
4 participants