-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Merge hardcoded/default configuration with OTEL config file #2211
Merge hardcoded/default configuration with OTEL config file #2211
Conversation
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
@objectiser @yurishkuro could you please review? |
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
The xdock tests are flaky. I think it's because of gRPC channel between agent and collector. I will try to use retry and report back. We had similar issue here https://github.com/jaegertracing/jaeger/pull/1384/files |
Signed-off-by: Pavol Loffay <[email protected]>
This patch in OTEL should fix the failures in OTEL xdoc open-telemetry/opentelemetry-collector#899. We should also apply the same to our current xdock. |
Signed-off-by: Pavol Loffay <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #2211 +/- ##
==========================================
- Coverage 96.18% 96.16% -0.02%
==========================================
Files 219 219
Lines 10632 10632
==========================================
- Hits 10226 10224 -2
- Misses 351 352 +1
- Partials 55 56 +1
Continue to review full report at Codecov.
|
Signed-off-by: Pavol Loffay <[email protected]>
@rubenvp8510 would you like to review this one? |
@@ -0,0 +1,23 @@ | |||
receivers: |
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 the receivers and exporters be removed now?
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 now. There is a comment in this file explaining why.
pipelines: | ||
traces: | ||
receivers: [jaeger] | ||
processors: [queued_retry, batch] |
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 may highlight a potential issue in some situations - what if a user wants the processors to be performed in a particular order?
In this specific case, wouldn't the batch normally precede the queued_retry? So the spans are batched, and then queued/retried based on those new batches?
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 is a good comment. We should allow overriding the order.
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.
In https://github.com/open-telemetry/opentelemetry-collector/pull/909` disabled flag has been removed from all components. Hence there is no way how a user could disable hardcoded/default component.
In this PR I wanted to support incremental addition of components. For instance if a user wants to add a processor it would just add it to services.pipelines.traces.processors
without repeating the default/hardcoded processors. Since there is no way to disable a component and order of the components might be important we should require defining an exact order of the components in the pipeline.
Example: add attribute processor
processors:
attributes:
key: foo
service:
pipelines:
traces:
processors: ["batch", "attributes"]
The batch
has to be repeated otherwise it will not be included in the pipeline.
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.
Is this going to be considered/implemented in a separate PR?
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.
In this PR, as this will have to change anyways.
return nil, err | ||
} | ||
} | ||
err = defaults.MergeConfigs(cfg, otelCfg) |
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.
So just to clarify, the user supplied OTel config will override any config provided by jaeger's default OTel config or CLI flags?
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.
OTel config will override config properties that are overridden in OTEL config. This is why we do merge instead of ignoring Jaeger config like we were doing prior this PR.
crossdock/otel-agent-config.yml
Outdated
@@ -4,15 +4,19 @@ receivers: | |||
host_endpoint: localhost:5778 | |||
fetch_endpoint: jaeger-collector:14250 | |||
protocols: | |||
grpc: |
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 has this been added (and disabled) rather than just leaving out?
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.
Because grpc is enabled by default and our legacy agent doesn't expose gRPC endpoint. Once we provide agent build with opinionated config this will be removed.
crossdock/otel-agent-config.yml
Outdated
thrift_compact: | ||
thrift_binary: | ||
|
||
exporters: | ||
jaeger_cassandra: |
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.
Same as comment above.
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.
Collector config by default uses cassandra backed. In this case we want to disable C* storage because this deployment acts as agent.
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 ok - but when there is an opinionated default config for agent this won't be a problem, as you explained above.
|
||
service: | ||
pipelines: | ||
traces: | ||
receivers: [jaeger] |
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 has jaeger receiver been dropped?
Are we also going to support an agent config using otel protocol receiver and exporter config? For example when using an OTel tracer with otel protocol exporter - it might be good to collect via otel agent (no jaeger receiver/exporter) and talk otel protocol to the backend jaeger collector, i.e. so no jaeger protocol used.
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 has jaeger receiver been dropped?
Jaeger receiver is enabled by default, hence we don't have to specify it explicitly. In this config file we just disabled the grpc endpoint - to better align with legacy agent capabilities. Once we create agent OTEL build this config file will change bc the agent will use a different hardcoded default config #2204
Are we also going to support an agent config using otel protocol receiver and exporter config? For example when using an OTel tracer with otel protocol exporter - it might be good to collect via otel agent (no jaeger receiver/exporter) and talk otel protocol to the backend jaeger collector, i.e. so no jaeger protocol used.
This is a separate discussion but I agree, we should be enabling OTEL endpoints by default. #2214
cmd/opentelemetry-collector/app/defaults/default_config_test.go
Outdated
Show resolved
Hide resolved
if len(getOTELConfigFile()) > 0 { | ||
otelCfg, err = service.FileLoaderConfigFactory(otelViper, f) | ||
if err != nil { | ||
return nil, err |
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.
Should we log an error here? Indicating a config load failure?
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.
It's not needed here as It is logged in OTEL collector.
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
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 one minor thing.
Signed-off-by: Pavol Loffay <[email protected]>
Resolves #2198
This PR changes the way how OTEL config is loaded:
disabled
property.Caveats:
config.Load()
returns an error if config does not contain receivers or exporters. We should fix this in upstream and move all validations to a separate function. - Allow loading incomplete configuration open-telemetry/opentelemetry-collector#888