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

[core] Stop sending service information #738

Merged
merged 10 commits into from
Apr 17, 2019

Conversation

brettlangdon
Copy link
Member

We no longer need to make calls to /services so these unnecessary calls can be removed from the tracer.

Reviewers: The changes I made should all be internal and cause no breaking changes to user's code, but would love feedback specifically in this area, if you notice something removed that could be a problem, let me know.

@brettlangdon brettlangdon added this to the 0.23.0 milestone Apr 16, 2019
@brettlangdon brettlangdon added the core Involves Datadog core libraries label Apr 16, 2019
Copy link
Contributor

@pawelchcki pawelchcki left a comment

Choose a reason for hiding this comment

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

Looks good!
not sure how much user code is touching that layer, my feeling is that all service mention could safely be removed.

But as a stop gap measure this Looks Good To Me!

@brettlangdon
Copy link
Member Author

Great! Yeah, Tracer#set_service_info was the main one that seemed like it needed to stay for now.

@pawelchcki
Copy link
Contributor

Indeed set_service_info is good to keep for now. Wonder if it would make sense to add warning here similar to this one:
https://github.com/DataDog/dd-trace-rb/blob/67bc4744079b8103d4fbfa95771e67a0267217f1/lib/ddtrace/pin.rb#L97 < this is only a optional question :)

Also, looking forward to much cleaner code thanks to that change. It looks much better already!

@brettlangdon
Copy link
Member Author

@pawelchcki and @palazzem I updated to remove all usage of set_service_info internally, so this is a little more 🔥 🔥

Would love another review.

def write(trace, services)
def write(trace, services = nil)
unless services.nil?
Datadog::Patcher.do_once('SyncWriter#write') do
Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure this does 100% what I expect it to... seems like it, but /shrug

Copy link
Contributor

Choose a reason for hiding this comment

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

Based on

def do_once(key = nil, options = {})

It will do the thing in block only once.

Not necessarily an intended use case of this but if threads are of no concern it should be good to go.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it is definitely the point to only do it once. Mainly because Ruby doesn't have the rate limited logger yet, and if we happened to miss a place in code or someone is doing this manually, then it could get super spammer.

I was mostly concerned about calling this method statically instead of as an instance method.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah it should work, however its not thread safe so using it in this particular class might lead to unexpected results. Its only logs so at worst they will be sent 1 or 2 times more than expected.

Also SyncWriter itself should be highly discourage from use. It has some very unpleasant side effects in multithreaded environment

Copy link
Member Author

Choose a reason for hiding this comment

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

👍 yeah, as long as we dedupe a bit, even once per-thread is fine by me, as long as it is 1M messages per-thread 😆

Copy link
Contributor

Choose a reason for hiding this comment

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

Generally don't think calling Datadog::Patcher.do_once is a good idea; the state is effectively turned into global state, which has some really bad side effects (particularly for things like tests.) The Datadog::Patcher module was meant to be composed in, not be called directly.

We should probably compose in Datadog::Patcher and use it that way, or extract do_once into another module with a better name, then compose that in here.

Copy link
Contributor

@pawelchcki pawelchcki left a comment

Choose a reason for hiding this comment

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

Looks awesome ❤️ I love it

@@ -17,11 +17,9 @@ class Settings < Contrib::Configuration::Settings
lazy: true

option :orm_service_name
option :service_name, depends_on: [:tracer] do |value|
(value || Utils.adapter_name).tap do |service_name|
tracer.set_service_info(service_name, Ext::APP, Datadog::Ext::AppTypes::DB)
Copy link
Contributor

Choose a reason for hiding this comment

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

❤️!!!

def write(trace, services)
def write(trace, services = nil)
unless services.nil?
Datadog::Patcher.do_once('SyncWriter#write') do
Copy link
Contributor

Choose a reason for hiding this comment

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

Based on

def do_once(key = nil, options = {})

It will do the thing in block only once.

Not necessarily an intended use case of this but if threads are of no concern it should be good to go.

@brettlangdon brettlangdon merged commit 9a6d0e6 into 0.23-dev Apr 17, 2019
@brettlangdon brettlangdon deleted the brettlangdon/stop.sending.services branch April 17, 2019 14:28
@delner
Copy link
Contributor

delner commented Apr 23, 2019

Side note: we'll want to rebase #628 on these changes which currently has services still a part of the transport.

@delner delner mentioned this pull request Apr 23, 2019
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Involves Datadog core libraries
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants