Skip navigation
Share:|

This video will show you how to create a custom table view in TrueSight Presentation Server 10.7 to determine where your synthetic events came from at a quick glance.

 

Share:|

If you were using the Application Management KM with older versions of TrueSight Synthetic Monitor, and you have upgraded to TrueSight Synthetic Monitor 10.7, then you will want to start using the new Synthetic Metric Rules. Below is a link to our documentation that explains how to move from Monitoring Policies to Synthetic Metric Rules:

https://docs.bmc.com/docs/display/tsavm107/Converting+from+Monitoring+Policies+to+Synthetic+Metric+Rules

 

And below here is a video that will demonstrate how to do the conversion:

Share:|

NOTE:  This is post contains a sample script.  BMC Support cannot assist in coding or debugging custom scripts

 

Project Attributes allows a user to edit parameters through an Execution Plan without editing the Silk Performer script directly.

 

A good case for this scenario would be a script that uses a username and password on a system where the password changes every few months.  If you have your script configured to use Project Attributes, then you can change the password via the Execution Plan instead of modifying the script.

 

Below is a step by step example of how we can do this:

 

1.  Open Silk Performer

2.  Choose Project - Project Attributes

3.  In the name field give the attribute a name (e.g password)

4.  In the Type field choose 'password' from the drop-down list.

5.  In the Value field enter a password you wish to use in your script.

Project Attributes.png

6.  You can now add code to your script that will pick up this attribute.  Below is some sample code:

---------------------------------------------------------

transactions

    TINIT            : begin;

    UserPassTest             : 1;

                            

var

  sUser   : string;

  sPass   : string;

 

// Transactions Section

dcltrans

 

  transaction TINIT

  begin

    AttributeGetString("ProjectAttributeUsername", sUser_variable);

    AttributeGetString("ProjectAttributePassword", sPass_variable);

  end TINIT;

 

  transaction UserPassTest

  var

  

  begin

   writeln(sUser_variable);

   writeln(spass_variable);

 

  end UserPassTest;

--------------------------------------------------------------

You can then use the variable "sPass_variable" anywhere that it is required in your script. Remember that if you use "sPass_variable" in a form (in the dclform section of the script) then it must be a global variable.

 

NOTE: Project attributes are case sensitive

 

After you have imported your script into TSPS, you can edit the Execution Plan and see your new editable settings.  If you followed the example above, then you should see something similar to the screen shot below:

Execution Plan.png

When the Execution Plan is deployed out to the TEA Agent, it will be passed the parameters from the above fields.  If you want to change the username or password that the Execution Plan is using, then you simply need to come back to the Execution Plan settings and change these values.

Share:|

You can use the SLA to change the status of your applications in the TSPS console and you can also use the AM KM with TrueSight Infrastructure Management (TSIM) to alert if an event threshold is breached n times in a series.

 

The SLA is used in TSPS to update the application status.  However, the SLA can only see the most recent 5 minute results window and cannot see anything that happened in the history of the application.  So if there is a failed result in the 5 minute period that could cause the SLA to trigger an event, then it will set application status to the appropriate value.

 

You may also have your AM KM set to trigger an event if an event threshold is breached n times in a series.  In this scenario, if an event is triggered, it will occur after n times. 

 

Please remember that the SLA and AM KM are 2 separate items and report on the data in different manners.

 

Below are a few use cases to demonstrate how the SLA and AM KM work (Please note that I am only discussing critical notifications in these use cases and not minor):

 

AM KM is configured to alert if there is a failure 2 times in a row

The Execution Plan runs once every 5 minutes and takes 1 minute to complete

The SLA has the following configuration:

     1.  Latency - 60 seconds

     2.  Accuracy Errors- 35%

     3. Execution Errors - 35%

     4.  Availability Errors - 35%

 

8:00 AM - Execution Plan starts

8:01 AM - Execution Plan stops with 1 Accuracy error

8:01 AM - AM KM sees 1 error.  No events are raised

8:05 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 1 Accuracy error.  This means there is 100% failure.  This is higher than the 35%.  The Application status is set to red.

 

8:05 AM - Execution Plan starts

8:06 AM - Execution Plan stops with 1 Accuracy error

8:06 AM - AM KM sees 1 error.  This is the second error in a row, so an event is raised and a notification is sent out as defined in the AM KM policy.

8:10 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 1 Accuracy error.  This means there is 100% failure.  This is higher than the 35%.  The Application status is set to red.

 

As you can see in the above scenario, the Application status was changed to critical during the first run of the Execution Plan, but the user was not alerted by the AM KM until the 2nd run of the Execution Plan.

 

Let’s look at a second use case where a user receives a notification from the AM KM, but the application status remains green:

 

AM KM is configured to alert if there is a failure 2 times in a row

The Execution Plan runs every  minute and takes 30 seconds to complete

The SLA has the following configuration:

     1.  Latency - 45 seconds

     2.  Accuracy Errors- 75%

     3. Execution Errors - 75 %

     4.  Availability Errors - 75%

 

8:00:00 AM - Execution Plan starts

8:00:30 AM - Execution Plan stops with 1 Accuracy error

8:00:30 AM - AM KM see's 1 error.  No events are raised

 

8:01:00 AM - Execution Plan starts

8:01:30 AM - Execution Plan runs with 1 Accuracy error

8:01:30 AM - AM KM see's 1 error.  This is the second error in a row, so an event is raised and a notification is sent out as defined in the AM KM policy.

 

8:02:00 AM - Execution Plan starts

8:02:30 AM - Execution Plan succeeds

8:02:30 AM - AM KM see's 0 errors.  No events are raised

 

8:03:00 AM - Execution Plan starts

8:03:30 AM - Execution Plan succeeds

8:03:30 AM - AM KM see's 0 errors.  No events are raised

 

8:04:00 AM - Execution Plan starts

8:04:30 AM - Execution Plan succeeds

8:04:30 AM - AM KM see's 0 errors.  No events are raised

 

8:05 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 2  Accuracy errors.  This means there is 40% failure.  This is lower  than the defined 75%.  The Application status remains green.

 

As you can see in the above scenario, the Application status was never changed because the combined results from the 5 minute results bucket did not meet the criteria for the SLA.  However, we did see 2 event threshold failures in a row, which means that the user was sent a notification from TSIM.

 

I hope this post helps understand how this situation happens and how to investigate.  See more blogs at TrueSight Support Blogs

 

Lisa Jahrsdoerfer

Filter Blog

By date:
By tag: