Skip to content

tracing: apply tracer provider configuration defined as part of http_connection_manager filter#10405

Merged
mattklein123 merged 24 commits intoenvoyproxy:masterfrom
yskopets:feature/use-tracer-per-http-connection-manager
Apr 10, 2020
Merged

tracing: apply tracer provider configuration defined as part of http_connection_manager filter#10405
mattklein123 merged 24 commits intoenvoyproxy:masterfrom
yskopets:feature/use-tracer-per-http-connection-manager

Conversation

@yskopets
Copy link
Copy Markdown
Member

@yskopets yskopets commented Mar 16, 2020

Description: apply tracer provider configuration defined as part of http_connection_manager filter
Risk Level: Low
Testing: unit tests
Docs Changes: N/A
Release Notes: N/A

Context:

@repokitteh-read-only
Copy link
Copy Markdown

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #10405 was opened by yskopets.

see: more, trace.

@yskopets yskopets force-pushed the feature/use-tracer-per-http-connection-manager branch from 08f2a00 to 52a48c6 Compare March 16, 2020 17:51
@mattklein123 mattklein123 self-assigned this Mar 16, 2020
@yskopets yskopets force-pushed the feature/use-tracer-per-http-connection-manager branch from 52a48c6 to a6be7b9 Compare March 16, 2020 18:06
@yskopets
Copy link
Copy Markdown
Member Author

@mattklein123

I need your advice on how to better handle OpenCensus case.

Right now, I've documented why OpenCensus is different from other tracing providers.

Do you think we need something better than a warning in the docs ?

E.g., we could prohibit configuring *envoy.tracers.opencensus* via http_connection_manager and only allow it in the bootstrap config.

Also, current implementation of HttpTracerManager as a Singleton leaves a room for an error in case of OpenCensus. Since Singletons might be removed when no longer in use (no more Listeners left), it is possible that OpenCensus will be configured more than 1 time even if it's a part of bootstrap config. Unfortunately, OpenCensus will not handle gracefully double configuration (it will not crash Envoy, but its behaviour will be wrong, e.g. reporting a Span multiple times).

WDYT ?

