Enable IBM Application Performance Management monitoring in IBM PureApplication System

Implementing and applying script packages to virtual system patterns


IBM® Application Performance Management (APM) is a new-generation monitoring solution for managing critical applications and the user experience in production. Until now, IBM PureApplication® System supported only the IBM Tivoli® Monitoring solution to monitor workloads. With the availability of APM, you have another option to monitor workloads. Unfortunately, you cannot find an APM pattern in PureApplication or use PureApplication to enable APM monitoring for other workload patterns. Thanks to the open architecture of PureApplication System, you can use a script package to do the integration on your own. This method is well known for its simplicity, flexibility, and low development and maintenance effort.

This tutorial explains how to enable APM monitoring in PureApplication patterns by using script packages. It also demonstrates how you can implement the script package and apply it to virtual system patterns.

A look at the APM agents

Similar to the servers and group of agents in IBM Tivoli Monitoring, the APM monitoring solution also consists of a server and group of agents:

  • An APM server
  • A group of APM agents for various system and software products, such as IBM WebSphere® Application Server, IBM HTTP Server®, IBM DB2®, and IBM Integration Bus

From the topology perspective, most APM agents are expected to be installed on the nodes where the target software products to be monitored are running. The APM server can run anywhere that the agents can reach it.

In PureApplication System, you must instrument the APM agents into the virtual system patterns to enable APM monitoring for middleware or database applications that are running in the patterns. The script package for PureApplication is one of the elemental components that you can use in virtual system pattern to customize pattern behavior. In this tutorial, we use the script packages to extend virtual system patterns to include installing and configuring APM agents for software in the patterns. You do not need to run the APM server as part of PureApplication System. For this tutorial, the APM server is already installed and running outside of PureApplication. To install and configure the APM server, see Installing your server.

The APM agents are categorized by the target software. The software usually has its own parameters for installing and configuring the agents. Most of the agents have similar installation and configuration steps. Because it's not possible to cover all of the agents in this tutorial, this tutorial uses only the APM agent for WebSphere Application Server as an example. This example demonstrates how to write the script package and use it to install and configure the APM agent for WebSphere Application Server in the WebSphere Application Server pattern.

The code that is described in this tutorial is only for the Linux platform. Therefore, make any corresponding changes before you apply the code to other platforms. To change the code that is described in this tutorial and use the corresponding commands according to the APM agent type, see Installing your agents.

Implement a script package

A script package usually contains a metadata file (named cbscript.json), a main executable file, and the associated supporting artifacts. In our example, we use the script to install and configure the APM agent for WebSphere Application Server for WAS servers in WebSphere Application Server patterns.

Create the metadata file

The cbscript.json file is the specification of the script package. It points to the location of the main script, which is the starting point of execution. This file also contains all of the configuration parameters that are used by the script. The following listing shows the main content of the cbscript.json file that is used in the script package.

  "command" : "python /tmp/apm_was/",                                                                
  "commandargs": "${AGENT_URI} ${AGENT_HOME} ${WAS_HOME} ${WAS_PROFILE_NAME} ${WAS_CELL_NAME}                                
                  ${WAS_NODE_NAME} ${WAS_SERVERS_PARM}",                                                                
  "execmode": 2,                                                                                                
  "filename": "",                                                                                                
  "location": "/tmp/apm_was",                                                                                                
  "name": "APM WAS agent",                                                                                                
  "ostype": "linux/unix",                                                                                                
  "timeout": 3600000,                                                                                                
  "type": "APPLICATION",                                                                                                
  "version": "1.0.0"                                                                                                      
  "keys": [                                                                                                                           
        "required": true,                                                                                  
        "scriptkey": "AGENT_URI",                                                                         
        "scriptdefaultvalue": "e.g.",   
        "label": "Configured Agent Image Location"                                                        
        … …                                                                                                                                 

Among the attributes, the "command" attribute indicates that the entry script is a Python script named "". The script runs to install and configure the APM agent for WebSphere Application Server. We describe the implementation of this script in the following sections. The value 2 of the "execmode" attribute indicates that the script will execute only after users manually trigger it.

The script requires a group of arguments, which are described in "commandargs", when it is run. The arguments, which are shown in the following table, are exposed on a user interface (UI) when the script package is imported or executed and allows users to enter the values.

"scriptkey" "label" "description"
AGENT_URI Configured Agent Image Location Specify the download URL of the configured APM agent image
AGENT_HOME APM Agent Installation Directory Specify where the APM agent will be installed
WAS_HOME WAS Installation Directory Provide the location where WebSphere Application Server is installed on this virtual machine (VM)
WAS_PROFILE_NAME WAS Profile Name Provide the profile name of the WebSphere Application Server
WAS_CELL_NAME WAS Cell Name Provide the cell name of the WebSphere Application Server
AS_NODE_NAME WAS Node Name Provide the node name of the WebSphere Application Server on this VM
WAS_SERVERS_PARM WAS Servers For the WebSphere Application Server, provide the server names, the system users to launch the WebSphere Application Server processes, and the option to auto-restart the WAS servers

The APM agent is installed from the image that you configured on the APM server side. The configured image contains the address of the APM server, the communication protocol, and the token that were used between, for example, the APM agent and the APM server. The installer refers to the image when it sets up the connection between the agent and server. The users of the script package must provide the configured image and make it available on an HTTP server for downloading. The "AGENT_URI" key obtains the configured image location.

Configuring the WebSphere Application Server agent requires information about the target WAS servers, such as their profile name, cell name, node name, and server name. The script completes the configuration by using other information, such as whether to restart WAS servers automatically with proper system users. The "WAS_SERVERS_PARM" key includes all the information for the WAS servers. To make them identifiable in one string, the value must use this schema:

If more than one server is involved, multiple values are separated by a comma, as in the following example:

Implement the script

The "" script is written in Python. The following diagram illustrates the logic in the script.

Installation and configuration flow of the APM agent for WebSphere Application Server
Installation and configuration flow of the APM agent for WebSphere Application Server

Check and clean the running agent

The WebSphere Application Server environment to install the APM agent must be clean enough to ensure that the installed agent works as expected. An agent installation can fail, or the APM agent for WebSphere Application Server can fail to collect metrics for the WebSphere Application Server, for the following reasons:

  • An IBM Tivoli Composite Application Manager (ITCAM) for WebSphere Application Server agent or another APM agent for WebSphere Application Server is running on the current WAS node.
  • The WAS servers on the current node were previously configured for the data collector for either ITCAM for WebSphere Application Server or another APM for WebSphere Application Server.

Therefore, the "" script starts by checking and cleaning the old monitoring agent and data collector configuration. Both the ITCAM agent for WebSphere Application Server and the APM agent for WebSphere Application Server exclusively include "kynagent" in their system process names. Therefore, the script uses the following command to detect the old monitoring agents by matching the process name.

cmd = 'ps –ef | grep kynagent | grep –v grep'                                                             
(rc,out,err) = maestro.log_call([cmd], shell=True)                                                            
if out > 0 :                                                                                              
    print 'The agent is still running'                                                                    

After the old monitoring agent is detected, the script also handles uninstalling the old agent. However, the script always attempts to unconfigure the data collector before the script uninstalls it because the data collector is usually configured with the old agent installed. Unconfiguring the data collector in silent mode requires a configuration file with the following properties.

[DEFAULT SECTION]                                                                                 =                                                                                     
tema.appserver = True                                                                                     
temaconnect = True                                                                                        
tema.port = 63335                                                                                         
tema.jmxport = 63355                                                                                      
soa.enable = False                                                                                        
de.enable = False                                                                                         
ms.connect = False                                                                                        
ttapi.enable = False                                                                                      
tpv.enable = False                                                                                           
was.appserver.home = e.g. /opt/IBM/WebSphere/AppServer/ # Obtained from WAS_HOME in script package                           = e.g. DefaultAppSrv01       # Obtained from WAS_PROFILE_NAME in script package                       = e.g. CloudBurstCell           # Obtained from WAS_CELL_NAME in script package                       = e.g. CloudBurstNode           # Obtained from WAS_NODE_NAME in script package                               
was.client.props = True                                                                                   
was.backup.configuration = False                                                                          
[SERVER]                                                                                          = e.g. server1                # Parsed from WAS_SERVERS_PARM                   
tema.serveralias = e.g. server1

Among the properties, the was.appserver.home,,,, and values are mutable based on actual WAS servers. You can get the values from the corresponding input of the script package keys. Other properties can use the default values, which are shown in the previous property configuration file. The following code shows how to unconfigure the data collector and uninstall the APM agent for WebSphere Application Server in the script.

#parse WAS_SERVERS_PARM                                                                                   
servers = []                                                                                              
server_tokens = was_servers_param.split(',')                                                              
for server_str in server_tokens:                                                                                
    tokens = server_str.split(':')                                                                          
    name = tokens[0]                                                                                      
    run_as = 'root'                                                                                       
    if len(tokens) > 1 and tokens[1] and tokens[1].strip():                                               
        run_as = tokens[1]                                                                                
    auto_restart = 'true'                                                                                 
    if len(tokens) >  2 and tokens[2] and tokens[2].strip():                                              
        auto_restart = tokens[2]                                                                          
    servers.append({'name':name, 'run_as':run_as, 'auto_restart':auto_restart})                           
#Create configuration file                                                                                                                              
p = ConfigParser.ConfigParser()                                                                                    
default_sect ion = 'DEFAULT SECTION'                                                                                    
p.set(default_section, '','')                                                                                    
… …                                                                                                                      
p.set(default_section, 'was.appserver.home',was_home)                                                                                    
p.set(default_section, '',was_profile_name)                                          
p.set(default_section, '',was_cell_name)                                           
p.set(default_section, '',was_node_name)                                                                                   
server_section = 'SERVER'                                                                                    
for s in servers :                                                                                        
    p.set(server_section, '', s['name'])                                          
    p.set(server_section, 'tema.serveralias', s['name'])                                                                                    
with open(config_file, 'w') as f :                                                                                    
#unconfig data collector , i.e. -p config.cfg                                                 
cmd = '%s/ -p %s'%(os.path.join(dchome, 'bin'), config_file)                                         
maestro.log_call([cmd], shell=True)                                                                                                                              
#uninstall the agent, i.e. force uninstall                                                                            
cmd = '%s/ force uninstall_all'%os.path.join(agent_home, 'bin')                                          
maestro.log_call([cmd], shell=True)

The script uses the script to uninstall the agent. You can also use the following APM command to uninstall agent: uninstall

This command removes only the files for the WebSphere Application Server agent. It leaves the APM agent framework files and the other APM agent that is installed in the directory. Because only the WebSphere Application Server agent is installed in the installation directory, you can clean the whole directory by using the script.

The script uninstalls only the APM agent, not the ITCAM agent, because the ITCAM agent has a different set of installation and uninstallation commands and its own lifecycle. The user can uninstall the ITCAM agent manually.

The maestro.log_call method that is used in the code is implemented and provided by the PureApplication script package framework. It is used for starting a local command or running a local script in a safe manner.

Install the agent

To install the agent from the agent image, you must provide the type of agent to install and the installation directory, and also accept the license in an installation configuration file, as shown in the following example.

License_Agreement="I agree to use the software only in accordance with the installed license."            

You can find the installation configuration file template named APM_silent_install.txt under the root directory that is extracted from the image. Instead of using the template, this script creates a new configuration file for installing the APM agent.

#unzip configured image                                                                                   
temp_dir = tem pfile.mkdtemp()                                                                              
image_file =, mode='r:')                                                                
# create APM_silent_install.txt                                                                           
p = ConfigParser.ConfigParser()                                                                           
#set properties                                                                                           
… …                                                                                                        
with open('%s/APM_silent_install.txt'%temp_dir, 'w') as f :                                                
# install agent e.g. -p  APM_silent_install.txt                                         
cmd = '%s/APM_Agent_Install_8.1.3/ -p %s/APM_silent_install.txt'%(temp_dir, temp_dir)  
maestro.log_call([cmd], shell=True)

Configure the data collector for the WAS servers

When you configure the data collector, the command changes the server.xml file of WebSphere Application Server to add an agent JAR file to the WebSphere Application Server process. This process requires the configuration process to have write permission to the server.xml file. Otherwise, the configuration process will fail. The root user can be used to run the script because this user usually has sufficient access to all system files as shown in the following example.

#config data collector , i.e. -p config.cfg                                                          
cmd = "su -c root '%s/ -p %s'"%(os.path.join(dchome, 'bin'), config_file)                                        
maestro.log_call([cmd], shell=True)

However, in respect of the customized WebSphere Application Server patterns where file access is controlled strictly, replace the root user with other system users who have write access to the server.xml file.

Restart the WAS servers

For the data collector to work, you must restart the WAS server. To keep the privilege of the WebSphere Application Server process, the script uses the system user who started the WAS servers the first time. The script package property WAS_SERVERS_PARM identifies the user as the value of the "run_as" parameter.

Some WebSphere Application Server patterns include more than one WAS server on one node. For example, the WAS servers in the Business Process Manager (BPM) Pattern include Messaging, Support, AppTarget, and WebApp. If those servers have dependencies, consider the order in which you restart the servers. The script honors the order that the server appears in the WAS server string value of the script package, for example: server1:root,server2:root. The script will stop and start server1 and server2 in order as shown in the following example.

for server in servers :                                                                                   
    if server['auto_restart'].lower() == 'true' :                                                         
        cmd = 'su %s -c "%s/bin/ %s"'%(server['run_as'],was_home, server['name'])            
        maestro.log_call([cmd], shell=True)                                                                   
        cmd = 'su -c "%s/bin/ %s"'%(server['run_as'], was_home, server['name'])             
        maestro.log_call([cmd], shell=True)

Restart the agent

Restart the APM agent as follows for the data collector to start working.

cmd= '%s/bin/ stop'%agent_home                                                                  
maestro.log_call([cmd], shell=True)                                                                             
cmd= '%s/bin/ start'%agent_home                                                               
maestro.log_call([cmd], shell=True)

Modify the permission of the data collector directory

After you restart the WAS servers, the servers attempt to create the runtime directory under the dchome directory and then write the configuration files to the new directory. Therefore, the runtime directory must have sufficient privilege for the run_as user of the WebSphere Application Server process to write and read. The script gives all users full read/write permission from the runtime directory in case multiple WAS servers are configured with different run_as users.

The script goes into sleep mode for a while. Then, it changes directory permission to allow the WAS servers to complete restarting and creating the runtime directory.

runtime = os.path.join(agent_home,'yndchome', '', 'runtime')                                     
print 'Change the privilege to %s'%runtime                                                                
retry = 5                                                                                                 
while not os.path.exists(runtime) and retry > 0:                                                           
    retry –-                                                                                              
if os.path.exists(runtime) :                                                                              
    os.chmod(runtime, 0777)

Make the script package

Next, you create a script package to wrap up the metadata and script files, which is required by PureApplication. To create the script package, compress the script and the Python script in the .zip or .tgz format. Ensure that the script is at the top level in the package structure. Also, name the compressed file with the value that is defined for "filename", that is, in the script.

Alternatively, you can also use the PureApplication Plug-in Development Kit to help make the script package. To learn more, see Creating an IBM Workload Script Package Project.

Use the script package

Before you use the script package, you must configure the original APM agent image by using the APM server script. (To configure the image, see Configuring the installation images for instructions.) Then, upload the configured image to an HTTP server that is reachable by the target WAS node that you want to run the script package on.

PureApplication provides a set of entitled script packages. However, you must import the script package, as the customer script package, into PureApplication before you use it. You also must explicitly add the script package to WebSphere Application Server patterns so that it can be executed when the patterns are deployed and running. The following sections explain how to import and use the script package in WebSphere Application Server pattern.

Use the script package in patterns

To import the new script package in PureApplication System, from the PureApplication web console, select Catalog → Script Package. Then, to upload the script package file, click Create New. You can always upload a new script package file later. You can use this function to upgrade the scripts with new changes after you create the script package.

After you successfully upload the script package, all the properties that are defined in the cbscript.json file are displayed in the "Environment" section of the script package detail panel. The properties are with the default values at the beginning. You can reset these values by overriding the properties in the "Add variable" section. You can also reset the values later when you add the script package into patterns or even at run time when you execute the script package. The reset times have the following differences:

  • The values in the Script Package panel are applied to all the patterns and instances that have the script package.
  • The values when adding the script package to a pattern are applied to all instances of the pattern.
  • The values when executing the script package are applied only to the current instance of the pattern.

For "Execute", select when I initiate it (as shown in the following figure) so that the script's execution is triggered manually at run time. This way, you can run the script only after the WAS servers are created and available to access.

Uploading the script package to PureApplication
Uploading the script package to PureApplication

After you successfully install the script package, you can use it in the WebSphere Application Server patterns. The script supports both the WebSphere Application Server Standalone and Network Deployment topologies, which are covered by most WebSphere Application Server patterns in PureApplication System. To add the script to a WebSphere Application Server pattern:

  1. Open the pattern in the IBM Pattern Builder, and click Scripts on the left side.
  2. From the list that is shown in the Script panel, locate the script package.
  3. Drag the script package to the nodes where the WAS servers are hosted (see the following figure).
Adding the script package to the WebSphere Application Server pattern
Adding the script package to the WebSphere Application Server pattern

The properties of the script packages are visible in the right pane when the script package is activated on the node. You might need to reset such properties as WAS_Profile_Name, WAS_Cell_Name, WAS_Node_Name, and WAS_Servers_PARM to make them consistent with the corresponding properties from the WebSphere Application Server software component in the pattern. Be careful with the dynamically created servers, and the name of the node and cell that are appended with instance ID, host name, or random digit, because all the names aren't settled until run time. In this case, you need to reset the script package properties that are related to WebSphere Application Server when the script package is executed.

Execute the script package

After you deploy WebSphere Application Server and see it in the RUNNING state, locate the script package in the WebSphere Application Server virtual machine section from the VM perspective on the Virtual System Instance page. To enter the property values of the script package, click the Execute link, and give each property a proper value.

Entering the property values of the script package
Entering the property values of the script package

To check whether the script package ran successfully, download the remote_std_out.log file. If the script package failed, download the remote_std_err.log file to debug and troubleshoot it.

Check the WebSphere Application Server metrics on the APM portal

After you successfully run the script package, log in to the APM portal at:
https://<APM server host name>:9443

To locate the target WAS servers and the metrics that are collected from the WAS servers:

  1. Select Performance → Application Dashboard.
  2. On the Application Dashboard, expand All My Applications, and click My Components.
  3. Under Groups, select WebSphere Application Server.

To view more details of the metrics, click any of the charts on the Status Overview page.

Application Dashboard in the APM portal
Application Dashboard in the APM portal

Reconfigure and upgrade the APM agent

You must reconfigure or even reinstall the APM agent in the following cases:

  • The APM server was reconfigured or reinstalled with a different IP address or communication protocol, for example. Therefore, you must reconfigure the agent installation image with the new APM server and then reinstall the APM agent.
  • To upgrade to newer versions, you must reconfigure and reinstall the APM agent.
  • When some of the new WAS servers were created and added to the WAS cluster, you must reconfigure the data collector for the new WAS servers.

The implementation of the script package is designed for idempotent execution. That means that, every time it runs, it starts by uninstalling the agent and ends by installing the APM agent from scratch. Use the newly configured image or reset the properties that are related to WebSphere Application Server to run the script package again when you want to reconfigure or upgrade the APM agent.

Execute the script package in batch mode

In some cases, executing the script package in batch mode helps increase the automation of installing and configuring the APM agent across more than one WAS nodes. This automation occurs particularly on multiple WAS nodes of a WAS cluster in one WebSphere Application Server pattern, or across multiple WAS clusters in one WebSphere Application Server pattern or multiple WebSphere Application Server patterns. PureApplication System provides the REST API of the executing script package on the designated VM and the ancillary APIs of locating the VM and the specific script packages. By compiling these APIs, you can make a script to execute the script package in batch mode.

The following table defines the API of the executing script.

Method POST
Resource /resources/virtualSystemInstances/<deploymentid>/virtualMachines/<vmid>/virtualMachineScripts/<scriptid>
Request body A JSON object that contains the properties that are required in the script package.

The following parameters are included in the path:

  • deploymentid. You use this parameter to specify the deployment ID of the pattern instance. The ID is in the details pane of the deployment on PureApplication instance page, as shown in the following figure. Finding the deploymentid of the pattern instance
    Finding the deploymentid of the pattern instance
  • vmid. You use this parameter to specify the ID of a VM where the script package is installed. You cannot find it in the UI, but you can obtain it by calling the following REST API of the query that is used to get the deployment's VMs.
    Method GET
    Resource /resources/virtualSystemInstances/<deploymentid>/virtualMachines/
    Response A JSON object contains the virtual machine resource list in the deployment.
          "uuid": "f3b10e17-4c09-48e3-895e-a08792586be2",
          "displayname": "OS_Node.11469727804568",
          "id": 234,
          … …

    The API response contains a list of VMs and their attributes, including "id". You can find the target VM by matching the "displayname" among the VMs in the list. You can find the value of "displayname" in the "Virtual machine perspective" section in the PureApplication instance console, as shown in the following figure. The value of "id" in the VM resource with the matched "displayname" will be used for "vmid" in the request.

    Finding the displayname of the VM
    Finding the displayname of the VM
  • Scriptid. Use this parameter to specify the ID of the script package that is used in the deployment. When the pattern with the script package is deployed, each script package will be assigned a unique ID. Like vmid, you cannot find the scriptid in the UI, but you can obtain it by calling the following REST API.
    Method GET
    Resource /resources/virtualSystemInstances/<deploymentid>/virtualMachines/<vmid>/virtualMachineScripts
    Response A JSON object contains the script list on the virtual machine in the deployment.
           "name": "Sample Install APM WAS Agent",
           "scriptid": "94",
           … …

    The response contains a list of script packages. Similar to how you look for the vmid, the script "name" will help you find the "scriptid" from the list.

To execute the script packages on multiple VMs, a file (see the following example) is used to feed the identifiers of the target deployments and VMs. This file also provides the values of the input parameters for WebSphere Application Server on each VM.

    "d-7ac772b7-f5c3-4fff-8eac-dd1d53732591": {                                                               
        "WASStandalone.11469630057527": {                                                                                    
            "AGENT_URI": "",                     
            "AGENT_HOME": "/opt/IBM/apmwas",                                                                                    
            "WAS_HOME": "/opt/IBM/WebSphere/AppServer",                                                               
            "WAS_PROFILE_NAME": "DefaultAppSrv01",                                                               
            "WAS_CELL_NAME": "CloudBurstCell",                                                               
            "WAS_NODE_NAME": "CloudBurstNode",                                                               
            "WAS_SERVERS_PARM": "server1:admin",                                                               
            "adminusername": "",                                                                                    
            "adminpassword": ""                                                                                    
        " WASStandalone.11469630057528": {                                                                                    
            "AGENT_URI": "",                     
             … …                                                                                                          
    "d-7ac772b7-f5c3-4fff-8eac-dd1d5378974": {                                                                                    
        "WASStandalone.11469630057527": {                                                                                    
            "AGENT_URI": "",                     
             … …                                                                                                          

A Python script (shown in the following example) is created to iteratively start the REST APIs to get the "vmid" and "scriptid", and execute the script packages on the target VMs across different deployments.

def local_call(*popenargs, **kwargs):                                                                        
    proc = subprocess.Popen(*popenargs, **kwargs)                                                            
    out = proc.communicate()[0]                                                                             
    return out                                                                                             
for deployment, instances in deployments :                                                                          
    for instance, param in instances :                                                                        
    #1. gen instance vm id                                                                                                
    cmd = 'curl -u "%s:%s" -X GET \                                                                                                
               –-url "https://%s/resources/virtualSystemInstances/%s/virtualMachines/"'\                        
                   %(user, password, floatip, deployment)                                                  
    out = local_call([cmd], shell=True)                                                                         
    for o in out :                                                                                                      
        if o['displayname'] == instance :								                        
           vmid = o['id']                                                                                                
        #2. get script package id                                                                                                
        cmd = 'curl -u "%s:%s" -X GET \                                                                        
                   --url "https://%s/resources/virtualSystemInstances/%s	                                                               
                          %(user, password, floatip, deployment, vmid)                                      
        out1 = local_call([cmd], shell=True)                                                                      
        for o1 in out1 :	                                                                                      
           if o1['name'] == 'Sample Instance APM WAS Agent' :                                                  
                spid = o1['id']                                                                                                   
        #3. trigger executing the script packages                                                                                                
        cmd = 'curl -u "%s:%s" -X POST -d %s \                                                                        
                  --url "https://%s/resources/virtualSystemInstances/%s\                                                
                     %(sys_user, sys_password, json.dumps(param), deployment, vmid, spid)                               
        local_call([cmd], shell=True)

The Python script can run anywhere that it can reach PureApplication System. It has no limit to the location of the target deployments and VMs that can spread across cloud groups. The administrative user name (sys_user) and password (sys_password) of logging the PureApplication console are required to authenticate the calls to REST APIs.

Instead of using maestro.log_call, the script implements its own local_call method to start the curl command. The reason is that it is expected to run stand-alone, not on the PureApplication script package framework.


By using the script package to enable the IBM Application Performance Management agents in virtual system patterns for IBM PureApplication System, you equip the workloads with the latest APM monitoring capabilities and user experience. This tutorial explained how to implement and apply the script package to install and configure the APM agent for WebSphere Application Server in WebSphere Application Server virtual system patterns. By replacing some commands or tailoring the script flow, you can reuse the script package to install and configure other APM agents for various middleware or databases, such as an OS agent, HTTP server agent, or DB2 agent.


We thank Dave Fresquez and Ling Lan for their expertise in reviewing this tutorial.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Middleware, DevOps
ArticleTitle=Enable IBM Application Performance Management monitoring in IBM PureApplication System