-
Notifications
You must be signed in to change notification settings - Fork 711
Introducing an example app with otel integration #129
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
Introducing an example app with otel integration #129
Conversation
Creeating an example app that can be extended as additional opentelemetry integration is completed.
integration-example can only be installed when all other requirements have been.
@@ -0,0 +1,12 @@ | |||
OpenTelemetry Integration 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.
The term "Integration" is already in use for our "ext" packages. Maybe "Example application monitored with OpenTelmetry"?
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.
good point. can do. How about the package name is that "opentelemetry-example"?
OpenTelemetry Integration Example | ||
================================= | ||
|
||
This repository serves as a complete example integration with OpenTelemetry. |
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 repository serves as a complete example integration with OpenTelemetry. | |
This package serves as a complete example integration with OpenTelemetry. |
And same concerns with "integration".
|
||
This repository serves as a complete example integration with OpenTelemetry. | ||
|
||
The purpose is to provide a reference for consumers for using the opentelemetry API and SDK to get set up and to use it for various use cases. |
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 purpose is to provide a reference for consumers for using the opentelemetry API and SDK to get set up and to use it for various use cases. | |
The purpose is to provide a reference for consumers that demonstrates how to use the OpenTelemetry API and SDK in a variety of use cases and how to set it up ´. |
"flask", | ||
"requests", | ||
], | ||
extras_require={}, |
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.
Can't we leave that out?
# the preferred implementation of these objects must be set, | ||
# as the opentelemetry-api defines the interface, but not | ||
# the implementation. | ||
trace.set_preferred_tracer_implementation(lambda T: Tracer()) |
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.
trace.set_preferred_tracer_implementation(lambda T: Tracer()) | |
trace.set_preferred_tracer_implementation(lambda _t: Tracer()) |
# Start by configuring all objects required to ensure | ||
# a complete end to end workflow. | ||
# the preferred implementation of these objects must be set, | ||
# as the opentelemetry-api defines the interface, but not |
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.
"but only provides a no-op implementation"
# the implementation. | ||
trace.set_preferred_tracer_implementation(lambda T: Tracer()) | ||
# Integrations are the glue that binds the opentelemetry API | ||
# and the frameworks and libraries that are used, injecting |
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.
# and the frameworks and libraries that are used, injecting | |
# and the frameworks and libraries that are used together, injecting |
trace.set_preferred_tracer_implementation(lambda T: Tracer()) | ||
# Integrations are the glue that binds the opentelemetry API | ||
# and the frameworks and libraries that are used, injecting | ||
# context propagation and the appropriate span tags |
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'd replace that "injecting ..." part with "automatically creating Spans and propagating contexts as appropriate."
Nice work, such a full example is definitely something we should have! |
I like it, I think this example is quite useful.
|
# as the opentelemetry-api defines the interface, but not | ||
# the implementation. | ||
trace.set_preferred_tracer_implementation(lambda T: Tracer()) | ||
# Integrations are the glue that binds the opentelemetry API |
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.
# Integrations are the glue that binds the opentelemetry API | |
# Integrations are the glue that binds the OpenTelemetry API |
TODO: | ||
|
||
* exporters? | ||
* configure propagators / formatters |
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.
Curious, is formatters the same as processors?
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.
no, I think I misread the spec an have been calling it formatters when I meant propagators: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-propagators.md
I think there's some terminology that could be clarified there, but I'll align with the correct terminology for now.
|
||
This repository serves as a complete example integration with OpenTelemetry. | ||
|
||
The purpose is to provide a reference for consumers for using the opentelemetry API and SDK to get set up and to use it for various use cases. |
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 purpose is to provide a reference for consumers for using the opentelemetry API and SDK to get set up and to use it for various use cases. | |
The purpose is to provide a reference for consumers for using the OpenTelemetry API and SDK to get set up and to use it for various use cases. |
Nice! This is awesome. Just wondering, if these examples are going to be user facing, should we run the whole set of tox commands on this package as well, (isort, black, lint, etc...) for consistency? |
+1 on the README. I will add that. The intent is to also illustrate how to use it. I'll add a useless span example, but I think we should be able to get more useful examples as we flesh out the library and identify more complex cases. Didn't realize that linting didn't cover this. will fix in upcoming commit. |
Addressing grammar changes. Adding all source code in the opentelemetry root to isort, pylint, flake8, and black. Including a span example in the app. renaming to "opentelemetry-example-app": omits the use of the word integration which already has a definition.
pylint opentelemetry-api/src/opentelemetry opentelemetry-api/tests/ opentelemetry-sdk/src/opentelemetry opentelemetry-sdk/tests/ ext/opentelemetry-ext-http-requests/src/ ext/opentelemetry-ext-http-requests/tests/ ext/opentelemetry-ext-wsgi/tests/ | ||
flake8 opentelemetry-api/src/ opentelemetry-api/tests/ opentelemetry-sdk/src/ opentelemetry-sdk/tests/ ext/opentelemetry-ext-wsgi/src/ ext/opentelemetry-ext-wsgi/tests/ ext/opentelemetry-ext-http-requests/src/ | ||
isort --check-only --diff --recursive opentelemetry-api/src opentelemetry-sdk/src ext/opentelemetry-ext-wsgi/src ext/opentelemetry-ext-wsgi/tests ext/opentelemetry-ext-http-requests/src/ | ||
black --check --diff . |
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.
Cool, didn't know this was possible. But makes sense since black doesn't need to know about package structure.
flake8 opentelemetry-api/src/ opentelemetry-api/tests/ opentelemetry-sdk/src/ opentelemetry-sdk/tests/ ext/opentelemetry-ext-wsgi/src/ ext/opentelemetry-ext-wsgi/tests/ ext/opentelemetry-ext-http-requests/src/ | ||
isort --check-only --diff --recursive opentelemetry-api/src opentelemetry-sdk/src ext/opentelemetry-ext-wsgi/src ext/opentelemetry-ext-wsgi/tests ext/opentelemetry-ext-http-requests/src/ | ||
black --check --diff . | ||
pylint opentelemetry-api/src/opentelemetry \ |
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.
👍 finally one can read the toxfile again 😀
opentelemetry-example-app/src/opentelemetry_example_app/ \ | ||
opentelemetry-example-app/tests/ | ||
flake8 . | ||
isort --check-only --diff --recursive . |
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.
Can isort properly distinguish internal and external imports with that (or does it matter at all)?
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.
A little digging here, but it does look like it matters:
https://isort.readthedocs.io/en/latest/#how-does-isort-work
But this shouldn't be affected by the directory it runs as because:
As isort determines third-part vs stdlib via importing the code, which relies on the package to be installed via tox, this shouldn't be an issue.
Also all existing import orders are unchanged.
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. Later we might want to revisit if one example package could cover all major scenarios or we might need multiple examples.
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, looks like a great start and should be helpful for both users and ourselves during development.
opentelemetry-example-app/setup.py
Outdated
|
||
setuptools.setup( | ||
name="opentelemetry-example-app", | ||
version="0.0.1alpha0", |
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.
Not 0.1.dev0
like the others?
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 change.
Creating an example app that has existing opentelemetry components configured. Baseline to add more as more components are added.