WebSphere XD v6.0.1 Visualization



Search Tips   |   Advanced Search



There are several different functions which can be used to provide a closer view of what happens in a complex WebSphere Extended Deployment (XD) environment. The Administrative Console helps us to learn where in a virtual resource pool applications are running, shows us performance data, views what decisions are made regarding deployment of applications and allocation of hardware.

The visualization features in WebSphere XD consist of both transient run time configuration information, as well as performance statistics. There are several perspectives and levels for each of them. For example we can get performance statistics on pool level, WAS level, machine level, and application level.

We can configure the statistics data to be logged for further use with external tools for example spreadsheet programs.

In addition we can use visualizations from the console to take administrative action directly, for example stopping servers, altering service policies, setting operation modes, and so on.

Although Internet Explorer 6.0 and Mozilla 1.4 or 1.7 are supported browsers for the Administrative Console, IBM recommends to use Internet Explorer if we wish to display the Runtime Operations views that WebSphere XD offers you.

To display these views, we must install the Adobe Scalable Vector Graphics (SVG) Viewer.

At the time of writing this book, the SVG Viewer did not support Mozilla, only Internet Explorer and Netscape Navigator.

The browser version is detected when the user views the dynamic charting. SVG is then converted to JPEG format if the browser is Mozilla. It does not have all the functionality of SVG but still displays the statistics. However, we found that some views might not scale correctly and some other views (such as the Runtime Map) cannot be displayed at all.


Runtime topology

To enter the run time topology go to...

Runtime Operations | Runtime Topology

With the run time topology page, we can view and change our WebSphere XD environment. We can adjust configuration options to stay informed of the activities occurring in the environment, and to make changes based on the information yielded in the topology view and dynamic charting.

We can select from node group, application and service policy perspectives. These perspectives determine which topology and charts display in the page. Within the perspectives, we can choose to view all the information, or information for a specific instance.

Here is the menu tree for our sample topology:

Figure 6-1 Runtime topology with menu tree

Left-clicking an element in the topology opens a menu with options from which we can choose. These options range from configuring or viewing server logs to stopping our server.

The run time topology depicts a momentary state of an XD environment. Hovering over an underlined element provides information about that element. This information refreshes on a configurable interval to help with our decision making. We can view information such as:

  • Application placement activity
  • Deployment of dynamic cluster instances
  • CPU usage per node
  • Dynamic workload manager (DWLM) weight per application server instance
  • Process ID per application server instance
  • Names of autonomic controllers (the location of a controller is indicated by an icon next to the node, hovering over the icon displays the name)
  • Server health status
  • Transaction classes
  • Work classes


The node group perspective

In the node group perspective we can see different performance, load, placement and health information about nodes belonging to the node groups. We can see CPU usage, can figure out which application servers are up and running and if health conditions are breached. We can also see where the different autonomic managers are located.


Finding the autonomic manager location

The autonomic managers are represented by the following icons in the menu tree:

Application Placement Controller one per cell
Health Management Controller one per cell
Dynamic Workload Management Controller one per dynamic cluster
Autonomic Request Flow Manager one per cell located on an ODR
Work Profiler one per cell located on an ODR

We can hover over these icons to get tooltips that show what an icon is standing for and to get some additional information. For example, when hovering over the DWLM Controller icon we can also see which dynamic clusters are handled by this controller. One controller can handle more than one dynamic cluster.

Figure 6-2 Node group perspective: Tooltip for DWLM controller


Displaying health and placement problems

On the left-hand side there is a grey bar. Health or placement problems are indicated by this icon on that bar if we have expanded to application server level. If we have not expanded the tree to application server level, we see a pale version of the icon. Hovering over the icon shows we more information about the reason.

Figure 6-3 Node group perspective: Tool tip for health event

We can alternatively hover over the icon or hover over the object name in the row where the icon is displayed. Both approaches display the same information. The same is true for clicking an icon or object. This displays the same menu.


The object menus

Left-clicking the blue object names or the icons displays a menu. The menu lists the allowed operations for this object. Nearly all objects have a Chart entry in their menu. Clicking Chart opens a charting tab for that object in the right frame of the Administrative Console.

