Want to view CF debugging output for all running requests? Send it to FusionReactor
Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.We all know that showing debug output to end users is a no-no, but sometimes don't you wish you (as an admin) could have access to what debugging info the users would have seen while their requests are running? What if you could capture the debugging info to view it for all running requests, and better still, keep it for a short time to view about hundreds of recent requests?
Well now you can, if you have FusionReactor, by way of a simple 2-step process to configure CF to do this. You can learn more about it in this article Capturing ColdFusion's Debug Output in FusionReactor by Darren Pywell, CTO of Intergral (makers of FusionReactor).
In it, he explains what this is all about (a combination of using FR's API and the "markers" feature of the FR Request Detail page, in conjunction with CF's built-in feature to let you add and use new debugging templates). More important, he gives you all you need to know to set things up, from the simple snippet of code needed (downloadable) to a walkthrough of the simple steps needed to configure CF to hand the debugging output to FR. You can be up and running with this new capability in a matter of minutes (skip to the bottom for the "fast track" steps he offers, for proof.) Check it out.
But what about the performance impact?
And yes, he addresses briefly the performance and memory implications of using such a feature in production. You should certainly take care to ensure that doing this isn't causing any harm, especially if doing this in production. That said, I see lots of shops that leave debugging turned on and use the IP address limiting feature in the CF Admin, which many will argue is equally detrimental. I think a point to make is that the negative impact may be more "theoretical" to some than to others.
The bottom line, as he recommends, is that you should test such things before rolling them into production. Sadly, many shops can't or don't bother with testing (which is very unfortunate).
If you can't test the impact, measure it...with FusionReactor
At least then you should try to have some measure you can watch to see if processing is being in any way harmed, whether it's tracking fewer requests being processed per day, requests taking longer to run each time on average, more CPU being used by CF per day, and so on.
The very good news is that those who have FusionReactor can use FR's own tremendous logging to help report this kind of information. I talk about how to report against that using a tool like Microsoft's free Log Parser, in this page on the google group for FusionReactor.
I'll do a future blog entry on the tremendous logging that's possible. It far exceeds anything provided by any other tool, including the CF8 Server Monitor (which does no logging at all), and it does it with very low overhead.
So if you're using FusionReactor, check out the debug tool. It's very easy to enable and disable (via the CF admin, once you've added the new debugging template). It's also a useful demonstration of the FRAPI.
And if you don't have FusionReactor, check that out, too. I use it or help people use it every day to solve CF problems. It's much more than "just a monitor". For more info, see the site's many resources (brief feature highlights, docs, online help, a live demo, mailing list, and more). See also some of the other entries I've done here on FusionReactor.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
I just want to clarify one thing. When I saw the title of your post I was pretty excited because I have been trying to find a way to get CF to show debugging info for all running requests, however this method will only show CF debugging output for requests that would normally show debugging output. What I mean by that is that some request have debugging output suppressed even though debugging is enabled via the CF Administrator. Some examples of this are AJAX calls made via CF 8's built in AJAX plumbing, remote CFC calls, or pages that use cfsetting with showDebugOutput set to false.
Anyway, I just wanted to point this out because I know people may want to use this feature to debug AJAX and Flex applications. Unfortunately the way CF suppress debugging info for those requests this approach won't work.
It would seem what you're wanting is something that Adobe would need to enable, by way of a remote debug output display option (where debugging output info is made available to something other than the request generating it, and which is not prevented by disabling debugging on the page). What I've described here is close, but not quite all you want. It's certainly reasonable to ask for. Have you filed a wish request for it? (http://carehart.org/...)
The only gotcha I see is that you would probably agree that such a tool should be expected not to work if debugging output is disabled server-wide, right? Because that may be chosen for performance reasons to prevent the generation of debugging output. But one may then argue that the same is intended in the CFSETTING. It's a fine line: are the directives intended to control creation, o display of debug output? Right now, it's kind of vague.
At least the CFSETTING attribute is named SHOWDEBUGOUTPUT, with the focus on "show", so letting a remote debugging override that isn't technically "wrong" feeling, while overriding the admin setting would seem to be.
It seems really that if such a remote debug output feature is enabled, it may be important to revise those two other controls to distinguish separately between "showing' and even "generating" debugging output. (And it's all the more potentially confusing because this is of course separate from the new debugger in CF8. We're not referring to THAT debugging info, available to be processed by the Eclipse debugger by way of the Adobe CF eclipse extensions, but just the long-standing "debugging output" shown traditionally at the bottom of pages.)
That said, yes this is something I would like to see Adobe enable, and I have requested it. I was actually thinking a remote debug output display option via the cfadmin. Obviously this wouldn't do anything if debugging was disabled via the cfadmin.
CFSETTING with showDebugOutput=false and remote Flex calls do generate debugging info, however it is not displayed.
Passing the _cf_nodebug=true URL parameter (which is what CF 8's AJAX plumbing does) does not generate debugging info.
As a side note, the _cf_nodebug attribute does not change the result of CF's built in IsDebugMode() function. (This function still returns true if you pass the _cf_nodebug=true URL parameter.)
Speaking of that, you opened your first comment with, "Good to see others hacking up the debugging templates!" I meant to add that I've been talking to Ray about creating a new project in RiaForge for a set of alternative debugging templates (long before posting the entry above). It's certainly a powerful feature that can be leveraged in many ways, as indeed tools like ColdFire, CFWatcher, StarFish, and your own CF Debug Copy all do. I list these all on my 411 site: http://www.cf411.com...