...
What is a cluster? | |
The main role of this feature is to allow users to have in one "indicator" the aggregation of other states. This indicator can provide a unique view for users |
...
playing different roles. Typical roles:
Let's take a simple example of a service delivery role for an ERP application. It mainly consists |
...
in the following IT components:
These IT components (Hosts in this example) will be the basis for the ERP service. With business rules, you can have an "indicator" representing the "aggregated |
...
" state for the ERP service! Shinken Enterprise already checks all of the IT components one by one including processing for root cause analysis from a host and service perspective. | |
Accessing Cluster Configuration | |
Clusters Configuration can be accessed by the Main Menu "Elements". | |
How to define Clusters |
A Cluster have the same notification logic than the hosts. This means you can have contacts that will receive only the relevant notifications based on their role.
Here is a configuration for |
...
a sample ERP rule:
| |||
Notification logic | |||
| A Cluster have the same notification logic than the hosts. This means you can have contacts that will receive only the relevant notifications based on their role. | |||
With "need at least X elements" clusters | |||
In some cases, you know that in a cluster of N elements, you need at least X of them to run OK. This is easily defined, you just need to use the "X of:" operator. Here is an example of the same ERP but with 3 http web servers, and you need at least 2 of them (to handle the load):
| |||
Possible values of X in X of: expressions | |||
...
The X of: |
...
expression may be configured different values depending on the needs. The supported expressions are described below:
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
| |||
...
...
The NOT rule | ||
...
You can define a not state rule. It can be useful for active/passive setups for example. You just need to add |
...
a ! |
...
before your element name. |
...
Example:
::
...
Aggregated state will be ok if database1 is |
...
Manage degraded status
...
For this you can use the extended operator *X,Y,Zof:*
X: number min of OK to get an overall OK state
Y: number min of WARNING to get an overall WARNING state
Z: number min of CRITICAL to get an overall CRITICAL state
State processing will be done the following order:
is Ok possible?
is critical possible?
is warning possible?
if none is possible, set OK.
Here are some example for business rules about 5 services A, B, C, D and E. Like 5,1,1of:A|B|C|D|E
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Warn Ok Ok Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
4of: --> Ok
5,1,1of: --> Warning
5,2,1of: --> Ok
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Warn Warn Ok Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
4of: --> Warning
3of: --> Ok
4,1,1of: --> Warning
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Crit Crit Ok Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
4of: --> Critical
3of: --> Ok
4,1,1of: --> Critical
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Warn Crit Ok Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
4of: --> Critical
4,1,1of: --> Critical
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Warn Warn Crit Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
2of: --> Ok
4,1,1of: --> Critical
...
===== ===== ===== ===== =====
**A***B***C***D***E**
Warn Crit Crit Ok Ok
===== ===== ===== ===== =====
Rules and overall states:
2of: --> Ok
2,4,4of: --> Ok
4,1,1of: --> Critical
4,1,2of: --> Critical
4,1,3of: --> Warning
Classic cases
...
Let's look at some classic setups, for MAX elements.
ON/OFF setup: MAXof: <=> MAX,MAX,MAXof:
Warning as soon as problem, and critical if all criticals: MAX,1,MAXof:
Worse state: MAX,1,1
Grouping expression expansion
...
UP and database2 DOWN on this example.
| |||
Grouping expression expansion | |||
Sometimes, you do not want to specify explicitly the hosts | |||
...
contained in a business rule, |
...
*. To do so, it is possible to use a *grouping expressionwhich is expanded into hosts or services. The supported expressions use the following syntax: |
...
The flag is a single character qualifying the expansion type. | |||
...
theses tables. Host flags |
...
| |||||||||
...
| |||||||
...
| ||||
...
Check flags
| ||||||||||
...
| |||
...
**Labels*are arbitrary names which may be set on any host or service using the ``label`` directive.
**Tags*are the template names inherited by hosts or services, generally coming from packs.
It is possible to combine both **host*and **service*expansion expression to build complex business rules.
.. note:: A business rule expression always has to be made of a host expression (selector if you prefer)
AND a service expression (still selector) separated by a coma when looking at service status.
If not so, there is no mean to distinguish a host status from a service status in the expression.
In servicegroup flag case, as you do not want to apply any filter on the host (you want ALL services which are member of the XXX service group, whichever host they are bound to),
you may use the host selector expression. The correct expression syntax should be:
``bp_rule!*,g:my-servicegroup``
The same rule applies to other service selectors (l, r, t, and so on).
Examples of combined expansion expression
-----------------------------------------
| ||||
...
Examples of combined expansion expression |
You want to build a business rule including all web servers composing the application frontend. |
...
which is equivalent to:
You may obviously combine expression expansion with standard expressions. | |||||
...
which is equivalent to:
| |||||