Figure 6-4 Node group perspective: Application server menu


The node group menu

Clicking a node group shows three menu entries:

  • Chart

  • Configure

    This option leads us to the node group configuration page in the Administrative Console (normally accessed via System administration | Node groups).

  • Show/Hide Sick Server

    This is a toggle function: Using the Show/Hide Sick Server menu entry expands the tree to the sick servers in this node group. If the tree is expanded, this option collapses the tree. Noter that this menu option is only available when we have a sick server in our environment.


The node menu

Clicking a node name or icon offers these three menu options:

  • Set Maintenance Mode

    When we set a node into maintenance mode the icon for that node changes to . This option is equivalent to the Set Maintenance, Immediate Stop button under...

    System administration | Nodes

    All processing on that node is stopped and needs manual restarting when the node is re®-enabled.

    A node in maintenance mode displays a different menu containing only Unset Maintenance Mode and Configure.

  • Set Maintenance Mode, Leave Processes Running

    This function is equivalent to the Set Maintenance button under...

    System administration | Nodes

  • Configure

    The Configure option takes us to this nodes' configuration page. This is the same as going to System administration | Nodes| node.

  • Chart

    The chart option has been added to the node menu in WebSphere XD V6.0.1. It is available in both normal and maintenance mode.


The application server menu

This menu has five different options.

  • Chart

  • Stop Server

    Stops the server and negates any current requests no matter what state they are in.

  • Smart Stop Server

    This option does the following:

    • Disables the dynamic workload manager (DWLM) for the server, removing this server from the set of servers DWLM considers for work load.

    • Sets the weight of the server to zero. The server weight returns to its normal value if it is restarted.

    • Checks for up to 30 seconds for any active HTTP requests running in the server for active HTTP sessions.

    • Runs the server shutdown sequence, if the first three steps return successfully and no active requests are running in the server.

  • Show Server Logs

    This option brings us to the runtime tab of the JVM Logs page of this server. This page is normally accessed via Troubleshooting | Logs and Trace | server_name | Logs | Runtime tab.

    Here we can take a look at the System.out and System.err files of this process by clicking the corresponding View button. The log is shown and clicking the OK button brings we back to the runtime topology.

  • Show Runtime Tasks

    This option is only shown if a health or placement issue is open for that server indicated by the icon. Selecting this menu item brings we directly to the runtime task page which is otherwise accessed via Runtime Operations | Task Management | Runtime Tasks.


The application menu

When bringing up the menu for the application modules of a server, we see these options:

  • Chart

  • Configure

    Selecting this option brings us to this applications' configuration page (Applications | Enterprise Applications | application_name).

  • Configure Service Policy

    Brings us to the Service Policies configuration panel (Operational Policies | Service Policies).

    All the aforementioned objects are found under the Nodes tree of a node group. There are two more trees available under some node groups:

    1. Deployment Targets
    2. Specialty Servers


Deployment Targets tree

The Deployment targets tree gives infomation about the three different possible deployment targets:

  • Application server (if an application is not installed in a cluster)
  • Cluster (if an application is deployed into a static rather than a dynamic cluster)
  • Dynamic cluster

Depending on the deployment target type, we then have different context menus. All three deployment targets offer these two options:

  • Chart
  • Configure

From the context menu of a dynamic cluster we can additionally select Set Operation Mode. The operation mode of a dynamic cluster can be set to Manual, Supervised or Automatic. This is the same as going to Servers | Dynamic Clusters.


Specialty Servers tree

We find the On Demand Routers under the Specialty Servers tree. The ODRs' menu offers only two options: Chart and Configure. Configure leads us to this ODRs' configuration page...

Servers | On Demand Routers | odr_name


The application perspective

The application perspective shows we infomation about all applications installed in our environment - projected in an application tree. For example, we can learn which J2EE modules are part of an application, where they are running, and to which targets the application is mapped.

By hovering over the application name we also get information about transaction classes and service policies assigned to this application...

Clicking object names or icons also displays a menu that allows us to further manipulate this object.

