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

Merge hardcoded/default configuration with OTEL config file #2211

Merged
merged 13 commits into from
May 4, 2020

Conversation

pavolloffay
Copy link
Member

@pavolloffay pavolloffay commented Apr 29, 2020

Resolves #2198

This PR changes the way how OTEL config is loaded:

  • Now when OTEL config is provided it is merged with hardcoded/default Jaeger opinionated config.
  • hardcoded/default Jaeger components can be disabled in OTEL config via disabled property.

Caveats:

@pavolloffay pavolloffay requested a review from a team as a code owner April 29, 2020 15:32
@pavolloffay pavolloffay requested a review from jpkrohling April 29, 2020 15:32
@pavolloffay
Copy link
Member Author

@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]>
@pavolloffay
Copy link
Member Author

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]>
@pavolloffay
Copy link
Member Author

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
Copy link

codecov bot commented Apr 30, 2020

Codecov Report

Merging #2211 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
cmd/query/app/server.go 91.78% <0.00%> (-2.74%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f834975...f774bf4. Read the comment docs.

@pavolloffay
Copy link
Member Author

@rubenvp8510 would you like to review this one?

@@ -0,0 +1,23 @@
receivers:
Copy link
Contributor

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?

Copy link
Member Author

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.

See also open-telemetry/opentelemetry-collector#888

pipelines:
traces:
receivers: [jaeger]
processors: [queued_retry, batch]
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

cmd/opentelemetry-collector/go.sum Outdated Show resolved Hide resolved
return nil, err
}
}
err = defaults.MergeConfigs(cfg, otelCfg)
Copy link
Contributor

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?

Copy link
Member Author

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.

@@ -4,15 +4,19 @@ receivers:
host_endpoint: localhost:5778
fetch_endpoint: jaeger-collector:14250
protocols:
grpc:
Copy link
Contributor

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?

Copy link
Member Author

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.

thrift_compact:
thrift_binary:

exporters:
jaeger_cassandra:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as comment above.

Copy link
Member Author

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.

Copy link
Contributor

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]
Copy link
Contributor

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.

Copy link
Member Author

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

if len(getOTELConfigFile()) > 0 {
otelCfg, err = service.FileLoaderConfigFactory(otelViper, f)
if err != nil {
return nil, err
Copy link
Contributor

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?

Copy link
Member Author

@pavolloffay pavolloffay May 4, 2020

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]>
Copy link
Contributor

@objectiser objectiser left a 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.

cmd/opentelemetry-collector/app/defaults/merge_test.go Outdated Show resolved Hide resolved
Signed-off-by: Pavol Loffay <[email protected]>
@pavolloffay pavolloffay merged commit e43a11d into jaegertracing:master May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Merge Jaeger OTEL configuration with OTEL config file
3 participants