[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). Cool. 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). Agreed. I just made it more subclassable: https://github.com/aanari/Plack-Middleware-NewRelic/pull/4 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 https://metacpan.org/pod/DBI#Callbacks 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! Tim.