We can use the application perspective to discern if applications or application editions are active or not. Active applications are represented by the icon and a tooltip is displayed when hovering over it. An inactive edition is represented by the icon and there is no tooltip information shown when we hover over the icon or the name.

Figure 6-6 Application perspective showing active and inactive editions


The service policy perspective

When selecting the service policy perspective, the tree is built starting with all service policies in the environment. When we expand a service policy, its transaction classes and which J2EE application modules belong to it are displayed. When going deeper into the tree we can also see on which application servers a module is running and if there is something wrong with a server.

Again, when hovering over names or icons, tooltip information is displayed and clicking an object name or icon displays a menu, just as in the other two perspectives.

For example, when we hover over a service policy name or icon we get a tooltip window which displays the most important properties of this service policy.

Figure 6-8 Service policy perspective with tooltip

The menu of service policies and transaction classes allow us to display the chart and to configure the service policy. The menu for the application module or server is identical to the appropriate objects in the node or application perspective.


Runtime charting

WebSphere XD provides a charting facility for nearly all objects. Selecting Chart from the menu that is displayed when clicking an object name or an object icon opens a new chart tab for that object on the right hand side of the panel.

For a chart, 20 datasets (50 in WebSphere XD V6.0.1) are collected in memory. By default, this happens every 15 seconds. We can change the collection interval, but it must be greater than or equal to 15 seconds.

There are several different datasets which can be displayed for one object or for many objects. Not all data is available for every object, for example we cannot select CPU utilization for dynamic clusters and similar combinations that do not make sense.


Data metrics

Concurrent Requests This metric measures the number of concurrent requests per the defined Data Set selection within the Data Name selection.

For example, selecting Node Group for the Data Scope, RedbookNodegroup1 as the Data Name, and Service Policy for the Data Set Type charts the average number of concurrent requests for the configured service policies coming into the node group called RedbookNodegroup1.

Avg. Throughput The average throughput metric is calculated in seconds based on the total workflow requests to the On Demand Router, as defined by the Data Scope, Data Name and Data Set.
Avg. Response Times (ms) The average response time metric is the time in milliseconds it takes for a work request to complete. This metric includes the request from inception, until the request is returned to the client, and is the equivalent of the service time metric plus the wait time in queue metric.
Percentile Response Time The percentage of requests of the service policy percentile goal that meet the specified response time.
Avg. Wait Times in queue (ms) This metric is the average time in milliseconds that a work request spends waiting to service.
Avg. Service Times (ms) The time in milliseconds to service a request for the On Demand Router. This metric indicates the time that the On Demand Router spends getting work to the node where it is completed.
Avg. Queue Length This metric is the average time, in milliseconds, for any work queue in the environment that is defined by the data scope, data set and data name.
Avg. Drop Rate The average drop rate is calculated based on the number of work requests that are not processed due to a full queue. Work requests that encounter a full queue are returned to the requestor with an error.
Jobs Requested The number of jobs which arrive at the execution environment (endpoint application) for processing.
Jobs Completed The number of jobs which run to completion at the execution environment.
Execution Time The total time in milliseconds time in milliseconds that jobs spend executing.
Maximum Concurrency The maximum concurrency level that is attained.
Jobs Queued The number of jobs that are queued at the scheduler.
Jobs Dispatched The number of jobs that are dispatched by the scheduler.
Jobs Failed The number of jobs that failed in the execution environment.
Jobs Error The number of dispatch errors that occurred for jobs.
Queue Time The time in milliseconds jobs spent in the queue.
Dispatch Time The total time in milliseconds jobs spent being dispatched.
Dispatch Error Time The time in milliseconds for jobs spent being dispatched when dispatch errors occurred.
Avg. Relative Performance The relative performance is how well the service policy is doing compared to the configured goal. This metric is available for the Service Policy Data Set Type only.
CPU Utilization The percentage of the resources that are being used and how much resource is available. CPU Utilization measures the node speed and process CPU. Available for the Application Server and Node Data Set Types.
Utilization The percentage of the resources that are being used and how much resource is available. Utilization measures the node speed and process CPU. Available for the Application Server, Cluster, and Dynamic Cluster Data Sets.
Free Memory (MB) This metric is only available for the Node Data Set Type.
Used Memory (MB) How much memory is used by the application server. This metric is only available for the Application Server Data Set Type.
Up Time (sec) Total uptime of the application server. This metric is also only available for the Application Server Data Set Type.
Total Requests Total number of requests for this application server. Only available for the Application Server Data Set Type.

There are two metrics available, when you select Partition as the Data Scope. Naturally, the values of these two metrics are related to the selected partition:

Avg. Response Times (ms) Total Transactions

While a chart is displayed you can add or remove new metrics by using the Add and Remove buttons and you can change the Chart Type. When adding new items, multiple selections in the Data Set and Data Metric fields are possible by holding down the Shift+Ctrl keys on your keyboard while selecting the items to be displayed.


Visualization data service

The visualization data service is used to store data collected by the visualization capabilities of WebSphere XD into comma separated log files. These files can be used to create charts with external programs. The simplest way to create an external visual view is to use spreadsheet programs such as Microsoft ® Excel®, Lotus 123, OpenOffice Calc, and so on.


Configuring the visualization data service

To enable the visualization data service select System administration | Visualization Data Service and check the Enable Log check box.

There are several property fields to configure the visualization data service to fit our needs:

  • When the Maximum File Size is reached, the files are rotated automatically.

  • The Maximum Number of Historical Files is kept and all other files are deleted by the visualization data service to prevent file systems filling up completely.

  • The directory where the current file and historical data are stored must be entered into the File Name field.

  • The Data log write interval specifies the number of seconds/minutes/hours/ days which the system waits to generate a new data point.

  • The Data transformer action is needed to define how data should be handled during the collection interval. There are two options, Average or Skip, to specify how to transform data when the interval reaches its maximum. The reason for this is that more data points might be provided than we want to use.

Average averages the existing data points, and Skip skips existing data points and uses only the ones we specify. As an example, imagine that the collecting time is 15 seconds and the data write interval is 30 seconds. In this case Average will write down the average value of two collected data sets while skip will store only every second collected data set and ignores the other ones.


Visualization data service files

The files stored by the data services are comma separated files and are normally located in an separate directory under the Deployment Manager´s log directory. The following five files are created and include different types of information:

  • TCModuleInstanceStatsCache.log
  • NodeStatsHistoricCache.log
  • TCModuleStatsCache.log
  • ServerStatsCache.log
  • BusinessGridStatsCache.log

As an example, the NodeStatsHistoricCache.log looks similar to...


The first row of each file holds the field names of each comma separated value in it. The first column of every file is the time stamp followed by the other data. We can see in our example that there are several rows for each time stamp representing all nodes. Missing values, like CPU usage for the Web servers which have no WebSphere XD components running on them, are represented by nothing, values that cannot delivered at that moment have a value of -1.


Collecting usable data

We can imagine that it is difficult to import that data as it is into, for example, a spreadsheet program without filtering. Therefore there are several ways to get better data to fit our needs.

In our example data was collected every 15 seconds which leads to a huge amount of datasets. When we are planning to make long time statistics we should increase this interval significantly by altering the visualization data service settings.

When our needs do not allow us to change these settings we can filter the data. This can be done by well known tools like UNIX commands or using the DataReaderWrapper class. This class is located in the install_root/lib/visualization.cacheservice.jar file and can be used as follows.

This command shows the usage page:

java DataReaderWrapper

This displays the ServerStatsCache.log files properties:

java DataReaderWrapper ServerStatsCache

To write only data from the ServerStatsCache file located in the log directory which represents RedbookCluster10_node1 on node node1 between the two timestamps to the data.out file:

java DataReaderWrapper ServerStatsCache log data.out 1113189469300 
1113189472500 name RedbookCluster10_node1 node node1

When using the DataReaderWrapper command the file construction changes a little bit: It splits up the time stamp to a name value pair, inserts human readable time and date, and moves all values representing the data also as name value pairs to a separate line...

