-
Notifications
You must be signed in to change notification settings - Fork 368
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
Enable extraction of http/unix adapter config from transport_options proc #1932
Enable extraction of http/unix adapter config from transport_options proc #1932
Conversation
…ise error In #1932 we did the groundwork required to support parsing the unix domain socket configuration from a c.tracing.transport_options configuration. Thus, we can now support unix domain sockets configured by the user without any other change (assuming that PR is merged before this commit is). The `transport_configuration_proc` can still contain weird transport configurations, but if that's the case, we just ignore them and print a warning. This is because we don't support every setting a user may provide in that proc. Worst case, for customers with a really custom config, is that the profiler won't be able to report data, and the customer will need to reach out to support for help updating it. (But we won't raise an exception or stop the profiler from starting).
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.
We reviewed these PRs together, and the consensus we reached was that we should try to remove the proc for transport_options
if we can implement a suitable replacement within the configuration settings code. This is the long term goal.
In the short term, to improve configuration usage, this is OK to do. Ideally this complexity will be removed long term when we have better transport configuration settings code in place.
…proc As documented in the getting started guide (<https://docs.datadoghq.com/tracing/setup_overview/setup/ruby/#configuring-the-transport-layer>), one way of configuring ddtrace is to provide a proc as the `tracing.transport_options` configuration setting. Up until now, the `AgentSettingsResolver` class effectively "gave up" when it saw one of these procs, and just included it the proc in its `AgentSettings` output. This meant that: a) If there were any invalid or conflicting settings, we could not detect or warn about them b) We were in the dark on what settings actually were going to be used, since the proc could do anything it wanted. The `AgentSettings` object could be completely used or completely ignored. c) It was hard to provide alternative transport implementations, because they may not be able to implement the full adapter configuration API expected by the user code. For instance, this is needed to implement unix domain socket support in the new profiler libddprof-based transport. To fix this, I've implemented a very minimalistic approach: Inside the `AgentSettingsResolver` we try to execute the `transport_options` proc and see if all it does is configure an http or unix adapter. If so, success, we get its configuration and no longer need to deal with the proc. If the proc tries to do anything fancier (extra transport configuration or using a test or custom adapter), we just give up and retain the previous behavior. Worst case, the previous behavior is retained exactly. Best case, we are able to parse the configuration correctly, and are able to do the usual validations and include it in the `AgentSettings` object. Finally, yes, this does add more complexity to the `AgentSettingsResolver` but I claim that this complexity was already there, and now I've exposed it where it should be.
2e0e8aa
to
a46c320
Compare
Pushed a rebase to solve a trivial conflict with #1930. |
Thanks for the review, merging away. CI is broken for |
…ise error In #1932 we did the groundwork required to support parsing the unix domain socket configuration from a c.tracing.transport_options configuration. Thus, we can now support unix domain sockets configured by the user without any other change (assuming that PR is merged before this commit is). The `transport_configuration_proc` can still contain weird transport configurations, but if that's the case, we just ignore them and print a warning. This is because we don't support every setting a user may provide in that proc. Worst case, for customers with a really custom config, is that the profiler won't be able to report data, and the customer will need to reach out to support for help updating it. (But we won't raise an exception or stop the profiler from starting).
…ise error In #1932 we did the groundwork required to support parsing the unix domain socket configuration from a c.tracing.transport_options configuration. Thus, we can now support unix domain sockets configured by the user without any other change (assuming that PR is merged before this commit is). The `transport_configuration_proc` can still contain weird transport configurations, but if that's the case, we just ignore them and print a warning. This is because we don't support every setting a user may provide in that proc. Worst case, for customers with a really custom config, is that the profiler won't be able to report data, and the customer will need to reach out to support for help updating it. (But we won't raise an exception or stop the profiler from starting).
…ise error In #1932 we did the groundwork required to support parsing the unix domain socket configuration from a c.tracing.transport_options configuration. Thus, we can now support unix domain sockets configured by the user without any other change (assuming that PR is merged before this commit is). The `transport_configuration_proc` can still contain weird transport configurations, but if that's the case, we just ignore them and print a warning. This is because we don't support every setting a user may provide in that proc. Worst case, for customers with a really custom config, is that the profiler won't be able to report data, and the customer will need to reach out to support for help updating it. (But we won't raise an exception or stop the profiler from starting).
…ise error In #1932 we did the groundwork required to support parsing the unix domain socket configuration from a c.tracing.transport_options configuration. Thus, we can now support unix domain sockets configured by the user without any other change (assuming that PR is merged before this commit is). The `transport_configuration_proc` can still contain weird transport configurations, but if that's the case, we just ignore them and print a warning. This is because we don't support every setting a user may provide in that proc. Worst case, for customers with a really custom config, is that the profiler won't be able to report data, and the customer will need to reach out to support for help updating it. (But we won't raise an exception or stop the profiler from starting).
As documented in the getting started guide (https://docs.datadoghq.com/tracing/setup_overview/setup/ruby/#configuring-the-transport-layer), one way of configuring ddtrace is to provide a proc as the
tracing.transport_options
configuration setting.Up until now, the
AgentSettingsResolver
class effectively "gave up" when it saw one of these procs, and just included it the proc in itsAgentSettings
output.This meant that:
a) If there were any invalid or conflicting settings, we could not detect or warn about them
b) We were in the dark on what settings actually were going to be used, since the proc could do anything it wanted. The
AgentSettings
object could be completely used or completely ignored.c) It was hard to provide alternative transport implementations, because they may not be able to implement the full adapter configuration API expected by the user code. For instance, this is needed to implement unix domain socket support in the new profiler libddprof-based transport.
To fix this, I've implemented a very minimalistic approach: Inside the
AgentSettingsResolver
we try to execute thetransport_options
proc and see if all it does is configure an http or unix adapter. If so, success, we get its configuration andno longer need to deal with the proc.
If the proc tries to do anything fancier (extra transport configuration or using a test or custom adapter), we just give up and retain the previous behavior.
Worst case, the previous behavior is retained exactly. Best case, we are able to parse the configuration correctly, and are able to do the usual validations and include it in the
AgentSettings
object.Finally, yes, this does add more complexity to the
AgentSettingsResolver
but I claim that this complexity was already there, and now I've exposed it where it should be.(P.s.: This relies on the refactoring in #1931)