-
Notifications
You must be signed in to change notification settings - Fork 867
opentelemetry-sdk: sketch of an OpAMP integration #4646
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
base: main
Are you sure you want to change the base?
Changes from all commits
8734dfa
c53c4c3
99730fd
c0269fa
dd7cef0
830fd1b
2298f14
f7e07b3
e859bfe
8e79bfc
1691294
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -554,6 +554,33 @@ def _import_id_generator(id_generator_name: str) -> IdGenerator: | |
| raise RuntimeError(f"{id_generator_name} is not an IdGenerator") | ||
|
|
||
|
|
||
| def _import_opamp() -> Callable[[Resource], None] | None: | ||
| # this in development, at the moment we are looking for a callable that takes | ||
| # the resource and instantiate an OpAMP agent. | ||
| # Since configuration is not specified every implementers may have its own. | ||
| # Refer to opentelemetry-opamp-client package on how to setup the OpAMP agent. | ||
| entry_point = None | ||
| try: | ||
| entry_point = next( | ||
| iter( | ||
| entry_points( | ||
| group="_opentelemetry_opamp", name="pre_sdk_init_function" | ||
| ) | ||
| ) | ||
| ) | ||
| return entry_point.load() | ||
| except StopIteration: | ||
| _logger.debug("No OpAMP init function found") | ||
| except AttributeError as exc: | ||
| _logger.warning( | ||
| "Failed to load OpAMP init function from entry point, %s: %s", | ||
| entry_point, | ||
| exc, | ||
| ) | ||
|
|
||
| return None | ||
|
|
||
|
|
||
| def _initialize_components( | ||
| auto_instrumentation_version: str | None = None, | ||
| trace_exporter_names: list[str] | None = None, | ||
|
|
@@ -618,6 +645,15 @@ def _initialize_components( | |
| # from the env variable else defaults to "unknown_service" | ||
| resource = Resource.create(resource_attributes) | ||
|
|
||
| # OpAMP is a system created to configure OpenTelemetry SDKs with a remote config. | ||
| # This is different than other init helpers because setting up OpAMP requires distro | ||
| # provided code as it's not strictly specified. We call OpAMP init before other code | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In my distro I initialize the OpAMP client after the sdk has been setup but can't exclude other scenarios
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we add this a SIG topic to get the execution order?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've renamed the entry point to |
||
| # because people may want to have it blocking to get an updated config before setting | ||
| # up the rest of the SDK. | ||
| _init_opamp = _import_opamp() | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My org is interested in using OpAMP first to report effective SDK configuration. For that use case, it would be convenient if there were also an OpAMP hook after With only a pre-init hook, the OpAMP implementation would have to re-create or re-invoke parts of the SDK configuration logic and infer the effective config, or it would have to poll the global providers and traverse the private object graphs after an arbitrary delay. I can see the value of the current pre-init hook for influencing initial configuration before providers are wired, but a post-init hook seems useful for reporting effective config. This could be a separate PR. Longer term, maybe it would be better to introduce a configuration controller/object that could be the source of truth for SDK config: it could resolve the config from the supported sources, provide the effective config for reporting, accept updates from OpAMP, and notify listeners when the configuration changes. What do you think? |
||
| if _init_opamp is not None: | ||
| _init_opamp(resource) | ||
|
|
||
| _init_tracing( | ||
| exporters=span_exporters, | ||
| id_generator=id_generator, | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.