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

Inject SDK & environment variables but do not autoinstrument with init container #2681

Closed
sy-be opened this issue Feb 27, 2024 · 2 comments
Closed
Labels
area:auto-instrumentation Issues for auto-instrumentation enhancement New feature or request needs-info

Comments

@sy-be
Copy link

sy-be commented Feb 27, 2024

Component(s)

instrumentation

Is your feature request related to a problem? Please describe.

I have a use case whereby developers want to manually instrument their applications from within the code, however they also want OTEL environment variables to be autoconfigured depending on the environment/k8s cluster they are running. Currently this is not fully supported, I could use instrumentation.opentelemetry.io/inject-sdk: "true", however it does not configure language specific env vars, e.g. for Python we additionally need setting up traces and metrics protocols and would be nice to avoid hardcoding these values and instead rely on OTEL operator for setting these.

Describe the solution you'd like

Have an annotation with the default value of autoinstrumentation with init containers set to true and when set to false, perform all the usual steps if injecting the SDK (e.g. injectPythonSDK()) but without appending an init container.

Describe alternatives you've considered

Another option would be to modify areContainerNamesConfiguredForMultipleInstrumentations to allow configurations with 0 configurations.

I could also potentially set the init container to some dummy no-op image conforming to filesystem structure as in autoinstrumentation images, however this seems a bit hacky.

Additional context

I can create a PR if this issue makes sense.

@sy-be sy-be added enhancement New feature or request needs triage labels Feb 27, 2024
@pavolloffay pavolloffay added area:auto-instrumentation Issues for auto-instrumentation and removed needs triage labels Feb 28, 2024
@pavolloffay
Copy link
Member

however it does not configure language specific env vars, e.g. for Python we additionally need setting up traces and metrics protocols and

could you be more specific and list which language specific ENV vars should be set?

In the CR there is spec.env option to configure any additional OTEL env vars that will be set when the inject-sdk annotation is used https://github.com/open-telemetry/opentelemetry-operator/blob/main/apis/v1alpha1/instrumentation_types.go#L47

@sy-be
Copy link
Author

sy-be commented Feb 28, 2024

Example would be these env vars: https://github.com/open-telemetry/opentelemetry-operator/blob/main/pkg/instrumentation/python.go#L65-L99

I could hardcode env vars into spec.env as you suggested, but if may result in inconsistency if in future injectPythonSDK() starts to inject more env vars or change defaults from let's say http/protobuf to grpc for the OTEL_EXPORTER_OTLP_TRACES_PROTOCOL.

Another example is open-telemetry/opentelemetry-python-contrib#1250 where OTEL_TRACES_EXPORTER had a schema change where both otlp_proto_grpc and otlp_proto_http values were deprecated. We had OTEL_TRACES_EXPORTER set to otlp_proto_http and we haven't noticed this deprecation initially.

@sy-be sy-be closed this as completed May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:auto-instrumentation Issues for auto-instrumentation enhancement New feature or request needs-info
Projects
None yet
Development

No branches or pull requests

2 participants