-
Notifications
You must be signed in to change notification settings - Fork 7
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
python configuration prototype #44
Conversation
prototypes/python/otel.py
Outdated
@@ -0,0 +1,119 @@ | |||
|
|||
import importlib |
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.
Nit, use from x import y
Question about the processor names - what is the reason that the name includes the exporter name after the slash? I can see it as a more descriptive name, but the type of the processor will have to be parsed from the name. |
It's probably not necessary, since the name is really identifying the type of processor this is and not used as a unique identifier anywhere else. I suppose it could make returning an error when configuring a specific processor a bit more easy to identify, but it's probably not needed at this time |
c67d0fe
to
e45b943
Compare
Signed-off-by: Alex Boten <aboten@lightstep.com>
Updated the list of propagators to an array of strings. Renamed *_provider to the name of the signal instead. This makes searching the parsed configuration a bit cleaner, since exporters are configured per signal, and not necessarily per provider (at least conceptually i found it easier to grok). Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
159b1b5
to
bacb1d4
Compare
|
||
import logging | ||
from typing import List, Sequence, Tuple | ||
from pkg_resources import iter_entry_points |
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 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.
Ah good to know. It's probably ok for the prototype but wouldn't want to ship this code :D
def _resource(self): | ||
# resource detection | ||
# attributes | ||
from opentelemetry.sdk.resources import Resource |
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 import here?
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 necessary to have the import in the method, that was just me being lazy
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.
Just some comments
Closing in favour of open-telemetry/opentelemetry-configuration#54 |
Here's the start of the python prototype. Specifically here, I wanted to test out the ergonomics of using the dictionary object parsed from the config file. I've updated a couple of things in the schema/config file as a result which I'm not opposed to changing back but here's the list of changes:
type/identifier
namingThe code as is supports configuring a console exporter, and turning on/off the SDK. I will continue adding more interpretation of the configuration in the future. The only interface users would interact with is shown in
prototype.py
as the following: