basic Typhoeus Hydra support about newrelic-ruby-agent

[nevans]

To be more specific, we don't care if there is only a "single transaction trace node representing the entire batch". What we really want is for the basic details about each request to be visible in the "drilldown"/"parameters"/"key" area. I'm currently looking at new_relic/agent/instrumentation/typhoeus and new_relic/agent/http_clients/typhoeus_wrappers to try and grok how they work.

[benweint]

Hi there!

The root problem here is that the agent is not designed to handle tracing of asynchronous events that potentially overlap in time and finish in a different order than they start, like the individual requests within a Hydra session. Solving that problem would involve a re-architecting of much of the Ruby agent.

That said, it sounds like you don't really need to solve that fundamental issue to get what you're after. You might be able to achieve what you're after by just attaching a parameter to the current transaction trace node that contains the set of URLs hit in a Hydra block. This won't make the requests show up on the Externals tab in the UI, but it will at least let you see what is happening during individual transaction traces.

To accomplish that, you'll want to start with this method in the Typhoeus instrumentation, probably making a separate case for when request_is_hydra_enabled? returns true. In that separate case, you'll want to use notice_extra_data to attach extra data onto the transaction trace node representing the Hydra block. The problem is that you'll only get the requests one-at-a-time, and notice_extra_data will overwrite the previous value that you pass to it if you call it again inside the same transaction trace node. There might be a creative way around that, such as including a number in the key name (e.g. hydra_url[N] where N is the 'index' of the request in the Hydra block). For that to work, you'd need a place to stash a counter on a per-Hydra-block basis, which I don't know off the top of my head if that's easy to find or not.

Let us know if this doesn't make sense, or if you run into trouble along the way - this does seems like a useful feature to add. Thanks!

[nevans]

Thanks! That does make sense, and is exactly what we need. Since we're already alias method chaining Hydra#run and the request has a reference back to its hydra (request.hydra), it probably makes sense for the Hydra instance to temporarily store an array of the requests (or a counter). After run_without_newrelic, we can process our requests array and attach it to the trace.

Some questions about notice_extra_data:

• notice_extra_data is a private method on NewRelic::Agent::TransactionSampler. How should I access it from the monkeypatched Hydra (which has NewRelic::Agent::MethodTracer included) or from anywhere else?
• Are there any magic key values to avoid? I see that :sql is special cased in a few places. Will using arbitrary keys work out okay?
• What will the web UI's transaction trace look like if I attach multiple keys e.g. "hydra_req[0]" through "hydra_req[n]" (where n might be >= 1000)? I could also roll up the entire batch of requests into a single message although that would be more likely to hit MAX_DATA_LENGTH.
• Speaking of MAX_DATA_LENGTH, will calling notice_extra_data thousands of times run into data size issues?
• Is it okay to give a duration of 0.0 or nil? Recording an accurate duration is more work than I want to do right now. :)

[benweint]

Great questions! I think you're right that it probably makes sense to stash the counter on the request.hydra instance.

• Re: notice_extra_data being a private method: sorry I missed that. I'd suggest adding a public wrapper method like notice_sql, called something like notice_http_request_url that calls notice_extra_data underneath.
• Re: key values to avoid: I believe the only two currently used are :sql and :key.
• Re: how the UI will handle this - I honestly don't know. I suspect it will show up, but it may not be formatted in a particularly pretty way. I suspect that you may bump up against some limits in the UI if you're really talking about displaying the URLs 1000s of outgoing requests within a single transaction, but the quickest way to answer that question is probably just to try it :)
• Re: MAX_DATA_LENGTH - that limit is applied on a per-key basis, so you actually should be OK if you use separate keys (it would be an issue if you were to aggregate everything together into one key, though).
• Re: a duration of 0 or nil - don't pass nil, but 0 should be fine. It looks like duration is only used to determine whether to capture a backtrace for the transaction trace node, which you probably don't want.

[nevans]

For the notice_extra_data wrapper, I'm still not sure how to get to the appropriate NewRelic::Agent::TransactionSampler instance. Is there a global/singleton somewhere, or a local reference created by NewRelic::Agent::MethodTracer?

[jasonrclark]

NewRelic::Agent.instance.transaction_sampler is the usual approach for getting the TransactionSampler instance.