A guest post from Tzvika Stein, one of our R&D engineers, on how easy it is to configure KPIs.
In this day and age, the amount of information may seem insurmountable. The size of IT infrastructures is constantly growing and frequently changing. The need to manage and monitor it all is greater than ever. HP BSM (Business Service Management) is the best solution available to overcome such a task.
In BSM, to see results, it all starts with the configuration. And when you get down to the screws and bolts, it all comes down to CIs and indicators. This article focuses on the KPI configuration. KPIs are required in order to get real-time information of availability, performance and other indications, and get a full and accurate picture of the state of your system via BSM Service Health. Configuring many KPIs, for many CIs, can be an exhausting and tedious task. But it doesn't have to be.
Let's take as an example John, a BSM administrator, who's been handed the task of configuring KPIs for a set of applications, servers and other CIs representing his business's IT infrastructure. Out-of-the-box, BSM comes with a large variety of KPIs and automatic rules, or assignments, to automatically configure KPIs for many common use cases. So far, these configurations fit John's monitoring needs perfectly.
Then, after a while, there were changes in the business's infrastructure that required some customizations. For instance, a certain application, which until now ran on a single server, now uses a cluster of servers to ensure redundancy for high availability. Due to these changes, some new KPIs needed to be added or existing KPIs needed different business rules. So, the first thing John did was to go to the Service Health Admin CI Indicators to perform some manual changes. Using bulk operations, he selects all the CIs that need a certain KPI to be added or modified, and in one shot adds or modifies the KPI for all the selected CIs. This is very good for tweaks and fine tunings, but for large dynamic system, an automatic configuration engine is still a necessity.
With time, John notices patterns and correlations between the topology of the CIs and the KPIs assigned to them. That's when John realizes that he can automate the KPI assignments he performed manually up till now.
So he decides to automate the procedure using the powerful KPI Enrichment Service (KES), which allows him to effortlessly configure a multitude of KPIs by means of Assignments. Assignments are configuration templates that define which CIs should be assigned what configuration. BSM has predefined assignments for many known topologies. Nonetheless, custom environments might need custom configurations, like in John's case. Luckily, these assignments are very simple to create in the BSM 9.
An assignment is comprised of a condition and of the KPI configurations that it generates. Creating assignment conditions is extremely easy. The condition defines which CIs are handled by a certain assignment. Moreover, conditions don't have to be mutually exclusive. A CI might fit multiple assignment conditions, and will be assigned the combined configuration defined by all the matching assignments put together. This allows John the flexibility to create simple or complex conditions to include or exclude CIs with ease, based on their types and properties.
The other part of an assignment is the KPI configurations. Defining the KPI is just as easy, using auto completion and Drag & Drop capabilities to simplify the use of reference properties as place holders in the KPI's configuration.
Once the assignments are in place, every new CI will be handled and automatically assigned the proper indicators. What about the CIs that existed prior to the assignment creation? No Problem. Simply select the relevant CI type and synchronize your entire model with a single click. You can re-sync your entire model, or part of it, at any time!
But the assignment engine is meant primarily for leaf-level CIs. What about CIs further up the chain? By default, every KPI assigned to a CI anywhere along the impact model is propagated with its default group rule as defined in the KPI definition in the repositories. But, if you need to change that in some cases, that's just as easy.
All you have to do is create a Propagation Rule to define the desired propagation behavior. A Propagation Rule is defined in a very similar way to that of the previously describe assignments. Though the condition is quite different, it is still very straightforward.
For further information refer to the BSM documentation on Using Service Health.
For HP Business Service Management software, Tzvika, Stein.