@yskopets yskopets force-pushed the feature/use-tracer-per-http-connection-manager branch from a6be7b9 to af52fbb Compare March 16, 2020 18:30
…_connection_manager` filter

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@yskopets yskopets force-pushed the feature/use-tracer-per-http-connection-manager branch from af52fbb to 0561ccc Compare March 16, 2020 23:58
@mattklein123
Copy link
Copy Markdown
Member

E.g., we could prohibit configuring envoy.tracers.opencensus via http_connection_manager and only allow it in the bootstrap config.

If our goal is to get rid of tracing config in bootstrap (which I think it is) I don't think this is a viable long term option.

Unfortunately, OpenCensus will not handle gracefully double configuration (it will not crash Envoy, but its behaviour will be wrong, e.g. reporting a Span multiple times).

This seems like a pretty big bug in the OpenCensus implementation. Can we get this tracked somehow and someone working on an upstream fix? I would be inclined to just ignore this for now and let this be tracked as a known bug. IMO we should not go out of our way to work around broken extensions in Envoy. cc @g-easy @rnburn @objectiser

@yskopets
Copy link
Copy Markdown
Member Author

@mattklein123

I don't want to leave any room for an error.

Because if it can happen, it will happen eventually, and it will cost somebody a few hours/days of troubleshooting.

So, I propose to update OpenCensusTracerFactory::createHttpTracer():

  1. On first successful invocation, memorize the proto_config argument and a created Tracer instance
  2. On subsequent invocations, compare proto_config argument against the first-time value; if they match, return previously created Tracer, otherwise throw an error

This way, HttpTracerManager can remain a Singleton and get deleted when it's necessary.

WDYT?

@mattklein123
Copy link
Copy Markdown
Member

WDYT?

Yup sounds like a great plan.

@yskopets
Copy link
Copy Markdown
Member Author

yskopets commented Mar 23, 2020

@mattklein123

I will do it in a separate PR

…ion notice for tracing provider configuration as part of Bootstrap config

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@yskopets
Copy link
Copy Markdown
Member Author

yskopets commented Mar 25, 2020

@mattklein123

I've made a few changes:

I was unable to add [deprecated = true] annotation, though:

  • if I add it to v2.Bootrstrap, then tracing field gets completely removed from v3.Bootrstrap
  • if I add it to v3.Bootrstrap, then it gets stripped off by automation on git push

How should I proceed ?

@mattklein123
Copy link
Copy Markdown
Member

How should I proceed ?

cc @htuch you can still access the hidden smuggled field in the v3 object (see the generated API protos that are checked in). However, technically we can't make breaking changes to v3 like this. We are likely going to lock v2 very soon (next ~1 week) and then we will be working on v3 and v4alpha. So what I would probably do is deprecate this field from v2 and get the hidden smuggled field approach working. Then when we move to v3/v4alpha it should be straightforward to move this change over.

…r-per-http-connection-manager

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@htuch
Copy link
Copy Markdown
Member

htuch commented Mar 26, 2020

Yeah, I'm actively working on moving the v2->v3 API migration tooling to go v3->v4alpha, ETA < 1 week.

…acing` field

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
…PRECATED_FEATURE_TEST()`

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
…uilt with `--define deprecated_features=disabled` option

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@yskopets
Copy link
Copy Markdown
Member Author

@mattklein123

After adding [deprecated = true] to v2.Bootstrap.tracing field, //test/config_test:example_configs_test was failing in CI builds with --define deprecated_features=disabled option.

To fix that, I updated all "example_configs" to define tracing provider as part of HCM.

The only example left that is still using v2.Bootstrap.tracing field is configs/using_deprecated_config.v2.yaml.

Let met know if it's not what you expected.

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thanks in general this looks great. Let's revisit in ~1 week when we lock v2?

/wait

// If not specified, Envoy will fall back to using tracing provider configuration
// from the bootstrap config.
// [#not-implemented-hide:]
// from the bootstrap config (for short-term backwards compatibility).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would make the new docs read as it should be now vs. referring back to the previous behavior. That can be covered in deprecated.rst.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

fixed

Comment thread api/envoy/config/trace/v2/trace.proto Outdated
// :ref:`provider <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpConnectionManager.Tracing.provider>`
// field.
//
// Alternatively, for the sake of short-term backwards compatibility, it is also possible to define
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Same comment here. Please make the new docs refer to the expected new config, and talk about deprecation in deprecated.rst

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

fixed

typed_config: {}
tracing:
operation_name: INGRESS
# Notice that tracing provider configuration is now part of "envoy.filters.network.http_connection_manager" config.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nit: I think this comment can be skipped, same elsewhere.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

fixed

yskopets added 2 commits April 8, 2020 22:03
…d in v2 api"

This reverts commit 2107e1f.

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@yskopets yskopets requested a review from mattklein123 April 8, 2020 20:16
@yskopets
Copy link
Copy Markdown
Member Author

yskopets commented Apr 8, 2020

@mattklein123

When I refer to v3 apis in deprecated.rst and version_history.rst, CI build for docs fails with

/source/generated/rst/intro/deprecated.rst:15: WARNING: undefined label: envoy_api_field_config.bootstrap.v3.bootstrap.tracing (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/deprecated.rst:15: WARNING: undefined label: envoy_api_field_extensions.filters.network.http_connection_manager.v3.httpconnectionmanager.tracing.provider (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/version_history.rst:6: WARNING: undefined label: envoy_api_field_config.bootstrap.v3.bootstrap.tracing (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/version_history.rst:6: WARNING: undefined label: envoy_api_field_extensions.filters.network.http_connection_manager.v3.httpconnectionmanager.tracing.provider (if the link has no caption the label must precede a section header)

How should I fix that ?

@mattklein123
Copy link
Copy Markdown
Member

@htuch see question about doc failure above?

@htuch
Copy link
Copy Markdown
Member

htuch commented Apr 8, 2020

@yskopets try using envoy_v3_api... prefix for the v3 protos, e.g. envoy_v3_api_field_config.bootstrap.v3.Bootstrap.tracing

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
@yskopets
Copy link
Copy Markdown
Member Author

yskopets commented Apr 8, 2020

@htuch thanks! it helped

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thanks this is a great improvement. Just a few small questions/comments.

/wait

//
// Envoy may support other tracers in the future, but right now the HTTP tracer is the only one
// supported.
message Tracing {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is this message actually used anymore or just the inner HTTP message? Should this message actually be tagged for deletion with the inner message moved somehow? I don't think the tool supports this but we might want to file an issue here? cc @htuch

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

config.trace.v3.Tracing will not be used anymore in v4.

I don't see a support for marking the entire message type as deprecated. The closest example is v2.Bootstrap.Runtime which only has (deprecated) comment in the docs.

I've added an "attention" message to config.trace.v3.Tracing for now.

@htuch Should I open an issue or you can phrase it better what needs to be done ?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Please open an issue to track this. We will need some tooling work I think to make sure this message gets deleted/moved/etc. I'm not sure the best way of handling.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

opened #10740

Comment thread docs/root/intro/version_history.rst Outdated

1.15.0 (Pending)
================
* tracing: tracing provider configuration as part of :ref:`bootstrap config <envoy_v3_api_field_config.bootstrap.v3.Bootstrap.tracing>`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nit: I wouldn't discuss deprecation here but rather just describe the new way of configuring it. You describe deprecation elsewhere.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

reworded

Comment thread test/server/server_test.cc Outdated
TEST_P(ServerInstanceImplTest, DEPRECATED_FEATURE_TEST(ZipkinHttpTracingEnabled)) {
options_.service_cluster_name_ = "some_cluster_name";
options_.service_node_name_ = "some_node_name";
EXPECT_NO_THROW(initialize("test/server/test_data/server/zipkin_tracing.yaml"));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nit: can you rename this zipkin_tracing_deprecated_config or similar so it's clear that it should be removed when this is cleaned up?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

renamed

…_data/server/zipkin_tracing_deprecated_config.yaml`

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
// .. attention::
// This field has been deprecated in favor of :ref:`HttpConnectionManager.Tracing.provider
// <envoy_api_field_extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.Tracing.provider>`.
trace.v3.Tracing tracing = 9 [deprecated = true];
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

One question before deprecating, do you have thoughts on #10576?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@htuch Sorry, didn't notice in time.

I've replied here.

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
mattklein123
mattklein123 previously approved these changes Apr 10, 2020
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@mattklein123
Copy link
Copy Markdown
Member

Apologies needs a master merge. We moved version history files around (see master).

/wait

…r-per-http-connection-manager

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thanks!

@mattklein123 mattklein123 merged commit 449be5e into envoyproxy:master Apr 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants