Prerequisite knowledge
Readers should have some experience with coding or managing a ColdFusion server. Also check out the other parts of the ColdFusion 8 server monitoring series:
User level
Required products
Adobe ColdFusion Enterprise Edition (2016 release) 8 (Download trial)


21 January 2008

The first three parts of this four-part series introduced charts and graphs in the Adobe Coldfusion 8 Server Monitor, as well as using the monitor to abort troublesome requests (Part 1 and Part 2). Part 3 introduced the alerts and snapshots features.
In this fourth and final part, I'll introduce you to the Multiserver Monitor, which is key if you need to manage more than one server. I'll also get you started using the monitoring aspects of the ColdFusion Administrative API (enabling you to access all the monitoring data programmatically). Finally, I'll review Monitor configuration settings (including how better to monitor requests for frameworks or other front controllers where all requests go through a single index.cfm) and various miscellaneous aspects of the monitor.
Check out the other parts of the ColdFusion 8 server monitoring series:

An enterprise dashboard with the Multiserver Monitor

You may not notice, but there are actually two monitors available in ColdFusion 8: the Server Monitor and the Multiserver Monitor. Some may confuse this as being related to the Multiserver deployment mode option of ColdFusion Enterprise, but really it's for when you need to monitor any of several ColdFusion 8 servers, regardless of whether they're in your current environment or another location, remote from where the monitor is being run (subject to security implications discussed later). The Multiserver Monitor can monitor any form of deployment of ColdFusion, whether stand-alone, multiserver (multiple instances), or J2EE (WAR/EAR-style) modes. That said, only other Enterprise (or Developer) edition servers can be monitored, not ColdFusion 8 Standard edition (nor earlier releases of ColdFusion.)
The key benefit of the Multiserver Monitor is that you don't need to open a separate window for each monitored ColdFusion 8 server, as it offers a single dashboard-style interface that enables you to easily see high-level status information for multiple servers from one window, with the option to drill down into each server's own Monitor. (I'm referring to the monitor interface that's been discussed so far in this article series.)
Opening the Multiserver Monitor
You open the Multiserver Monitor in nearly the same way as the basic monitor. The option to open it appears in the Server Monitoring page of the ColdFusion Administrator (Server Monitoring > Server Monitor), a second button labelled Launch Multiserver Monitor at the bottom of its page (see Figure 1).
The Launch Multiserver Monitor button
Figure 1. The Launch Multiserver Monitor button
You can also launch the Multiserver Monitor from a URL entered in your browser directly, as:
The first time you open the Multiserver Monitor, you will be prompted to create a master password. This is used because you would likely configure the Monitor to watch multiple servers, and you want to ensure that someone else who may open the Multiserver Monitor is properly authenticated to access this one Monitor that monitors them all. (You will also specify the login security for each server to be monitored when you add a new monitor to the Multiserver Monitor, as discussed in the next section.)
Adding new monitors
When you open the Multiserver Monitor for the very first time, there will be no servers listed as being monitored, not even for the local machine from which you launched the Monitor itself (see Figure 2).
The initial screen of the Multiserver Monitor
Figure 2. The initial screen of the Multiserver Monitor
To add new servers, click Add (at the top left of the screen in Figure 2). This will open a new window (see Figure 3) where you provide the servername, port, and administrator login information for the server to be monitored.
Adding a server to be monitored
Figure 3. Adding a server to be monitored
Use whatever domain and port you would use to access the ColdFusion Administrator on that server. Do not specify http:// and such as part of the domain name. Just provide the domain name. Note that the port used will depend on whether you've deployed ColdFusion using its built-in web server or an external web server (like IIS or Apache). The Context root field needs only to be populated if the server to be monitored was deployed using the J2EE mode, in which case you'll name the context root in which the web application (or WAR/EAR file) was deployed.
Finally, you need to specify authentication information to access the server, using the same information used to log in to the server's administrator. You can select the HTTPS option if the ColdFusion Administrator is on an SSL-enabled web server, in which case your authentication information will be encrypted when sent to the server. And since ColdFusion 8 offers a new option to define multiple Admin users, note that this Add Server interface offers the option to provide a username. If you have not defined one, just use admin and then use your Admin password. Even if you've chosen to have no Admin password security at all in the ColdFusion Administrator, simply enter any username and password, as you cannot leave them blank here.
As a first test, try adding the server from which you are running the Multiserver Monitor itself. For my local stand-alone development edition deployed using IIS, where I have not defined multiple admin users, I used localhost for the server, 80 for the port, admin for the username , and my ColdFusion Administrator password.
If you try to name a server on a domain other than that which you used to launch the Multiserver Monitor, you may receive an indication of Permission Denied. This is caused by a default security feature whereby a server can't be monitored by a remote Multiserver Monitor without granting it explicit permission.
Of course, the real power in the Multiserver Monitor is in adding multiple servers, but even with just one server monitored, you can explore the features of the Multiserver dashboard, as discussed in the next section.
Observing the status of a monitored server
Once added, a new monitor box will display for that server (see Figure 4). Note that if you do add multiple servers, they will display alongside each other in this window.
Monitoring a single server
Figure 4. Monitoring a single server
If the settings for a given server are correct and the Multiserver Monitor successfully connects to it, the Status line (at the bottom of that box) will show Logged In. If it shows Unreachable, that means either that the server is stopped or the configuration settings are incorrect. If the status shows Permission Denied, again that's a problem of configuration discussed in the section, "Securing the monitoring of your server."
If you receive any errors and need to correct a mistake, you can edit the connection information for a server by selecting it and choosing the Edit button, at the top of the screen. (Once you have multiple servers defined, you'll be able to tell which is selected because the box for the server will show the yellow background, as you see with the lone server shown in Figure 4.)
What the monitor box shows
When successfully connected, the monitor box will show such high-level information as how long the server has been online, whether any alerts have been triggered, and it will also show a "warning" when any given alert set for that server achieves 80% of its threshold.
As discussed in Part 3 of this series, alerts can be configured in the Server Monitor to detect whether too many requests are taking too long, average response time is too high, too much memory is being used, or too many requests are timing out. When any alert is triggered on the server being monitored, the Multiserver Monitor box for that server will show a red X next to the server and a phrase next to Alerts to indicate the kind of alert, such as "Slow Server", as shown in Figure 5.
A Slow Server alert detected
Figure 5. A Slow Server alert detected
If you've seen this display and thought that was all that the Multiserver Monitor provided, you might conclude that it's rather anemic. You may want to see more about the current status of the server(s) being monitored, such as how many requests are running, how much memory is in use, and so on. Fortunately, there is still more data available. You just need to know how to ask to see it.
Don't miss the Detail View
This could be a hidden gem that many miss. There's an available Detail View icon at the far right of the display of the Multiserver Monitor (in Figure 4) that displays a new detail page for all the servers being monitored. The detail page is shown in Figure 6.
The Detail View
Figure 6. The Detail View
That's quite a bit more detail! For each monitored server, you're shown how many active requests are currently running, how many requests per second, the average response time of requests, whether there have been any alerts, the amount of JVM memory in use, how many application errors there have been, and how long the server has been running.
This detail is only about what's going on at this moment. To see any sort of historical perspective (such as why the server was slow a few minutes ago), you'd need to use the Server Monitor (discussed in the first two parts of this series), and I'll show you soon how to get to that from within the Multiserver Monitor.
A couple of tricks in the Detail View
But there's really still more available on this Detail View than may be obvious: first, if you place your mouse over some of the columns, you'll see that they show still more data. For the Active Requests column, it splits that number into the number of active and queued requests. If you place your mouse over the JVM Memory column, you'll see the used and free memory. Finally, if you place your mouse over the Errors column, you'll see that the error count actually sums errors and page timeouts.
You may wonder why you should have to place your mouse over these columns to see this information. You don't. Notice that the bottom of the screen has lots of extra fields, which are initially blank when you come to this screen.
If you select one of the servers in your list (while on the Detail View), however, that line will turn blue and the fields at the bottom of the page will be populated for that server, with the very data shown in the pop-ups.
So why are there two approaches? The pop-up feature is nice when you have many servers listed and you want to get quick insight into one of them while reviewing the list of servers. It simply saves you having to select one just to populate the bottom of the screen and move your eyes to that location: Use whichever approach serves you best. Figure 7 shows both features enabled: a server selected to populate the bottom data and a pop-up displayed.
The Detail View with server selected and pop ups shown
Figure 7. The Detail View with server selected and pop ups shown
You can return to the main view of the Multiserver Monitor (from the Detail View) by clicking the icon just left of the Detail View icon, which is labelled Quick View (if you place your mouse over it.)
Drilling down into the Server Monitor for a selected server
It's nice that you can get more high-level overview data about a selected server, but you may want still more. Of course, the main Server Monitor is available for each server, and you can drill into it to find out much more.
Whether on the detail or the main/quick view page, select a server and click the Monitor button shown at the top of the list of servers (where the Add and Edit buttons are.) That will launch the Server Monitor for that server in a new window/tab of your browser.
Monitoring communication errors with Multiserver Monitor-to-Server Communications
There's one last interface feature of the Multiserver Monitor that requires some explanation. You may notice an Errors tab at the top of the Multiserver Monitor, visible in most of the previous figures. It does not list application errors (errors that would be logged in the application.log file of ColdFusion), but rather, it shows errors in the communication from the Multiserver Monitor—a Flex application—to the ColdFusion server being monitored. See Figure 8.
Errors tab for a server
Figure 8. Errors tab for a server
It shows all the monitored servers and whether any have had errors, and if so, for each, when it last occurred (and how long ago), what the error fault code was, and a string of info and detail about the error. Like the aforementioned Details view, if you select the line for a given server, the bottom of the page shows the same information, but with more room to see each string's details.
(If you're interested instead in tracking application errors, note that those errors appear in the Server Monitor, in the Errors > Requests with Errors page of the Statistics tab, as discussed in Part 2 of this series.)

Some possible challenges using the Multiserver monitor

That's it for the interface features of the Multiserver Monitor. Still, there are few challenges in using the tool that you might encounter.
Securing the monitoring of your server
As you contemplate the power of this tool to watch any CF8 Enterprise or Developer edition server, you may wonder just how one can limit which servers can be monitored, or rather, how can you keep someone else from monitoring your own server?
Of course, you saw earlier in adding a new server to the Multiserver Monitor that one needs to know an administrator username and password for the server to be monitored, but for many that's simply not enough security. You might want to prevent your server from being monitored at all.
Here's good news: By default, the Multiserver Monitor can only monitor the server from which it's launched. It's not that you can't monitor other servers, of course, but for security reasons, a Flash movie playing in a web browser is not allowed to access data that resides outside the exact web domain from which the SWF file originated. That's comforting news to the security-conscious, but it can also be a hindrance as you try to add new servers you want to legitimately monitor, if you're not expecting it. How do you enable it if desired?
Understanding the multiservermonitor-access-policy.xml file
For a ColdFusion server to be monitored by a Multiserver Monitor running on a different domain, you must take an extra step regarding the configuration of that server to be monitored. Here's an example: The Multiserver Monitor loaded from server A on cannot monitor Server B on, unless Server B is configured to permit requests from Specifically, the multiservermonitor-access-policy.xml for the ColdFusion server running on Server B of must be configured to permit monitoring from
In the stand-alone deployment mode of ColdFusion, this multiservermonitor-access-policy.xml file would be found in the \coldfusion8\wwwroot\CFIDE directory, if you installed ColdFusion to use its built-in web server, or in the \CFIDE directory within a webroot directory of your external web server if you've configured ColdFusion to use one. Again, this is the directory where your ColdFusion Administrator is configured for the ColdFusion server. Similarly, in the Multiserver deployment, this would be in the deployed instance, such as \JRun4\servers\cfusion\cfusion-ear\cfusion-war\CFIDE, if using the built-in web server
The file has just one significant line, commented out by default:
<!-- <allow-access-from domain="*" /> -->
With it commented out, it means that requests from a Multiserver Monitor in another domain are denied. If un-commented, it would permit monitoring from Multiserver Monitors running on any domain at all (this is something you would never want).
If you want to permit the Multiserver Monitor on another domain to access this server, un-comment the line and name in the domain attribute the domain (or IP address) for that remote server. (Note that this is not about adding the IP address of the client who is running the Multiserver Monitor, but rather the server running the Multiserver Monitor!)
For instance, if the server at wanted to permit monitoring from the Multiserver Monitor running at,'s xml file could be modified to have the line:
<allow-access-from domain="" />
The Flash security model uses the exact domain name, so it's important to note that while this would permit access from a Multiserver Monitor loaded from, it would not permit access if the monitor was run from If that's the actual domain from which you want to run the Monitor, you should instead specify the domain value either as or note that you can use a wildcard, as in * You cannot use wildcards for IP addresses.
If you want to permit access from multiple different domains, note that you can specify multiple entries to name multiple remote domains, such as:
<allow-access-from domain="*" /> <allow-access-from domain="*" />
You can learn more about this sort of cross-domain xml file, which has long existed for use with Flash applications, in the TechNote 14213: External data not accessible outside a Flash movie's domain. While it discusses crossdomain.xml files in particular, this multiservermonitor-access-policy.xml is merely a differently-named version of such a file. (The cross-domain issues apply only to the Multiserver Monitor, because as a Flash-based interface it can communicate with a server other than that from which it's requested. The Server Monitor, while also a Flash-based interface, communicates only with the server from which it's requested.)
You can edit this multiservermonitor-access-policy.xml file and it will take effect immediately, without needing to restart either the server being monitored or the one doing the monitoring.
Be careful with browser caching and the cross-domain file
Although the change above takes effect immediately, there is a potential gotcha with browser caching.
Let's explain it in the context of adding a new server to the Multiserver Monitor list of servers (Figure 3). If you add a remote server before making this cross-domain policy change on that remote server, the box shown in the Multiserver Monitor (as shown in Figure 5) will display the words Permission Denied in its Status line, because you had not yet made the cross-domain configuration change.
Once you make the change, however, the error may not go away immediately. The problem is that the browser (the one showing the Multiserver Monitor) will have cached its request for that XML file. The Flex/Flash-based application that is the Multiserver Monitor requests this file from the remote server to determine if it's permitted to access it remotely this way, and it saves it for future requests.
You can manually view the remote server's XML file using a URL such as:
If you do that and it shows the proper values have been set, yet the Monitor still won't permit access and showing the error in the status line, you need to force the browser to refresh the SWF file showing the Multiserver Monitor. This is a challenge common to Flex/Flash-based web applications pulling data from a remote web server related to interaction with built-in browser caching features (which can very between browsers and depending on options set within the browser by the user.)
In most browsers you can force the browser to refresh a file it's requested by holding the Shift key while refreshing (using the mouse to click the refresh button or clicking Control-R). If that doesn't work, there are still other techniques which may help (passing random query strings, using HTTP proxy tools to analyze the problem) but since it's likely you will add servers infrequently, you can also just close the browser (perhaps all instances of it) and reopen it, and then run the Multiserver Monitor.
It's worth noting about this cross-domain policy issue that, to Flash (and the monitor), domain names and IP addresses are not resolved as being identical, even if the browser sees them as such. As a test, you'll find that if you view your localhost Multiserver Monitor (as in http://localhost/CFIDE/administrator/monitor/launch- multiservermonitor.cfm), and then try to add your local server to the Multiserver Monitor using as the "server" field (as in Figure 1), this too will fail initially. You must add localhost as a permitted domain in the cross-domain file discussed above (or vice, versa, if you browsed it as localhost but added the server as, in which case you'd need to use localhost for the "Server"field.).
Multiserver Monitor configuration is stored per the domain used to open it
To wrap up this presentation of the Multiserver Monitor, and especially with regard to trying to access a server by both its domain name and IP address, there's a related but very different concern when it comes to how you request the Multiserver Monitor in your browser.
If you browse the Multiserver Monitor through one domain name (like localhost), and configure it to watch various servers, and then browse the Multiserver Monitor again but through that server's IP address (like or another domain name (like your real servername) as compared to the first one, it will show the Multiserver Monitor, but all your configuration settings (like the list of servers you previously configured) will be lost. Why is that?
As a Flash/Flex application, the Multiserver Monitor is a client-side application that talks to back-end servers. It needs a place to store the configuration information entered, and like most Flash/Flex applications, it uses Flash SharedObjects (as an alternative to cookies) to save the configuration information you've entered. SharedObjects are stored on the local disk of the user viewing the monitor, and they are also unique per domain (or IP address) used to launch the SWF file, which explains the problem. Launching the Multiserver Monitor with different URLs (on the same server) will therefore have different configuration settings.

Programmatic monitoring with the Admin API

Everything in this and the previous articles of this series has been about using the Flex-based Monitor and Multiserver Monitor interfaces to track what's been happening on the server(s) being monitored, and it's helpful that Adobe has provided those interfaces. They reflect best practices in rich Internet application (RIA) development and really make it easy to watch what's going on in your environment.
Inevitably, there may be something you want to see that's not shown there, or you may want to see it in a format that it's not (perhaps graphed), or you may want to view it for a different timeframe than is shown in the monitor, or you may want to log information to a file (something lacking in the CF8 Server Monitor).
The good news is that there's nothing that the ColdFusion 8 Server Monitor does that you can't programmatically create by way of the ColdFusion Administrative API, or Admin API. Introduced in ColdFusion 7, this set of ColdFusion components (CFCs) provide various forms of programmatic access to administrative functionality. What's new for ColdFusion 8 is that there is a new CFC devoted to server monitoring called servermonitoring.cfc. At this time, there's not much documentation at all on the Admin API in general, let alone this CFC in particular. Fortunately, there are ways to view the available methods and properties of this Admin API CFC.
The easiest way may be to use the built-in component explorer in ColdFusion by browsing the URL http://[server:port]/CFIDE/adminapi/servermonitoring.cfc, as in http://localhost:8500/CFIDE/adminapi/servermonitoring.cfc or Note that you're pointing to the CFC within the adminapi directory under CFIDE (the same directory where the ColdFusion administrator is located).
When you browse a CFC this way, you will be prompted for the ColdFusion Server Administrator or RDS password (it doesn't seem to currently support the new multiple admin user feature in ColdFusion 8), and then shown high-level information about the CFC (see Figure 9).
Browsing the Admin API's servermonitoring.cfc
Figure 9. Browsing the Admin API's servermonitoring.cfc
Here you can see first a long list of the many available methods, and then, paging down, you'll find information about each available method, including its expected arguments (if any) and what kind of information it returns. You can use these to invoke the component methods just as you would for any other CFC.
Here's a very simple example that displays counters of the kind of requests being made against the server:
<cfscript> // login to the Admin API admin=createobject("component","CFIDE.adminapi.administrator"); // provide your admin password admin.login("adminpw"); // create the server monitoring instancesmon = createobject("component","CFIDE.adminapi.servermonitoring"); </cfscript> <cfdump var="#instancesmon.getHitCountStats()#">
Note that any attempt to use the Admin API first requires that you programmatically log into the Administrator. The first two lines of code do that, creating an instance of the administrator CFC and then calling its login method, passing in your password. This example then creates an instance of the servermonitoring CFC and then invokes the getHitCountStats method, displaying its result (a structure) via cfdump. You can view more about the returned structure keys for a method by clicking on that methodname in the help offered in the component explorer, as shown in Figure 10.
Details of the information returned from getHitCountStats()
Figure 10. Details of the information returned from getHitCountStats()
It's important to note that some of the methods, or some of the properties returned by the methods, may require that one or more of the monitoring features to be enabled. These were referred to in Part 1 and Part 2 of this article series as related to Start buttons in the Server Monitor (monitoring, profiling, and memory tracking), but note that these can also be enabled programmatically through either the startMonitoring or setMonitorSettings methods. This could be useful, as you could start a particular monitoring feature, get some needed data, and then turn it off. Just be aware that if you enable these settings, they remain enabled (just as the Start buttons do) until you disable them, as discussed in the final section here, "Start button settings remain enabled."
Along those lines, some of the documentation discussing which monitoring feature must be "started" for a given API method or interface feature is not always complete or correct. For instance, in Figure 10, it says for the getRealTimeStats function that "monitoring must be turned on for the function to work," but it does indeed work and return some useful data regardless; it's just that some of the values will be zero (of course, they can also be zero even if monitoring is enabled, simply because they have no value).
I'll leave it to you to explore on your own the other available monitoring API methods.

Tweaking the Monitor in the Settings section

We now turn our attention to the very last bit of unexplored territory in the Server Monitor interface. Going back to the basic Server Monitor discussed in the first three parts, it's important to note that you may benefit from tweaking some available settings, such as how often reports and graphs are refreshed, and which items should or should not be monitored or profiled, and more.
The Server Monitor offers a settings page, accessed by way of a Settings icon that appears at the top right of the monitor, immediately left of the online help icon and to the right of the Start monitoring buttons. See Figure 11, which shows the pop-up window that appears when you press it.
The Server Monitor Settings icon and page
Figure 11. The Server Monitor Settings icon and page
The settings page has four tabs controlling different settings.
The General settings tab
The General settings tab has three fields for overall control of timing in the Monitor (refresh reports every x seconds, refresh graphs every x seconds, and calculate average response time every [or over] x seconds). When the server is running without any problems, you may choose to increase these values so as to reduce the load on the server (for how often the Monitor requests the data from the server). When a problem is reported with the server, or when a developer is profiling an application, you may prefer to set the refresh interval(s) to a lower value, resulting in a faster refresh, which will provide updated information more quickly.
The tab also has another setting, an option labelled Shrink Template Path, which controls whether any display of template paths (within the monitor) should be abbreviated to remove some intermediate portions of the path when displayed. For instance, consider a request at c:\inetpub\wwwroot\somedir\somefile.cfm. With this setting enabled, the monitor will display the file or path, such as in the Slowest Requests page, as c:\inetpub\...\somedir\somefile.cfm. If you place your mouse over it, a pop-up window displays the complete path.
The Filter Settings tab
The Filter Settings tab also has three settings. The first controls whether the ColdFusion Administrator itself should be monitored. The second two permit you to control which requests are (or are not) monitored using the Server Monitor.
By default, the Server Monitor collects information about all ColdFusion templates in the webroot directory and its subdirectories and in any directories specified on the Mappings page of the ColdFusion Administrator. However, you might not want to monitor all requests on the server.
The Exclude Paths option lets you specify a path to exclude so that the Server Monitor does not collect information about files in that directory or in any of its subdirectories. This capability is especially useful in restricting monitoring on production servers, where you may want to prevent the monitor tracking some subset of code.
There's an available Include Paths option, but it is not the opposite of Exclude Paths. Rather, it controls whether to monitor any subdirectories of an excluded directory.
Otherwise, all files are monitored, and you can't configure the server to monitor some particular directory/directories to the exclusion of all others.
The Profiling Filter tab
The Profiling Filter tab has only two settings, identical to the exclude/include path settings of the Filter Settings tab. The documentation suggests that this controls whether profiling operations specifically are tracked for requests in the named path, though in my testing I could not prevent profiling using this feature.
The Aliasing tab
One challenge some developers may find with the Server Monitor is that it often reports only the template path (absolute path) for a request being displayed, without the querystring used for the request.
Possible issues with Frameworks and Front Controllers
This is very problematic with frameworks like Fusebox, ModelGlue, Mach-II, and so on, which all tend to route requests through a single file, like index.cfm (often referred to as a front-controller).
The problem is that all requests that might be displayed for such an application could all display as using the same template (that index.cfm) and thus would be indistinguishable from each other. Consider requests such as the following:
http://localhost/fbapp/index.cfm?fuseaction=store.productDetails&productid=30 http://localhost/fbapp/index.cfm?fuseaction=store.viewcart
These are two very different requests, one for product details and one for a display of all items in a shopping cart. They would lead to execution of very different operations in underlying CFML templates. Yet, if displayed in the Server Monitor, they might each show their template path as:
With no further way to distinguish them from each other, you can't tell if one of these in the Slowest Requests page of the Monitor is the product details or view cart action (unless you drilled down into the request details to find and view its URL variable values). When trying to review higher-level data displays, however, this is very inconvenient.
Using the Aliasing tab to solve Front Controller problems
The solution is the Aliasing tab, where you can define that for a given template the monitor should watch for a given "action parameter" (such as the fuseaction querystring variable in the URL above). The monitor then instead shows the value assigned to that action parameter (such as store.viewcart) in the monitoring pages. You also specify an alias, which is a phrase that appears in place of the template path and file name.
For example, consider if you defined the aliasing with the template path to be C:\Inetpub\wwwroot\fbapp\index.cfm (it must be an absolute path to a specific file), the Alias Name to be fbapp, and the Action Parameter to be fuseaction. If your previously mentioned request was run:
The resulting display within the monitor (where previously it showed just the template path to the index.cfm file) would now show:
That at least distinguishes it from a request for the store.viewcart. Note, however, that it doesn't show the productid. That, too, may be useful. Again, you can see the productid if you drill down into the request to see all of its URL variables, but another solution is to add productid as yet another action parameter in the alias (multiple values are separated with commas in the aliasing interface for this field). Requests that have no productid (like the viewcart) would show up with an empty value for productid:
Using the Aliasing tab to segregate requests differing by querystring
My last point demonstrates that the aliasing feature could be used even for requests that do not use a front-controller style of coding. Consider that you may simply have some request where you want to track individually (or distinguish) the requests that are made for one template with different query string or URL variable values. Again, you could just define the action parameter to be the query string variable on which you want to track requests to this one template.
Note here that while in the previous section I defined the Alias Name to be just the small phrase "fbapp", you could just as well choose to specify the alias name to be the full name of the template path, so that it shows up as normal in the monitor. While it could be a long value, recall that the aforementioned Shrink Template Path feature will collapse the full template path into an abbreviated form anyway, leaving room to show the action parameter as well. It's entirely your choice.
Finally, you can define as many aliasing mappings as you'd like, for the different applications and subdirectories where aliases may be useful.

Various miscellaneous aspects of the Monitor

We're nearly done with our round-the-world tour of the Server Monitor interface. I will close with just a few random points to note about the Monitor.
The Refresh, Reset All Statistics buttons
First, note that just to the left of the Settings icon discussed previously there is a Refresh icon, and left of that is a Reset All Statistics icon. You can confirm each of these by simply placing your mouse over them, and a tooltip will display their name.
The Refresh button can be used any time that you're viewing a page in the monitor and you don't want to wait for the defined refresh interval (discussed in the description of the General settings tab above), to cause updated information to be shown. It may be worth noting, however, that there are some instances (such as when viewing some drill-down/detail pages) where the Refresh button will not update the page at all. You'll need to return to the list page and re-select the item you're viewing to see updated information.
The Reset All Statistics button can be used when you want to clear all the Server Monitor statistics displayed, which may be useful when you're performing testing or debugging. All the displays of lists (such as slowest requests or queries by memory usage) will be cleared, though some lists will not (like active sessions, since they're not reflecting past requests but instead the current status). Also, the memory chart and some charts in the detail pages (discussed in Parts 1 and 2) are not reset.
Flash Remoting must be enabled
I've mentioned a couple of times that the Server and Multiserver Monitors are Flex/Flash-based applications. Something I've not mentioned to this point in the series is that, in order for the Server Monitor (and Multiserver Monitor) to work against a given ColdFusion server, that server must have the option Enable Flash Remoting support enabled in the Data & Services > Flex Integration page of the ColdFusion Administrator, since the monitors use Flash Remoting to communicate with the server.
Start settings remain enabled
Another point to keep in mind regarding the monitor is that if you enable any of the start buttons (monitoring, profiling, or memory tracking) or enable them using their Admin API equivalents, those settings remain in effect even when you close the monitor, and indeed, even across restarts of the ColdFusion server.
Be careful about leaving them on longer than you may require. Since the memory tracking especially is very processing-intensive, with the profiling less so and the monitoring even less, there's the chance that you could enable these and pay the price of their overhead when you aren't ever running the monitor or using the Admin API equivalent features discussed earlier in this article. Be careful not to leave them enabled when not being used.
That said, I want to reiterate a point I made in Parts 1 and 2: there are many, many features of the Server Monitor (and Multiserver Monitor) that remain very useful even with none of those start buttons enabled.
Monitoring even when the server is becoming unresponsive
It's also important to point out that the architecture of the Server Monitor is such that it even remains useful when the server is under heavy load or even has become non-responsive. Of course, if the JVM that underlies ColdFusion dies, then the server and the monitor will die with it. But as long as ColdFusion is running, you may find that you can get into the Server Monitor (or the Multiserver Monitor can access that server) even when you can't otherwise make typical requests of other CFML pages against the server.
That said, there's a trick to consider: the pages that launch the Server Monitor (launch-monitor.cfm, mentioned in Part 1) and the Multiserver Monitor (launch-multiservermonitor.cfm) are themselves .cfm files, and you may find that if you try to launch them, during a period of inaccessibility, you can't. But consider that these pages really just load the underlying SWF files that present the Flex-based monitor interfaces: You may find in such situations that you can indeed load the SWF files directly instead. Their filenames are ServerMonitorUI.swf and MultiServerMonitor.swf, each in the same directory as their corresponding CFM files ([server]/CFIDE/administrator/monitor/).

Where to go from here

I hope this four-part series on the Server Monitor has not only introduced you to its riches and capabilities, but also encouraged you to explore and benefit from it, whether you're a developer and someone responsible for production implementations of ColdFusion. It's just great to be able to see into underlying details, status, and operations of the server in ways you've never been able to before.
Where can you learn more? Besides its online help, the Server Monitor is discussed in the ColdFusion 8 manual, Configuring and Administering ColdFusion, which has sections that cover "Specifying Server Monitor Settings" and "ColdFusion Server Monitor API," specifically.
Check out the other parts of the ColdFusion 8 server monitoring series: