Overview

Skill Level: Any Skill Level

This recipe explains how to implement the event integration between CA APM SaaS on the cloud and Netcool on premise inside customer's IT infrastructure using Json payload.

Ingredients

For this recipe the following prerequisites are expected:

  • an existing and working Netcool environment on premise;
  • an existing CA APM SaaS instance running in the Cloud;
  • network flow (outbound to internet) from customer on premise network to the CA APM instance in the cloud;
  • an available machine to install a new probe on the Netcool environment;
  • a target machine on premise to install the CA APM agent with network flow to Netcool env.

Step-by-step

  1. Install the MessageBus Probe (in case it does not exists)

    The messagebus probe is used to receive JSON event messages from the CA APM solution.

    The probe needs to be installed and connected to the existing Netcool environment so received events can be used later on the current integrations in use, like ticketing, paging, emailing, automations and others.

    For more information on how to install the Netcool MessageBus Probe component, please refer to the documentation available on the following link.

    https://www.ibm.com/support/knowledgecenter/SSSHTQ/messbuspr-pdf.pdf

  2. Install CA APM infrastructure agent with proxy extension

    The event flow from CA APM SaaS to Netcool uses one or more CA APM infrastructure agents with the proxy extension enabled.

    Steps to install both agent and proxy are shown below:

    1. Download Infrastructure Agent from the APM SaaS
    2. Download proxy extension package from an official CA source (not GA yet)
    3. Copy both packages to the target machine
    4. Install the CA APM Agent (cd umagent; ./apmia-ca-installer.sh install)
    5. Copy tar.zip proxy extension to umagent/extensions/deploy agent directory
    6. Restart the agent (cd umagent; ./apmia-ca-installer.sh restart)
    7. Generate Notification Token at CA APM portal
    8. Generate Security Token at CA APM portal
    9. Edit umagent/extensions/atcNotificationProxy-99.99.dev-20171013.142021-9/config/atcnotificationproxy.properties
      1. Decrease refresh time to 5s for testing
      2. Update SaaS instance URL
      3. Update Omnibus URL
      4. Update Security Token
      5. Update Notification Token
    10. Edit umagent/extensions/atcNotificationProxy-99.99.dev-20171013.142021-9/config/message_template.json (an example is provided at section 4)
    11. Restart agent (cd umagent; ./apmia-ca-installer.sh restart)
    12. Simulate alert (see section 5 for more details)
      1. Go to Alerts
      2. Go to CPU Utilization (example)
      3. Under Notifications – Select the new notification
      4. Under Comparison settings – Decrease existing threshold to force an alarm
      5. Click Save Alert button
    13. Observe event flow into MessageBus probe logs

     

  3. Required configuration files on the Netcool side (MessageBus Probe)

    The Probe has 2 important files, the props and the rules files.

    For the props, the most important informations are shown below. Other config lines are also required, but they are generic to all probe (like AuthUserName and AuthPassword), so not described in here.

    # Probe Specific Properties
    MessagePayload : ‘json’
    TransportFile : ‘$OMNIHOME/java/conf/httpWebhookTransport.properties’
    TransportType : ‘HTTP’
    RulesFile : ‘/opt/IBM/GSMA/probe/MsgBus/rules/gsma_eif.rules’

    For the rules, the GSMA EIF rules file was used for this integration. Please refer to the GSMA documentation for more information.

  4. Required settings on the CA APM side (proxy extension)

    At step 10 – section 2 above – the JSON format is defined. That format (including attributes and values) is used on the message that is sent to netcool system.

    Example below can be used as a start point.

    ## template to be send to Omnibus. Placeholders might be used:
    ## ${APM.alertName} – name of the alert
    ## ${APM.statusText} – status (DANGER, CAUTION, OK)
    ## ${APM.occurrence} – Alert occurrence in GMT format
    ## ${APM.Vertex.type} – value of the attribute (type) of the alerted component
    ## ${APM.Vertex.name} – value of the attribute (name) of the alerted component
    ## ${APM.Vertex.<anyattribute>} – value of the attribute of the alerted component
    {
    “source”:”CA_APM”,
    “CustomerCode”:”IBM”,
    “appl_id”:”${APM.Vertex.ApplID}”,
    “msg”:”${APM.alertName} in ${APM.statusText} state”,
    “InstanceId”:”${APM.Vertex.instanceID}”,
    “InstanceValue”:”${APM.Vertex.instanceValue}”,
    “InstanceSituation”:”${APM.alertName}”,
    “origin”:”${APM.Vertex.hostname}”,
    “AlertGroup”:”${APM.Vertex.type}”,
    “hostname”:”${APM.Vertex.hostname}”,
    “Component”:”${APM.Vertex.name}”,
    “ComponentType”:”${APM.Vertex.type}”,
    “severity”:”${APM.statusText}”
    }

    At step 12 – section 2 above – the alert is triggered. Picture below shows how to enable proxy on the alert

    Used-Capture2

     

    For the proposed example, some new (custom) attributes were defined at CA APM portal, as shown below:

    Used-Capture7

  5. Alert testing

    See below the configuration screens and the messages received by messagebus probe during the alert testing.

    The alert condition

    CA APM alert configuration

    Used-Capture3

    Event received by MessageBus probe

    Used-Capture9

    The normal condition

    CA APM alert configuration

    Used-Capture6

    Event received by MessageBus probe

    Used-Capture8

  6. Overall Architecture

    Picture below shows the architecture related to this event integration.

    CA_APM_Netcool_diagram_v1

Join The Discussion