Note: This blog post is from 2008. 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.

Parts 3 and 4 of my 4-part series on the CF8 Server Monitor are now posted on the Adobe DevNet site. Part 3 was posted several weeks ago, but with the holidays, etc. I just failed to get word out. Part 4 was posted yesterday.

If you've not taken a look at these, you may be missing out. There are some misconceptions about the monitor, and also I think most don't realize that it can do much more than they may suspect. There's precious little documentation (and discussion) about it, so you may find things here you won't find anywhere else.

• Part 1: Using the Server Monitor in development
• Part 2: Using the Server Monitor in production
• Part 3: Automated monitoring and request management with Alerts and Snapshots
• Part 4: Multiserver Monitor, Admin API monitoring, and more

The third and fourth parts, specifically, have the following sections:

Part 3

• Automated monitoring and request management with Alerts
• Substantial diagnostic details with Snapshots

Part 4

• An enterprise dashboard with the Multiserver Monitor
• Programmatic Monitoring with the Admin API
• Tweaking the Monitor in the Settings section
• Miscellaneous aspects of the Monitor

Sure, I've just written about FusionReactor yesterday, and will write still more about the new release. I don't see it incompatible to help people make the most of whatever tool they may use. I've written previously also about SeeFusion. Indeed, I've written previously that that each has their place, even in the face of CF8's server monitor.

I'd like to hear from readers

The DevCenter articles offer a feedback link, but so far I've not gotten any (and they say they will forward any they get). I'd really appreciate hearing from anyone who has read the articles. I really feel that they go way beyond what's available in the docs and help, to bring together information and concepts you might otherwise miss. Has it helped you at all?

Finally, do you ever wonder why some call this area of the Adobe site "DevNet", "DevCenter", and/or some the "Developer Connection"? Well, the URL has devnet in it, but the breadcrumb bar at the top of my articles shows "Home > Developer Connection > ColdFusion Developer Center". Go figure. :-)

Note: This blog post is from 2008. 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.

The fine folks at Intergral, makers of the FusionReactor monitor for CF and other servers, have quietly released a new FusionReactor 3 today.

The key new features are:

• An improved Enterprise Dashboard, built on Flex, with additional new info and even an Air-based version (the latter still in beta)
• Substantially improved request metrics (system overview) page, with new graphs and data (since the Dashboard is only in the FR Enterprise edition, this is a real plus for FR standard users) and also slow query tracking
• dramatic new zoom feature in graphs, to zoom in a range of time intervals
• improved logging, especially useful for post-mortem analysis
• ability to fire a script/batch file when a server monitored in the Enterprise dashboard stops/starts (has long been able to send you email and/or log those events)
• support for multiple user logins with optional varying access levels, including new "manager" and "observer" roles in addition to the normal "admin" role
• abiliity to track cpu available in the system against CPU used by a monitored instance
• ability to view/delete requests queued by FR crash protection queuing

You can learn more about what's new, and upgrade pricing.

I'll blog more about many other little things that have changed--the good ol' "hidden gems" I like to do.

Note: This blog post is from 2007. 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.

Some may be interested to learn that I've had another article published on the Adobe Devnet site yesterday: "ColdFusion 8 server monitoring - part 2: Using the Server Monitor in production".

This follows up the part 1, which focused on uses of the monitor in development. There will be 4 parts ultimately, all listed in the Developer Center, with the 3rd part discussing the alerts and snapshots features, and part 4 discussing the Multiserver Monitor, Admin API monitoring features, and various miscellaneous observations.

The CF8 monitor offers a lot more than many would think, and insight into certain inner workings of CF that we've just never had before. I try to highlight things that you may have missed if you've only glanced at it or attended brief overviews at conferences or user groups. I will likely to my own presentation on it in the future..

No one should read from this that I'm any less supportive of 3rd party tools like FusionReactor and SeeFusion. As I've stated before, there's clearly a place for those tools for shops not yet on CF8, and even once on CF8 I believe there are differences among all the tools that could warrant having more than one at once.

