Share This:

@@Welcome to November’s ITSM Blog post.  In this Blog, we will be discussing Service Level Management Architecture and Troubleshooting Tips.

 

 

The BMC Service Level Management (BMC SLM) application provides a combined solution to bridge operations and services. BMC SLM provides a way to review, enforce, and report on the level of service provided to ensure that adequate levels of service are delivered in alignment with business needs at an acceptable cost.

 

The practice of Service Level Management (SLM) gives assurance to the service consumer that a provider will deliver a level of service that meets their needs. The purpose of the SLM practice is to set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored, and managed against these targets.

 

WHAT IS   Service Level Agreements (SLA's)

 

An SLA is defined as a documented agreement between a service provider and a customer that identifies both services required and the expected level of service. SLA's are used to measure the performance of services from the customer’s point of view, and it is important that they are agreed in the wider business context.

 

 

Primary Components of SLM

 

 

 

Configuration: User interface and workflow needed to configure service targets, agreements, contracts, templates, and other options.

 

Data sources and plug-ins: The data sources based on AR System use the native AR System interface to communicate with the main BMC SLM data repository

 

SLM Engine: A C++ binary that runs under the armonitor service and creates the filters to process service targets for AR System data sources

 

 

BMC SLM data model

 

The SLM data model comprises of the following main components:

 

  • Definition or configuration component forms – Stores information about the definition of service targets, agreements, contracts, milestones, and actions.

 

 

Real-time processing forms Used for calculations of measurements, compliance, and triggering milestones.

 

After the service targets and agreements are defined, the “processing” data model of SLM can be addressed. This includes service target processing, milestones, and compliance processing. The forms in this component are:

 

 

For real time trouble shooting problems related to SLM we would need more in-depth understanding of the flow and activities performed in the

Real time processing form.

 

 

The forms in this component are:

 

  • SLM:Measurement: This form tracks the measurement records and the performance of a service target, recording the latest service target status and the timestamps of the changes. Different types of information are stored on this form. All the information is related to service target processing.
  • SLM:MeasurementChild: This form tracks each change in state on the measurement for performance monitoring and availability service targets, such as from available to unavailable: Because each change in state is known, SLA compliance can, at any time, calculate the compliance performance of each service target for a review period to sum up their contribution to the SLA compliance percentage.
  • SLM:EventSchedule: This form tracks when events  should execute. Each record in this form has a timestamp indicating when a event should execute and for which instance of service target and application.
  • SLM:SLACompliance: This form tracks all the compliance calculations. A record is created in this form for each agreement, review period, and contract combination. As each review period completes, the record is marked as done and a new one is started.
  • SLM:ComplianceHistory: This form tracks compliance data for each service target contained in an agreement.

 

  • Application Administration Console forms – Used to store preferences and other administrative information.

Administrators use the forms in the BMC SLM administration console to configure items for the definition and processing modules.

The administrator can configure these items before setting up service targets and agreements, because they might not frequently change.

 

 

Form

Description

SLM:ConfigDataSource

UI and repository for all the data sources that work with SLM. Any AR System form that needs to work with BMC SLM will have an entry in this form. Other significant configuration settings related to the data sources are also stored in this form. In conjunction with the back end form SLM:Object, all forms working with the BMC SLM application needs to be registered with their own GUID.

SLM:ConfigGoalTypes

Repository for mapping of internal goal types to user-defined goal labels. Users see labels such as Incident Response Time, Incident Resolution time, but the application works off the goal types to be able to process the service target accordingly.

SLM:ConfigPreferences

Stores general application settings that apply across the product, including the service target identification prefix and location of log files.

SLM:ConfigReviewPeriods

Stores review periods that users select in the agreement definition to determine the time spans for compliance calculations.

SLM:ConfigSLAGroups

Stores the service target groups information for the service target group feature that is specific to request-based service targets.

SLM:ConfigSLAOwners

Stores “aliases” or names for groups of user IDs that can be used in alert actions. This enables emails and alerts to be sent to a group.

SLM:ConfigSLMComments

Stores pre-configured comments created by users to add to their measurement and compliance records. Comments typically include reasons for missing a compliance or goal.

 

 

 

Service Level Management BRIE Engine configuration

 

The main function of the Business Rule Interpretation Engine (BMC SLM Engine) is to interpret stored rules when they are created to construct the filters needed to implement these rules. The engine is written in C++ and runs continuously as a Microsoft Windows process or a UNIX daemon under armonitor. The command line to start the engine is in the armonitor.cfg and starts when AR System starts.

 

Along with the BMC SLM engine, the Application Dispatcher (arsvcdsp) engine acts as a "command controller" for all engines running under AR System. It receives commands queued in the Application Pending form and sends a signal to "wake up" the engine that needs to process each command, based on the category

BR-BRIE is the category of this command and Create-Rule is the command received by the engine. When a filter executes this command, an entry is created in the Application Pending form. This triggers the Application Dispatcher engine to evaluate this command and trigger the BMC SLM Engine to start processing.

 

The dispatcher is installed as part of AR System and works with any engine that runs under armonitor.

 

 

 

BRIE Service Configuration Check

 

This section shows the key point to check in order to ensure BRIE service will be up and running.

 

AR System Server Group Operation Ranking form

 

Open the AR System Server Group Operation Ranking form and search for Operation = Business Rules Engine, Admin server should be ranked 1 for this operation.

 

armonitor file

 

Log into Admin AR Server and open the armonitor file:

 

Windows: ARSystemServerInstallDir\Conf\armonitor.cfg

UNIX: etc/arsystem/serverName/armonitor.conf

 

Make sure you have the following lines defined and uncommented:

 

Windows: "C:\Program Files\BMC Software\BMCServiceLevelManagement\bin\slmbrsvc.exe"

UNIX: /opt/bmc/BMCServiceLevelManagement/bin/slmbrsvc.sh

ar file

 

Log into Admin AR Server and open the ar file:

 

Windows: ARSystemServerInstallDir\Conf\ar.cfg

UNIX: /opt/bmc/ARSystem/conf/ar.conf

 

Make sure you have the following lines defined and uncommented:

 

Windows:

  • Business-Rules-Engine-Suspended: F
  • Plugin-Path: C:\Program Files\BMC Software\BMCServiceLevelManagement\bin
  • Plugin: omfobjiefilapi.dll
  • Plugin: arfslasetup.dll

 

UNIX:

  • Business-Rules-Engine-Suspended: F
  • Plugin-Path: /opt/bmc/BMCServiceLevelManagement/bin
  • Plugin: libomfobjiefilapi.so
  • Plugin: libarfslasetup.so

 

NOTE: Business-Rules-Engine-Suspended parameter must be “F” in the admin server and “T” in all other servers in the group.

 

 

 

BRIE dll, so and application files

 

Log into Admin AR Server and open the bin folder:

 

Windows: BMC Software\BMCServiceLevelManagement\bin

UNIX: /opt/bmc/BMCServiceLevelManagement/bin/

 

Windows:

  • arfslasetup.dll
  • arfslasetupexe.exe
  • omfobjie.exe
  • omfobjiefilapi.dll
  • slmbrsvc.exe

 

UNIX:

  • libomfobjiefilapi.so
  • libarfslasetup.so
  • omfobjie
  • slmbrsvc
  • slmbrsvc.sh

BRIE Engine Running on a Private Queue

 

This section shows how to configure BRIE Engine to run on a private queue.

 

Advantages:

 

  • Performance improvement by running BRIE server on private queue instead of through Admin queue which is default for BRIE server; running on private queue will eliminate potential for resource contention with other applications and Admin activities using Admin queue.

 

  • Configuring BRIE server to run on private queue has been used successfully to resolve conditions causing crash of BRIE server with no other change necessary.

 

  • When BRIE server is running on private queue, it is very simple to isolate BRIE server activity in ARServer logs as the private queue will be identified as RPC Client.

 

Login to Admin server and go to Applications > AR System Administration > AR System Administration Console > System > General > Server Information > Ports and Queues tab

 

Add the following queue:

 

Log into Admin AR Server and open the ar file, add the following parameter and restart ar server

 

BR-RPC-Socket: 390625  

 

Common Issues in SLM

1) Service Target stay in 'Build in Progress"