java DataReaderWrapper NodeStatsHistoricCache. node1.log 1129583626157 1129585819016 nodeName node1 
generates the following output: 
Timestamp = 1129583626157, 05.10.17_17.13.46
nodeCPU = 12, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583626157, version = XD,
Timestamp = 1129583656147, 05.10.17_17.14.16
nodeCPU = 12, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583656147, version = XD,
Timestamp = 1129583671677, 05.10.17_17.14.31
nodeCPU = 12, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583671677, version = XD,
Timestamp = 1129583702280, 05.10.17_17.15.02
nodeCPU = 12, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583702280, version = XD,
Timestamp = 1129583717680, 05.10.17_17.15.17
nodeCPU = 11, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583717680, version = XD,
Timestamp = 1129583746827, 05.10.17_17.15.46
nodeCPU = 11, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583746827, version = XD,
Timestamp = 1129583762036, 05.10.17_17.16.02
nodeCPU = 13, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583762036, version = XD,
Timestamp = 1129583777490, 05.10.17_17.16.17
nodeCPU = 14, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583777490, version = XD,
Timestamp = 1129583807247, 05.10.17_17.16.47
nodeCPU = 15, nodeFreeMemory = -1, nodeName = node1, timeStamp = 1129583807247, version = XD,


Runtime map

WebSphere XD provides an innovative visualization technique called a runtime map. A runtime map is a method of displaying hierarchical data on different levels from the entire cell. The configuration information for each level shown in the map can be shown by placing the mouse cursor over the level.

The runtime map is a rectangle which is subdivided recursively into smaller rectangles, each of which represents the collection of nodes at some level in that tree of data. The significance of each rectangle's size and color are purpose-specific.

From a WebSphere XD perspective, the top-layer rectangle represents a cell. A cell is then subdivided into rectangles which represent node groups in that cell. Each node group rectangle is subdivided into rectangles representing dynamic clusters, and so on.

The size and color of rectangles correlate to the magnitude of a statistic, depending on which runtime map is being viewed. Color is typically used to represent health or goal attainment. For example, green nodes are healthy and available for work, while red nodes indicate an unhealthy state which requires attention. Size typically represents a quantity such as concurrent requests, or number of server instances.

By default, the runtime map displays the entire WebSphere XD topology. We can drill down to more granular scopes by clicking a non-root rectangle in the runtime map.

WebSphere XD's runtime map is particularly helpful to administrators of very large topologies, as it depicts large sets of data clearly. For instance, a set of 1000 applications is shown in a treemap of dynamic clusters with various sizes of rectangles.

The runtime map is intended as an assessment tool to provide an active perspective on the health of our entire environment. If we hover over a rectangle in the runtime map and right-click, a menu opens with several options for zooming, view source, and so on.

Figure 6-14 Runtime map of the full cell with expanded preferences

As we can see in this figure, we have selected to display the cell as our first layer (which is Layer 0), then the node groups, deployment targets, and the server instances as top layer (which is Layer 3). We can select to display other objects and their color codes from the Preferences drop-downs, such as application, J2EE modules, module instances, service policies, transaction classes.

Also, the runtime map provides a robust search facility which allows us to single out a subset of the data in an entire map, for example, all application server instances in a single node. For instance, we can search to highlight the top ten performing applications based on response time, or the dynamic clusters which have the lowest concurrent request values.


Search facility

Withe the search field, we can find specific instances of a variety of search options. After a parameter has been passed into the search, all the resulting entries are highlighted on the runtime map.

Search results are cleared with the next refresh of the map automatically. We can also clear them using the Clear Search Results button manually.

If results are not cleared between searches, then all results of consecutive searches are highlighted on the runtime map.

