Tim – I apologize for the delay in getting back to you, I just made you a 
collaborator on the GitHub project, and you are already a co-maintainer on 

Jose – are you interested in being a collaborator too on 
Plack::Middleware::NewRelic, or are you pursuing using opentracing for your 
needs instead (from the link you shared with us)?


Ali Anari
        (215) 205-0971

On October 17, 2016 at 4:38:58 AM, tim.bu...@pobox.com (tim.bu...@pobox.com) 

[I've taken the liberty of CC'ing this to the dbi-users mailing list.]  

On Mon, Oct 17, 2016 at 07:20:30AM +0000, Jose Luis Martínez Torres wrote:  
> Hello Tim,  

Hello Jose.  

> I have been thinking of making a NewRelic toolkit for instrumenting the stuff 
> that goes on  
> inside an app in an easy way (calls to the database, creating segments for 
> calls to controllers in  
> Catalyst, creating segments for calls to external HTTP servers).  


If you've not looked at http://opentracing.io please do.  
There's no perl API yet. Perhaps you could help write one! :)  
Though since we're talking about NewRelic I presume you're using that.  

> I've looked at the actual state of things on CPAN, and can only find  
> Plack::Middleware::NewRelic, for which I have some doubts (for example, I 
> can't explain myself why it's  
> using a CHI cache in the _agent_builder method, since Moo is supposed to 
> cache that value...),  

Me too: https://github.com/aanari/Plack-Middleware-NewRelic/issues/6 :)  

> and then there doesn't seem to be a way of exposing the agent to  
> other parts of the software stack (so they can create segments).  


I just made it more subclassable:  
and then implemented our needs in a subclass.  

Perhaps the author, Ali Anari, would be open to having you and I as  
co-maintainers so we could move the code forward. I've CC'd this to Ali.  

> Since I can't seem to find prior work on this for Perl, was thinking of 
> creating a  
> NewRelic Singleton instance that gets initialized by a Plack Middleware (that 
> sets the transaction id  
> and initializes the agent), and then let other modules (like a DBI NewRelic 
> Agent get the singleton and  
> create segments for their transactions). On that I had doubts on how to 
> handle this in an efficient way:  
> your Plack-Middleware-Debug-DBIProfile seems like one way to go. Would you 
> recommend me going down that  
> path (when this is thought to be enabled in production environments)? Or 
> going down a path like in this  
> blog? [1]https://blog.afoolishmanifesto.com/posts/dbi-caller-info/ (wrapping 
> the prepare method,  
> starting a segment there, and then closing the segment on execute in the 
> sth).  

Requiring use of a subclass is problematic in some ways and raises the  
effort and risks for other people to adopt the tool.  

Plack::Middleware has an easy time because there's a very clear entry  
and exit point.  

The problem with the NewRelic API, IIRC, is that you can't add a segment  
retrospectively. There's no way to say "I've just spent $X seconds doing Y".  
You have to make an API call at the start of Y and another at the end.  
The DBI::Profile mechanism would work for the former but not the later.  

Using a subclass, like fREW does in the link you posted, is a reasonable  
approach, You'd override some set of methods, at least execute() and  
do(), with code that would create and end a NewRelic segment for each call.  
(Ideally every kind of select and fetch method should also be wrapped,  
if you really want accurate data. Plus prepare() for some drivers. The  
list goes on and on but the returns diminish.)  

Subclassing the driver would also be possible but there are probably  
dragons lurking there.  

The Callbacks mechanism is also worth looking into  
The current implementation has two limitations that make it less than  
ideal, but both could be implemented (in C) without too much work:  
a) there's no way to invoke a callback on _return_ from a method  
b) there's no (easy) way to have multiple callbacks, so it's hard to  
have multiple modules setting callbacks without them clashing.  
The former is what's needed to make Callbacks useful for profiling.  

> I also am afraid that others might be already doing stuff around monitoring 
> Perl  
> applications with New Relic, but I can't find how they're doing it (on GitHub 
> for example). You, being  
> the maintainer of NewRelic::Agent can maybe guide me to people you know are 
> instrumenting their Perl  
> code with NewRelic and how they're doing it.  

I notice that you're emailing me personally rather than using the  
dbi-users mailing list. So you're not helping other like-minded people  
to find you :) I suggest you start by emailing dbi-users@perl.org  
Or rather, I was going to suggest that but ended up just CC'ing this  
reply instead :)  

> Since it's the first time I mail you, please let me express my gratitude 
> towards you and  
> your work in the Perl community. You are an inspiration for us J  

Thanks, and you're welcome!  


Reply via email to