Tyler Helmuth

I was referring to [this issue](https://github.com/open-telemetry/opentelemetry-collector/issues/5084#issuecomment-1093116666), but it is fixed now.

@ajsaclayan @dmitryax the transform processor can handle this situation exactly: ```yaml transform: metric_statements: - context: datapoint statements: - 'set(attributes["foo"], true) where attributes["some.key"] == "some.value"' ```

@atoulme math has been added to the OTTL. Does it solve this issue?

@matthewmodestino checkout the [transform processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor) and the function [replace_pattern](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/ottlfuncs#replace_pattern). Does that fit your needs?

@matthewmodestino I'm going to close this based on the transform processor's capabilities. Please ping me if you think it should stay open.

@famoushz can you try adding `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` and `OTEL_EXPORTER_OTLP_ENDPOINT` to the Instrumentation's env vars? ```yaml apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: my-instrumentation spec: exporter: endpoint: http://tempo:4317 propagators: - tracecontext - baggage...

@flenoir Can you try removing /v1/traces from the OTEL_EXPORTER_OTLP_ENDPOINT value?

@mx-psi based on the decision made in https://github.com/open-telemetry/opentelemetry-collector/issues/10181 our `component.Host` implementation can implement optional interfaces that other components need. As an aside, I think `service` should probably expose, somehow, which...

As part of the RFC we decided that `${FOO}` and `${env:FOO}` would be resolved the same way (at least for our distros) which means supporting YAML syntax for both styles....

@evan-bradley thats fine