The following search options exist:

  • Basic search: The basic search allows us to search upon various criteria by selecting a type from the Type drop down list. Enter the name of the search element in the Name field, select a type, then click the search button to launch the search. The basic search allows us to search for various types of elements including:

    • Cell
    • Node Group
    • Deployment Target
    • Server Instance
    • J2EE Module
    • Application
    • Module Instance
    • Service Policy
    • Transaction Class
    • Partition

    As an example, we can enter Trade into the Name field and select Application from the Type menu. Clicking Search highlights the Trade application in the runtime map. Naturally, this requires that the result is displayed somewhere in the runtime map.

  • Lowest: The lowest search option allows us to select a metric and a search type. The metric option is either the Average (Avg.) Response Time or Concurrent Requests. The search type is also a selectable option of either the single lowest, the bottom 5, 10, or 25. This search returns the lowest performing Avg. Response Time or Concurrent Requests based on our selected scope.

    This search is well suited to learning what servers in the environment have the lowest utilization rate, or have the best performance.

  • Highest: The highest search option allows us to select a metric and a search type. The metric option is either the Avg. Response Time or Concurrent Requests. The search type is also a selectable option of either the single highest, the top 5, 10, or 25. This search will return the highest performing Avg. Response Time or Concurrent Requests based on our selected scope.

    This search is well suited to learning what servers in the environment have the highest utilization rate, or have the worst performance.

    Here is the result of a search for the highest average response time and the result of a subsequent search for the highest concurrent request. Both of them stay marked until cleared automatically or manually.

  • Advanced search: The advanced search option allows us to search on specific search criteria. We can enter single search criteria, such as Type=Dynamic Cluster, or we can enter multiple search entries, such as

    Avg. Response Time=10 Name=ABC


    Type=Service PolicyImportance=50

    When we are using the Advanced search option, multiple search parameters must be contained on separate lines. We can find instances of available search parameters by utilizing the hover feature in the map. Any data displayed in the hover feature of the runtime map can be used as advanced search parameters.

    Advanced search uses a literal string search. Spacing, spelling, capitalization, and punctuation are relevant and any errors cause the search to fail.


Runtime tasks

The runtime tasks give the administrator control over the autonomic features of WebSphere XD. Runtime tasks are generated by the health controller and the application placement controller. Depending on the supervised or automatic mode, health policies and dynamic clusters have two types of tasks that are composed:

  • Tasks which need approval by the administrator and where actions are taken after that.
  • Tasks, which are only displayed for administrator information, already finished.

To open the runtime task page in the Administrative Console select Runtime Operations | Task Management | Runtime Tasks.

The runtime tasks page presents we information about the tasks generated in the last days - except when the Deployment Manager is restarted. After a Deployment Manager restart, the runtime tasks page is empty.

In WebSphere XD V6.0.1 the runtime tasks are persisted to files on the Deployment Manager. If the Deployment Manager is restarted, the tasks' states are preserved and displayed when the Deployment Manager starts again.

We get information about the task, such as a short explanation, the state (for example, New, Expired, In progress, Closed), severity (such as Fatal), who has created and submitted the task and the time it was generated. By hovering over the task explanation value, we can see a tooltip for the full explanation.

Clicking the task explanation opens a new window showing the action plan for that task. The action plan includes the steps for the plan and the date and time when the plan expires.

Clicking the task ID brings up the general properties for that task including the action plan.

Figure 6-19 Runtime tasks: General properties

To act on a specific task select it and from the action list select either Accept, Deny or Close, then click the Submit button. We can also select the appropriate action on the General properties page and submit it from there. Accepting the task commits the previewed action plan. Closing the task means it is handled successfully by the task management service or manually closed. Denying the task places it in dead status if the task is not submitted again in the next batch of task submissions by the originating component. We can also select multiple tasks with the same actions. After we act on a task, the action list is unavailable for that task.


Event notification

When using the Administrative Console an administrator gets delivered a lot of useful information about the condition of the WebSphere XD cell. The event notification on the other hand is used to prevent the administrator from having to constantly working with the Administrative Console. When the notification E-mail is enabled. the administrator will be informed about all tasks generated by the health or the placement controller.

To set up the notification go to...

Runtime Operations | Task Management | Notifications

In the SMTP Host Name field, type the simple mail transfer protocol (SMTP) server to connect to when sending mail. Validation is not performed on the server host name.

In the Port number field, type the SMTP port number to connect to when sending mail. Valid port numbers are between 1 and 64767. Validation that the port is the correct SMTP port is not performed.

In the SMTP user ID field, type our user ID if our mail transport host requires authentication. Leave this field blank if our mail server does not require authentication.

In the SMTP password field, type our password if our mail transport host requires authentication. Leave this field blank if our mail server does not require authentication.

