EUEM & BPPM Integration     (Best Practices)

Version 1
    Share:|

    How can EUEM interface with BPPM?

    BMC has many products that have the ability interface to each other with the idea to give a more complete solution to the customer.  The different offerings can monitor different operations/users and are able to send their data collected back to a central system which analyzes provides an appropriate response i.e.: a ticket generated and assigned to a resource that would address the current issue.

     

    The Analyzer part of the APM suite processes HTTP/HTTPS data and gives the end user experience of a particular web application.  If certain conditions are met, the Analyzer has the ability to send out alerts.  The two ways the Analyzer can send out alerts are email and SNMP traps.  This alerts generated from the HTTP/HTTPS data can be sent from AIM (Automated Incident Management) and Error Detection Rules.  System alerts (concerning system operation) can send out alerts via email and also has the ability to send syslog information as well (no traps).

     

    A complete setup using Patrol KM:

     

    all stages.png

     

     

    Although a good approach, the delays mentioned between stages can inhibit the reaction time to a given situation.

    If a situation

     

    Stage 1:  Collector to Analyzer

    There is a natural data delay from when the collector sees the traffic on the wire and when the Analyzer processes it.  This is due to tcp retransmits, out of order packets, network speed (and other factors) as well as some low level processing of the data (decryption, primitive custom fields).  It is important to note also that the Analyzer pulls data from the Collector.  It has to first process what it has and then retrieve more.  During high traffic periods, the processing time could be longer than lower traffic times.

     

    Stage 2: Analyzer to Patrol KM:

    The Patrol KM pulls data from the Analyzer utilizing the Analyzer api’s.  This polling frequency is at minimum 5 minutes.  Also, the Patrol KM is limited to the amount of watchpoint and metrics it can fetch.

     

    Stage 3:  Patrol to BPPM:

    Patrol feeds the data collected into BPPM (BMC Proactivenet Performance Management).  Again this is done on a set frequency.

     

    Stage 4:  BPPM to Remedy:

    BPPM takes time to process this data and according to configured rules has the ability to communicate with Remedy and create a ticket.

     

    Stage 5: Remedy to Support person:

    Remedy creates and notifies support person that a ticket has been assigned.  Remedy processing and email lag attribute to delay factor.

     

     

     

    Best Practices:

     

    It is possible to use all of the products listed on the previous page and improve response time for a particular situation.

     

    quicker stages.png

     

    As shown above, the first configuration still exists but it is also possible to configure the Analyzer to send a SNMP track directly to BPPM saving the 10 minutes between the stages.

     

    Since a ticket can be created in Remedy using via email, the Analyzer can also be configured to send out an email to Remedy and create a ticket saving 10+ minutes is delay.  This same email can directly be sent to a person or group (or both).  For situations that AIM can be used to decide if there is an incident with the HTTP/HTTPS traffic, you can configure a trap to be sent to BPPM and have it decide using it’s configuration when and how to assign a Remedy ticket to.  For situations in traffic that require as quick a response as possible, it is possible to configure the Analyzer for a customer error detection rule (or regular rule) to send out a trap or email immediately when a situation is seen in the traffic i.e.: host time >10 seconds for any given response.

     

    There are many different configurations that can be used.  It is also a best practice to plan for a discovery period to see which configuration works best for your environment.