What to do when a service target is getting stuck in “Build in Progress” status?

 

 

 

 

Step 1:

Review the following parameters in the AR configuration files:

 

  1. ar.cfg
    1. Server-directory: C:\Program Files\BMC Software\ARSystem\ARServer\Db
    2. Multiple-ARSystem-Servers: T
    3. Business-Rules-Engine-Suspended: F (Business-Rules-Engine-Suspended: T means service slmbrsvc is running but suspended, thus SVT cannot be built. That’s why you need to change it to F.)

 

Example:

 

 

  1. armonitor.cfg

 

  1. "C:\Program Files\BMC Software\BMCServiceLevelManagement\bin\slmbrsvc.exe" -d "C:\Program Files\BMC Software\ARSystem" -m
  2. "C:\Program Files\BMC Software\BMCServiceLevelManagement\bin\slmcollsvc.exe" -d "C:\Program Files\BMC Software\ARSystem" -m -c

 

Verify that both files slmbrsvc.exe and slmcollsvc.exe are on their corresponding paths.

 

Example:

 

@

 

 

Step 2:

Review the arerror.log and search for entry errors with BRIE or SLMCOLLSVC.

For example:

 

BRIE : Authentication failed (Remedy Application Service)  ARERR – 623

SLMCS : Authentication failed (Remedy Application Service)  ARERR – 623

BRIE : Cannot establish a network connection to the AR System server (clm-aus-t48u6y.bmc.com : RPC: Miscellaneous tli error - System error (Socket error - 10055))  ARERR – 90

Special users (Distributed Server,Remedy Application Service,MidTier Service) : Remedy Application Service password is wrong:

 

 

The Above errors in this example can be then rectified by resetting the Application Service Password.

 

https://communities.bmc.com/docs/DOC-98209

 

 

Verifying Issues related to Milestone Notification Not being Sent.

 

1) SLM Milestone note being sent.

 

There are duplicate SLM milestone notifications being sent.

 

2) Duplicate Milestone Notification being Sent

 

There are duplicate SLM milestone notifications being sent.

 

 

Thank you for going though Blog, feel free to provide you valuable input.