Note: This blog post is from 2007. 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.

I'm surprised to still see people lament when they learn that CF8's server monitor does not run on CF8 Standard, or that it doesn't run at all against CF 6 or 7. My surprise is that their comments often make no mention of being aware of alternatives. On one list, someone said they might even be willing to pay double CF Standard's price to get monitoring in Standard. They just didn't like paying 6 times more (for Enterprise).

Well here's the thing: you can indeed get CF server monitoring, whether added to CF8 or made available in CF 6 or 7, and for far less than even double the cost of CF Standard. Some of you know where I'm going, but in case it needs to be said...

Check out FusionReactor and SeeFusion, both tools that I've written about before (see the "related entries" links at the bottom of this entry.)

Both these tools not only run on 8 (any edition), but they run on 7 and 6 as well, which CF 8's monitor does not. Further, FusionReactor can monitor not just CF but also any J2EE servers or app (including LiveCycle Data Services, for instance), and SeeFusion has a sister product, SeeJava, that can do this as well.

I've been a huge fan of both tools for a couple of years. No, they're not identical to CF8's monitor, and CF 8's monitor has access to a lot of information that those tools don't (for now, though they could be modified to access it as well, via the Admin API if running on CF8 Enterprise). But even until then there are features each of them has that CF's monitor doesn't, and vice versa.

I know some instead want Adobe to offer the monitor somehow to those on Standard, whether at some price or in some new edition. The chances of that seem seem pretty slim for now, though certainly interested folks should make their concern known. And certainly, it's worth noting that one can run the CF8 monitor on the Developer edition.

But some rightly point out that they want CF server monitoring in production and they can't use Adobe's on CF8 standard (or on 6 or 7). (And they're asking for more than just monitors to tell if the server's up or down, etc. Sure there are plenty of tools to tell that, but they want real insight into the processing of requests, threads, queries and more, which only these tools can do.)

I just want to make sure those folks know there are indeed good, professionally managed alternatives to get that on CF8 standard and earlier versions of CF, and those options are at low costs and come with free trials. (Same goes for step debugging. While the new debugger in CF8 works only with 8, FusionDebug, from the same company that makes FusionReactor, works in 6, 7, and 8.)

As I wrote before, I don't feel that the availability of the CF8 monitor (or debugger) diminishes the value of the third party tools for those on CF8. Keep an eye on the monitoring category here in my blog as I'll continue to write more about all 3 monitors in the future. They each have their strengths and their place.

Note: This blog post is from 2007. 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.

If you'd not seen it, there are a slew of new CF8 articles on the Adobe CF Developer Center, including one I've done that's the first of a 4-part series on the CF8 monitor. The first both introduces the monitor and focuses on its uses first in development:

ColdFusion 8 server monitoring - Part 1: Using the Server Monitor in development

It's 8 pages printed, so lots of info there. I hope you'll get value from it. Since there's no feedback mechanism there, I'd appreciate if you'd share comments here of what you think of it. We writers get precious little feedback on our work, most times.

For now, it's even listed as a front-page article on the CF8 Dev Center. (FWIW, note that the URLs say "devnet" while the site itself uses the phrase "Developer Center".)

Future articles in my CF8 Monitor series will focus on using the monitor in production, then using the multi-server monitor, alerts, and snapshots, and finally several miscellaneous features and tips in part 4.

I should say finally, since many know I've talked a lot about FusionReactor and SeeFusion in the past, that, no, I don't think the CF8 monitor is a death knell for those tools (nor do I think the CF8 debugger will kill off FusionDebug). There's a place for both (especially if you're not yet on 8, and even afterwards possibly), and since the monitor is only in CF8 Enterprise, that especially keeps the other monitors in the running. I've written a more complete discussion of my perspective on these things:

Scorpio Debugger and Monitor: What's it mean for FusionDebug, FusionReactor, and SeeFusion?

Now, about it being in Enterprise, that's something I couldn't say in either my past entries or even in the current article on the DevCenter, as those were all written before the final release of CF8. I'm sorry if they read as if everyone using CF8 could use them. I really had no way to say otherwise.

That said, with the CF8 monitor being free in CF8, and especially with it giving us access to some awesome new info (which even the other monitors could now provide access to), it's worth learning what's possible. There's a lot more to it than you may think.

See the other entries I've done on the monitor. Some of them have info I couldn't fit into the DevCenter articles, or that may not be published for a few weeks.

Note: This blog post is from 2007. 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.

If you're a user of (or are considering using) FusionDebug or FusionReactor, two tools I've written about before, I want to point out that they have some new support resources.

Mailing Lists

First, there are now mailing lists (Google Groups) for each. This is something I pressed for since last year, and thankfully now they're enabled and there are good discussions already taking place.

http://groups.google.com/group/fusionreactor

http://groups.google.com/group/fusiondebug

Knowledgebase, Searchable and Browsable

There is also a new Knowledge Base where they've put many tech notes and answers to questions (other than those already in the FAQs). You can search it via the main support page, indicating which product and type of docs to search (it also searches the Google groups as well).

Finally, I'll share a little hidden gem. If you'd rather not search the KB, you can instead browse it. Here's a URL for each product:

Browse FusionReactor KB articles

Browse FusionDebug KB articles

I should note that they don't currently offer these links on the site, and in fact they may change in the future (since they're not published yet), but I don't think they'll mind me sharing it for now.

They're presented in numerical order, which isn't really chronological order, but clearly mixed in are discussions relevant to both old and new releases of the products, to be sure to note that indicator in the info at the bottom of each technote, if you have any question. There's some good stuff in there, and I'll be mining it for tips to share (here or on the mailing lists).

Note: This blog post is from 2007. 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.

OK, I'm playing a little trick here, and it's the first time I've ever felt the need to do it in 5 years of blogging (or 10, depending on how you count it). Anyway, I don't have any new content here.

It's just that I just noticed that the traffic for my 2nd blog entry on server monitoring was much lower than the first, yet it was posted about the time--and is just as important, if not more so for most people, than the first. So I've used a different title here to try to catch your attention. Looks like it worked! :-)

Please do go read the other, if you have still not. And let me know what you think, if you did. I'd also like folks to confirm what I'm seeing, as it seems almost too good to be true.

What's in a title? Everything, it seems

I can't help but fear that the title I used, "CF 8 Hidden Gem: Using the Server Monitor even without "starting" any collection...yes, TANSTAAFL", just confused people. "What's he mean by a collection?" And "TANSTAAFL"?

Actually, I wanted to say "Using the Server Monitor even without 'starting monitoring'", but obviously that would have been confusing, too. Indeed, I allude to this in the entry, about how the feature called "start monitoring" can lead people to think that the monitor doesn't do anything until you at least enable that. Not true, and that was the point of the entry! There's some amazing stuff "with zero overhead".

(Perhaps I also lost people with my play on the acronym, TANSTAAFL ("there ain't no such thing as a free lunch"), where I was referring to how there IS a "free lunch" here. Serves me right for being tricky. Again, I was scrambling to come up with a title because of the "start monitoring" challenge.)

Don't miss the features--truly hidden gems!

Anyway, the point is that if you're interested in the new CF 8 Server Monitor, whether for production user or not, you really ought to check out what I pointed out. I do think you'll be amazed.

Drop your comments on it over there, please. Not here. Don't want to create any further confusion! In fact, I'll disable comments on this one (another first).

Note: This blog post is from 2007. 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.

In my previous entry, I explained how different features of the CF8 monitor have different levels of overhead. I also pointed out that there was value even if you didn't enable any of the features at all. I can't stress that point enough. So yes, there "is" such a thing as a free lunch.

Some Cool Info: at ZERO COST

Even without pressing the buttons to start "monitoring", "profiling", or "memory tracking", you can see:

• how many pages are having errors, and details on each
• jvm memory used, and a detailed graph
• template cache status (how many pages, and total size of the cache), graphed over time
• query cache status (yep, the cached query count and total size)
• and more

Big deal, I may hear some say. Well, it is a big deal. That template cache and query cache status info is gold, and something that many of us have long lamented to have. Talk about opening up the black box. And with no overhead.

But wait (to quote the old Ginzu knives commercials from the 80's), there's more! And I mean, seriously cool info--again at zero cost.

Some Amazing Info! Again, at ZERO COST

Even without enabling ANY of the three buttons, you'll still be able to see all this really cool new info:

• active sessions (yes, a list of all sessions currently active, and if you click on each, the session variables and values currently assigned!)
• application scope memory usage (yes, as above!)
• server scope memory usage (yes, as above!)
• and more

All I can say is "wow". That is just so cool to get that, for free.

Don't we need to enable "memory tracking"?

I'm sure some are asking, "Well, isn't that what the 'start memory tracking' would be about?" Apparently not!

The help page for the monitor (the ? at its top right) describes the memory tracker as reporting "the queries and sessions that have used the most memory... and profiling information on the largest variables on the Requests by Memory Usage report". I'm willing to do without those in exchange for the info above, most of the time.

Now, on the other hand, the ellipses in my quote above (the "...") refers to where it also said the memory tracker provides "the memory usage of all application and server scopes". Hmm. Well, I'm seeing that without enabling it. Or maybe it's referring to some other aspect of the reports. There are indeed many reports in the monitor which had no data if none of the "start" buttons were enabled.

So what, then is the "start monitoring"?

As for the "start monitoring", according to the help it provides info on "active requests, slowest requests, active sessions, cumulative server usage, highest hit counts, template cache status, request throttle data, requests that timed out, requests with errors, and server alerts." Again, I'm not so sure about that. I'm seeing a few of those without using that feature.

I'll leave it to you to read what the "start profiling" says it enables.

I do think an argument could be made that the "start monitoring" button probably may contribute to confusion. I'm sure some will try to convey what I've written and talk about what you can get from "the monitor", and some will assume it's tied to enabling that button, when clearly it isn't. Maybe it could be called something else. Probably too late for that.

Joy in Mudville

So if you hear someone say, "we won't use the monitor in production", slap them roundly on the cheek...I mean, point them to this blog entry (and the last one). Seriously, it's tragic if someone would miss out on the value of the monitor simply because of an overinflated sense of fear.

But do have them check for any comments below, too. Maybe someone will correct me. Maybe my setup is somehow unique, but I've run many tests without these other features on and observed in real time the display of all the above.(And I have not had the "start" features enabled since I installed the RC a week ago, though I did have them enabled in previous betas. I can't believe that's having an impact.)

Finally, I'll point out that even if you don't want to (or can't for some reason) use the Server Monitor interface, you can get all the same information by way of the Admin API, and a new servermonitoring.cfc. Ray Camden's done a blog entry on it. Indeed he makes a similar observation about how he was able to get some of the methods to return data even if the docs said that a particular monitor feature must be enabled.

Check it out for yourself, and feel free to report here your corrections, or your delight. Hope that's helpful.

Note: This blog post is from 2007. 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.

The CF Enterprise Server monitor is more powerful than many may realize, yet naturally some are immediately concerned about its potential overhead, especially if they're considering running it in production. Things aren't quite as obvious as they may seem, or as many may assert.

Update: I've updated this entry now 5 years later, in 2012, to give a bit more context to what I said originally. No change in the message, just a little more info and perspective. (There's also no change in the impact of it, pro or con, in CF 9 or 10.)

First, it's indeed true that depending on what you enable, it *could* be very resource-intensive and could even bring down a server under load. But conversely it also can have ZERO impact--yes, even in production. I'll discuss that in my next entry.

But before that, I just want to take a moment and explain the key 3 features that control what impact, if any, it will have.

Note that there are three buttons at the top of the monitoring page which "start" different monitoring features. (If you don't see these buttons, just refresh the browser again to get them to appear.)

So what are the implications of starting each of the optional monitoring features?

• start memory tracking: this has the highest potential impact for overhead, which can be very substantial, even to the point of crashing your instance. And even on a low-traffic developer machine, you might see a big hit from running this. More on this in a moment.
• start profiling: this has much less overhead. It primarily enables tracking of database activity. The help page for the monitor calls its overhead "minimal", but I will note that on a CF server with tremendous DB activity, its overhead could be more substantial.
• start monitoring: This is the least impactful button. It's needed to at least see running requests, as well as to have Alerts fire. But even on a busy server I've rarely seen it have a negative impact. That said, you don't need ANY of the 3 buttons enabled to see at least some info. More below.

Definitely check out that help page (from the front page of the monitor) or discussions in my 4-part series of articles on the monitor to learn more about what each button does as well as more about the monitor itself and its many features.

About the Memory Tracking feature

You'll note that I hedged above on the impact of the Memory Tracking. Conventional wisdom is that it is indeed a potential server killer, and I can confirm that I've seen it many times in my CF server troubleshooting consulting practice. But I can also report that I've seen it running on production machines and having virtually no seeming impact. I kid you not.

I suspect it has to do with how many objects are in memory, how complex they are, how busy the server is, etc.

Now, some might propose that you use it only for brief periods (minutes, seconds) to gather some info for analysis, perhaps only in emergency. (I even said this in my initial version of this blog entry.) But many have found that things go horribly wrong on some CF instances the moment it's enabled. So it's probably best not to use it at all on live prod server.

You might be able to do it in a test/dev server, and you may get value form that in looking at the impact at least of individual or small numbers of requests. But beware also that some problems simply don't present themselves except under load (and often only in production, not even with load testing), so using it in dev/test may not help spot/understand/resolve all problems.

So does that mean there's no value if you can't use this feature in prod? Well, no. Remember, this is one of 3 buttons. The other two have less overhead (especially "start monitoring"). More than that, you can get value from the monitor with NONE of the buttons turned on.

Any value if none turned on?

Yes, don't miss this vital point: there is value to using the monitor even with none of the start buttons enabled. That is deserves its own entry. Who says there's no such thing as a free lunch? :-)

So if you hear someone say "don't use the monitor in production", please make sure they're clear on all this. There are 3 features you can enable, or none at all, and each provides different info at different costs--some of it zero.

Postscript: The buttons stay enabled after closing the monitor, and even over restart

I know I've discussed this elsewhere, but while I'm updating this entry let me reiterate the point: it's vital that you understand that if you turn on any of these buttons, they STAY TURNED ON, even if you close the monitor. And EVEN IF YOU RESTART CF. In fact, this is important enough to deserve its own entry. I'll post that now (as I update this in 2012), CF911: Using the #ColdFusion Server Monitor? Be aware that the "Start" buttons remain enabled.

Note: This blog post is from 2007. 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.

So by now most have heard that Adobe announced at cf.Objective() that Scorpio (now CF8) would include an interactive step debugger. And many may know I've long been a fan of FusionDebug, having written quite a bit about it, as well as the monitoring tools, Integral's FusionReactor and Webapper's SeeFusion.

A natural question on the minds of many is whether Adobe's entry into these markets is a death knell for these vendors? I don't think so, at all. Here are just a few reasons why. I'm sure I (and others) will think of more. Comments are indeed welcome.

1. Are you running 6, 7, or 8? - First of all, it's vital to keep in mind that the new CF 8 tools work only with CF 8. If you're still on CFMX 6 or 7, then you can't use the CF 8 debugger or monitor. I've heard some who thought that the new CF 8 Debugger might work worth the earlier releases. It does not. Of course, it's indeed another strong incentive to move up to CF 8, and there are more and more reasons being released all the time. But until you do, you can't benefit from them. Both SeeFusion and FusionReactor/FusionDebug work with CF 6, 7, and 8 (and the monitor tools also work with BlueDragon/J2EE and should work with Railo, Smith, and others.)

2. Do you have more than just CF to monitor? - Indeed, another point in the favor of the third-party monitoring tools is that more than just CFML servers, they indeed work with any Java server. And that's not just tools like Tomcat, JBoss, WebLogic, and WebSphere, but also includes other Adobe-specific tools that are also J2EE server-based, like Flex/LiveCycle Data Services, the older Flex 1.5, and more, and of course the Adobe J2EE server, JRun. FusionReactor's installer and "add server" feature will both recognize any of these automatically so that the one FusionReactor Enterprise Dashboard monitor can watch all such services, while SeeFusion offers a separate SeeJava product for watching such J2EE servers.

3. Does one size really fit all? - Another point to keep in mind is that each of the tools still do something that the other does not. I've said the same when contrasting SeeFusion and FusionReactor, and I can now say the same of them and the new CF 8 tools. Each can have their place in a developer/administrator's toolbelt. I could even argue that one could/should have them all, for whatever benefit each offers. The prices are low enough that it's not much of an issue.

4. CF 8 monitor API is public - With regard to the new monitor in CF8, Adobe has made it clear that it's just a particular (albeit very nice) Flex interface on top of an underlying API of admin CFCs that anyone can call. Naturally, this means that the other monitor tools could easily add whatever feature they (or users) may think must be added. (The FusionReactor folks will announce plans at CFUnited for integrating CF8 monitoring features into FusionReactor, so we should see some benefits and cooperation taking place.) Again, though, perhaps the reasons above may diminish the significance of needing to "keep up". Perhaps they can peacefully coexist.

5. If a tree falls in Times Square, it will make a sound - One can argue that a benefit of the new CF 8 monitor and debugger tools is that they will raise the profile of--and interest in the CF community for--such tools. And of course competition also breeds innovation. I think we already saw that between the two monitor tools themselves (and indeed between CF and BD, and others). In fact, still another outgrowth of this will be an increase in the opportunities for skilled folks (like those at these companies) to help CF developers make the most of the mass of information that these tools all provide. That will serve both companies well, since they each do training and consulting.

6. The past is prologue - Further to the last point, let's keep in mind that we can only compare the new CF 8 tools to the current versions of their third-party counterparts. Both Intergral and Webapper have told me (and others) that they've known these things were coming and have been considering enhancements for quite some time. The companies will be in a great position to watch and see what things people like (or don't like) about the CF 8 tools. I mentioned Intergral's plans above, and the SeeFusion folks are talking about extending their product to provide actual problem-solving intelligence, beyond just exposing metrics. Of course, we can expect Adobe will continue to evolve the tools as well (both before the final release and in later ones).

7. An abundance of riches - Finally, consider how fortunate we are in the ColdFusion community to have third party vendors who take risks to enhance the CF toolset and bring new and exciting professional tools to market--even before Adobe! We should support them if indeed they provide solutions to our problems. To the degree that we do (and they do), they will continue to survive.

Clearly I'm high on the entire CF tools market and think there's a place for all the companies and their tools.

Even so, there are some things that the CF8 monitor and debugger do add that are not currently in the other tools, and there's no doubt that for many, if they're moving to CF8 they may be happy with what they get built into those tools.

But it's not a zero-sum game with only one possible winner. Even if only a small fraction of the market remains interested in and using the 3rd party tools, whether because using the older CF releases, or for the features they offer, that's still a decent market for the toolmakers. And as they (and the market) evolve, the third party tools should continue to gain new fans.

I'll be writing (and speaking) quite a bit about both of the new CF 8 tools, as well as those from the other vendors, and how they all compare now and into the future.

It's just more testimony of why it's now really a great time to be involved in CFML.