Select Enable notifications to use e-mail notifications. When notifications are enabled, and a task is generated, an e-mail notification is sent to each of the e-mail addresses specified.

In the E-mail address field, type the address for notification and click Add. Each e-mail address is validated for syntax. We can enter multiple addresses to this list. To take an existing address off the list, select the address and click Remove.


Usage examples

This section gives we some examples of how to use the visualization features in WebSphere XD to learn what is happening in our environment.

Identify which nodes belong to a node group.

This information can be found in the runtime topology. Verify the Node Group perspective is selected. Then expand the node group that we wish to look at, for example RedbookNodegroup1. Expanding the Nodes tree displays all nodes in the node group.

Identify which servers of a dynamic cluster are active and running the application.

This can also be found in the runtime topology. After selecting the Node Group perspective, expand the node group in which the dynamic cluster is configured to run. This approach assumes that we know to which node group the dynamic cluster belongs. If we do not know this, then select Dynamic Clusters in the Administrative Console first to display the dynamic clusters and their node group.

Expand the Nodes tree, then expand each individual node. All active application servers are now listed.

Identify in which application server an application is currently running.

This is again found in the runtime topology. There are a couple of options on how to display this information:

We can select the Application perspective to display all applications of our environment. We can then drill down until we eventually find the Running in tree under the J2EE Modules. Using this approach also gives we infomation about installed application editions and where they run in.

Another option is to use the Node Group perspective and drill down into individual nodes until the Running modules tree can be expanded. This is basically the succession of the steps listed for the previous example.

We can find information about system usage, such as CPU and memory utilization (per node in a node group) as follows:

Open the runtime topology and select the Node Group perspective. A chart is displayed in the right pane of the Administrative Console.

Now select the following settings for the chart:

Data Scope Cell
Data Name:
Data Set Type:
Data Set: all nodes that we are interested in
Data Metric: Utilization and Free Memory (MB) (Choose either or both.)

Click Add. The chart is updated with the appropriate information.

To learn information about our application runtime environment such as average response time for an application or the number of concurrent requests:

In the runtime topology, select the Application perspective. In the chart select the following:

Data Name The appropriate application
Data Set Type The appropriate data set type for the information we want to see. For example, Node or Dynamic Cluster.
Data Set The data set related to the selected data set type, for example, the node name or dynamic cluster name. We can also select more than one node and cluster.
Data Metric All metrics our are interested in, such as Concurrent Requests, Avg. Throughput, Maximum Concurrency, and so on.

Click Add to display the selected information in the chart.

If we need information about the On Demand Routers:

In the runtime topology select the Node Group perspective and the DefaultNodeGroup as the ODRs are part of this node group. The chart for the DefaultNodeGroup opens in the right pane. Select the following:

Data Set Type On Demand Router.
Data Set Select all ODR_names that we want.
Data Metric Select all metrics we are interested in, for example, Avg. Service Times (ms) or Avg. Throughput.

Click Add to display the selected metrics in the chart.

We can find the dynamic workload management weights of application servers using this method:

Use the runtime map and expand Preferences. Then select the following:

Layer 0 Type = Cell and Displayed Entity = your_cell_name.
Layer 1 Type = Server Instance and Displayed Entity = All or the server_name we want.

Click Apply. Hovering over the application server boxes displays a lot of infomation about each server, including the WLM Weight.

See how the service policies for our cell are doing:

Layer 0 Type = Cell
Layer 1 Type = Service Policy

Click Apply. Hovering over the service policy boxes displays infomation about each service policy, including the average response time, concurrent requests and its configuration.

Find application servers with the highest utilization rate or that are performing the best.

This can be done using the runtime map.

If we need to obtain the PIDs of our application servers:

In the runtime map, expand Preferences. Then select the following:

Layer 0 Type = Cell and Displayed Entity = your_cell_name.
Layer 1 Type = Server Instance and Displayed Entity = All or the application_server we want.

Click Apply. Hovering over the application server boxes displays a lot of infomation about each server, including the PID number if the server is active. If the server is not running, then a question mark (?) is displayed for the PID.




WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.


IBM is a trademark of the IBM Corporation in the United States, other countries, or both.