4.2.7 Common exclusion-conditions
Common exclusion-conditions form part of an event acquisition filter and consist of a group of conditions for filtering out JP1 events or excluding JP1 events from automated-action execution. You can apply or disable each group. In maintenance mode, for example, you can set a common exclusion-condition group to temporarily prevent JP1 events from being collected or exclude them from automated-action execution when the events are issued by the host you are working on, without having to change the pass conditions or exclusion-conditions in the event acquisition filter. If you have defined multiple event acquisition filters, and switch among them as required, the common exclusion-conditions you set apply to whichever filter is in force.
Of the conditions defined in an event acquisition filter, common exclusion-conditions take precedence over exclusion-conditions, which take precedence over pass conditions. The following figure shows the relationships among the common exclusion-conditions, exclusion-conditions, and pass conditions in event acquisition filters.
|
There are two types of operation modes for common exclusion-conditions: basic mode and extended mode. You can execute the jcochcefmode command to switch between basic mode and extended mode. In extended mode, you can filter events by Registered time, Arrived time, Start time, End time, Event source host name, and other items. You can also filter the event conditions by specifying the date and time, or execute the jcochfilter command to switch whether to enable or disable each group of conditions. However, for regular expressions, you can use only the extended regular expressions. After you switch to extended mode, you can return to basic mode. For details about basic mode and extended mode, see 4.2.7(1) Difference between basic mode and extended mode of common exclusion-conditions. This manual describes information common to basic mode and extended mode if not otherwise specified.
For details about how to define common exclusion-conditions and how to switch the operation modes, see 5.2.4(3) Setting common exclusion-conditions in the JP1/Integrated Management 3 - Manager Configuration Guide.
You can specify an appropriate target on a common exclusion-condition, depending on whether to prevent JP1 events from being collected or exclude JP1 events from automated-action execution. For details, see 4.2.7(2) Exclusion target of a common exclusion-condition.
You can also use additional common exclusion-conditions. You can define additional common exclusion-conditions by using monitored JP1 events while the system is operating. You can use additional common exclusion-conditions only when common exclusion-conditions are in extended mode. For details about additional common exclusion-conditions, see 4.2.7(3) Additional common exclusion-conditions.
The following shows the difference between common exclusion-conditions and additional common exclusion-conditions:
-
Common exclusion-conditions
Used to exclude pre-defined JP1 events when the system is configured so that they cannot be collected or included in automated-action execution.
-
Additional common exclusion-conditions
Used to exclude JP1 events that are determined to be unnecessary during monitoring when the system is operating so that they cannot be collected or included in automated-action execution. If an additional common exclusion-condition is determined to be a necessary exclusion-condition when the system is operating, the system administrator can change the additional common exclusion-condition to a common exclusion-condition.
For smoother operations, you can use common exclusion-conditions and additional common exclusion-conditions as follows as the situation demands:
-
When the system is configured
Use the Common Exclusion-Conditions Settings window or execute the jcochfilter command with the -ef option specified to define the JP1 events not to be monitored by the system. These are the common exclusion-conditions defined in advance.
-
When the system is operating
In the event list in the Event Console window, select the JP1 events that are determined to be unnecessary during monitoring and define them as additional common exclusion-conditions.
-
When the system is reconfigured
Use the Event Acquisition Conditions List window to edit or delete the additional common exclusion-conditions accumulated during system operation. You can also change a JP1 event that is not monitored by the system or included in automated-action execution from an additional common exclusion-condition to a common exclusion-condition.
- Organization of this subsection
(1) Difference between basic mode and extended mode of common exclusion-conditions
The following table compares what you can do when common exclusion-conditions are switched into extended mode with what you can do when common exclusion-conditions are in basic mode. Common exclusion-conditions operate in basic mode by default and after JP1/IM - Manager is installed.
What you can do with common exclusion-conditions |
Basic mode |
Extended mode |
---|---|---|
Filter events by Registered time and Arrived time |
N |
Y |
Filter events by Start time and End time |
N |
Y |
Filter events by Event source host name |
N |
Y |
Filter events by Extended attribute |
Y |
Y |
Compare events by using JP1-specific regular expressions or basic regular expressions |
Y |
N |
Compare events by using extended regular expressions |
Y |
Y |
Define a group of conditions for each agent host |
N |
Y |
Set whether to activate or deactivate common exclusion-conditions for each group of common exclusion-conditions |
Y |
Y |
Add a group of common exclusion-conditions you want to activate or deactivate |
N |
Y |
Specify a period of time for which a group of conditions is applied |
N |
Y |
Write comments |
N |
Y |
Set additional common exclusion-conditions based on the JP1 events occurring while the system is operating |
N |
Y |
Exclude a JP1 event that satisfies a condition |
Y |
Y |
In the JP1 events that was collected, exclude a JP1 event that satisfies a condition from automated-action execution |
N |
Y |
- Legend:
-
Y: Available
N: Not available
The following table describes the difference between basic mode and extended mode of common exclusion-conditions.
Item |
Basic mode |
Extended mode |
---|---|---|
Attributes of event conditions |
Basic attributes:
|
Basic attributes:
|
Common extended attributes:
|
Common extended attributes:
|
|
|
|
|
Comparison types of event conditions# |
|
|
Regular expressions |
|
Extended regular expressions |
Maximum number of common exclusion-conditions groups that can be defined |
30 groups (filter length: 64 kilobytes or shorter) |
2,500 groups (Filter length: 15 megabytes or shorter) |
Contents of definition |
|
|
Method of activating or deactivating common exclusion-conditions |
|
|
Applicable period |
-- |
On the Conditions Apply Period page in the Common Exclusion-Condition Settings (Extended) window, you can set the applicable period. |
Setting method |
Common Exclusion-Conditions Settings window |
|
- Legend:
-
--: Not applicable.
#: Comparison types of event conditions differ depending on the selected attribute. For details, see the following:
-
For basic mode:
3.15 Common Exclusion-Conditions Settings window in the JP1/Integrated Management 3 - Manager GUI Reference.
-
For extended mode:
3.16 Common Exclusion-Condition Settings (Extended) window in the manual JP1/Integrated Management 3 - Manager GUI Reference.
(2) Exclusion target of a common exclusion-condition
You can select an exclusion target of a common exclusion-condition from the following two options:
-
Preventing a JP1 event from being collected when the event satisfies the common exclusion-condition
This option is used to exclude a specified JP1 event from monitoring by preventing the event from being collected. This option is available in basic mode and extended mode. During maintenance work, for example, if you want to prevent JP1 events from being collected only when the events are issued from a host undergoing maintenance, you can just select this option, rather than changing existing event acquisition filter definitions.
-
Excluding a collected JP1 event from automated-action execution when the event satisfies the common exclusion-condition
This option is used to collect JP1 events but exclude a specified JP1 event from automated-action execution. This option is available only in extended mode. During maintenance work, for example, if you want to exclude JP1 events from automated-action execution only when the events are issued from a host undergoing maintenance, you can just select this option, rather than changing existing automated action definitions.
The following figure shows an overview of common exclusion-conditions.
|
JP1 events issued from HostA undergoing maintenance are excluded from monitoring by a common exclusion-condition that prevents the events from being collected. JP1 events issued from Application 2 undergoing maintenance are excluded from automated-action execution by a common exclusion-condition that prevents the events from being included in automated-action execution.
The following figure shows service components for common exclusion-conditions.
|
An event that satisfies a common exclusion-condition that prevents JP1 events from being included in automated-action execution is called an action-excluded event.
The event conditions of common exclusion-condition that prevents JP1 events from being included in automated-action execution are defined independently from the execution conditions of automated action definitions. That is, you can use a single common exclusion-condition to collectively exclude multiple JP1 events from automated-action execution even when the events match different automated action definitions.
Common exclusion-condition that prevents JP1 events from being included in automated-action execution take precedence over whether automated action definitions are enabled or disabled.
Setting a common exclusion-condition that prevents JP1 events from being included in automated-action execution does not affect existing action definitions. When a common exclusion-condition is set and, as a result, no action in an action definition will not be executed, the status (enabled or disabled) of the action definition remains the same. That is, an action with AND-joined conditions and the status of the automated action function are as follows:
-
Action with AND-joined conditions
When a common exclusion-condition is set to exclude a JP1 event from automated-action execution and, as a result, an AND-joined condition is not satisfied, the action is not executed. The action definition including the unsatisfied AND-joined condition remains enabled. The action is not executed even when other AND-joined conditions are satisfied.
-
Status of the automated action function
The status of the automated action function does not change to standby as long as there is an enabled action definition. This is true if no action in the action definition will be executed due to a common exclusion-condition is set to exclude a JP1 event from automated-action execution.
When the integrated monitoring database is used, the event attributes (program-specific extended attributes) listed below are added to an action-excluded event. The attributes can be used as program-specific extended attributes in functions except for the event-source-host mapping function.
-
Common exclude conditions group ID (E.JP1_IMCOMEXCLUDE_ID)
-
Common exclude conditions group name (E.JP1_IMCOMEXCLUDE_NAME)
-
Common exclude conditions group target-for-exclusion (E.JP1_IMCOMEXCLUDE_TARGET)
(3) Additional common exclusion-conditions
The additional common exclusion-conditions are used by defining the monitored JP1 events during system operations. Selecting a JP1 event in the Event Console window or Related Events window sets an additional common exclusion-condition.
To use the additional common exclusion-conditions, you must have the JP1_Console_Admin permission. Also, you must switch the common exclusion-conditions into extended mode. You can define the additional common exclusion-conditions for the following JP1 events:
-
JP1 events registered in the event database of a manager host to which JP1 JP1/IM - View logged in, or in the integrated monitoring database
-
JP1 events registered in the event database of agent hosts
You can set the additional common exclusion-conditions in the Common Exclusion-Condition Settings (Extended) window, which can be displayed as follows:
-
In the Event Console window, select a JP1 event, and select View>Exclude by Common Exclusion-Conditions.
-
In the Event Console window, select a JP1 event, and from the pop-up menu displayed by right-clicking, select Exclude by Common Exclusion-Conditions.
-
In the Related Events window, select a JP1 event, and from the pop-up menu displayed by right-clicking, select Exclude by Common Exclusion-Conditions.
The attribute name and value of the selected JP1 event are displayed and are automatically input as event conditions. The common exclusion-conditions group name and comments are also input and automatically displayed. For details about this window, see 3.16 Common Exclusion-Condition Settings (Extended) window in the JP1/Integrated Management 3 - Manager GUI Reference. For details about the event attribute names that can be specified for event conditions, see Common-exclusion-conditions display item definition file (common_exclude_filter_attr_list.conf) in Chapter 2. Definition Files in the JP1/Integrated Management 3 - Manager Command, Definition File and API Reference.
The defined additional common exclusion-conditions can be edited, deleted, or changed into common exclusion-conditions in the Event Acquisition Conditions List window.
For details about this window, see 3.14 Event Acquisition Conditions List window in the JP1/Integrated Management 3 - Manager GUI Reference.
For details about how to set additional common exclusion-conditions, see 6.5.4 Setting an additional common exclusion-condition to exclude a JP1 event from the monitoring target or action execution in the JP1/Integrated Management 3 - Manager Administration Guide.
(4) Applicable period of a common exclusion-condition
By changing the mode of common exclusion-conditions of the event acquisition filter to extended mode, you can specify an applicable period of a condition for preventing JP1 events from being collected or excluding them from automated-action execution. During the applicable period, the common exclusion-condition in extended mode can prevent JP1 events from being collected or exclude them from automated-action execution only when the events occur during the applicable period.
For example, when the maintenance time for a monitored host is fixed to a certain time, you can specify the applicable period to prevent JP1 events that would occur on the host during the maintenance conducted at certain date and time or at a certain day of the week from being collected or exclude such events from automated-action execution, or to disable conditions groups by restricting the period.
The following example applies common exclusion-conditions in extended mode from 9:00 on Sunday to 9:00 on the next Monday during July 8 in 2011 to September 10 in 2011, according to the maintenance schedule for the monitored host. Note that the applicable period includes the start time, but not the end time. In this example, the applicable period is every week from 09:00:00 on Sunday to 08:59:59 on the following Monday.
|
The time is set according to the time zone designed for the machine on which JP1/IM - Manager is running.
Thus, specifying the applicable period might enable JP1 event filtering without the need of changing conditions groups, or activating or deactivating the common exclusion-conditions. JP1 events that occurred during the applicable period is determined by comparing the Arrived time (B.ARRIVEDTIME) of the JP1 event. Note that you can specify the applicable period for each conditions group. To use the applicable period, common exclusion-conditions groups must be enabled.
You can specify the applicable period on the Conditions Apply Period page in the Common Exclusion-Condition Settings (Extended) window. For details about the Common Exclusion-Condition Settings (Extended) window, see 3.16 Common Exclusion-Condition Settings (Extended) window in the JP1/Integrated Management 3 - Manager GUI Reference.
(5) Information included in a common exclusion history file
JP1/IM - Manager logs the history of the following processes into a common exclusion history file:
-
A JP1 event arrives at JP1/IM - Manager but the event is not collected.
-
A collected JP1 event is excluded from automated-action execution.
-
A common exclusion-conditions definition is applied or changed.
A common exclusion history file is named as follows:
comexcluden#.log
# n is an integer from 1 to 5.
Common exclusion history files are stored in the following locations:
- In Windows:
-
- Physical hosts:
-
console-path\operation\comexclude
- Logical hosts:
-
shared-folder\operation\comexclude
- In UNIX:
-
- Physical hosts:
-
/var/opt/jp1cons/operation/comexclude
- Logical hosts:
-
shared-directory/operation/comexclude
A common exclusion history file is created if it does not exist in the location at any of the times listed below. This is based on the assumption that the operation mode of common exclusion-conditions is set to extended mode.
-
When JP1/IM - Manager starts
-
When JP1/IM - Manager is running and JP1/IM - Manager receives a JP1 event that satisfies a common exclusion-condition
-
When JP1/IM - Manager is running and a common exclusion-conditions definition is applied to JP1/IM - Manager
-
When JP1/IM - Manager is running and a common exclusion-conditions definition is enabled or disabled
A log entry in a common exclusion history file is generated in the following format:
serial-number process-time process-description
The serial-number is a serial number in the common exclusion history. The serial number can be from 00000001 to 99999999. When the number reaches 99999999, it is reset to 00000001. The serial number is also reset to 00000001 when JP1/IM - Manager restarts. The process-time is written in the following format: YYYY/MM/DD hh:mm:ss.SSS (where YYYY is the year, MM month, DD day, hh hour, mm minute, and ss.SSS second).
The following table describes what information is included in the process-description.
No. |
Common exclusion process to be logged |
Information included in the process description |
---|---|---|
1 |
Exclusion is made according to common exclusion-conditions. |
The ID and name of the common exclusion-conditions group that caused the exclusion, and the information of the excluded event are logged.
The placeholders indicate the following:
|
2 |
A common exclusion-conditions definition is updated.# |
A message is logged indicating that a common exclusion-conditions definition is updated. The common exclusion-conditions extended definition was updated. (line break) The additional common exclusion-conditions definition was updated. (line break) |
#: An update is triggered by the following actions:
-
Start JP1/IM - Manager.
-
Update by using the Exclude by Common Exclusion-Conditions menu in the System Environment Settings window in JP1/IM - View.
-
Update by using the jcochfilter -ef command.
-
Enable a common exclusion-condition (with the -e or -on option of the jcochfilter command)
-
Disable a common exclusion-condition (with the -e or -off option of the jcochfilter command)
The details of an update are logged in the common exclusion-conditions definition history file.
The following is an example of a common exclusion history file:
00000001 2017/04/01 12:30:25.131 The common exclusion-conditions extended definition was updated. 00000002 2017/04/01 12:30:25.229 The additional common exclusion-conditions definition was updated. 00000003 2017/04/01 12:35:04.100 Exclude the event from acquiring. (event[SEQNO=10001 ID=4704 SOURCESERVER=hostA ARRIVEDTIME=2017/04/01_12:35:05 SEVERITY=Emergency] common exclusion-conditions[ID=1 NAME= hostA maintenance]) 00000004 2017/04/01 12:35:35.342 Exclude the acquired event from action-executing. (event[SEQNO=10005 ID=4201 SOURCESERVER=hostB ARRIVEDTIME=2017/04/01_12:35:36 SEVERITY=Alert] common exclusion-conditions[ID=A2 NAME= hostB maintenance])
(6) Information included in a common exclusion-conditions definition history file
JP1/IM - Manager logs the definition history of common exclusion-conditions into a common exclusion-conditions definition history file. This file helps you check the detailed definition of a certain common exclusion-conditions group, for example, whose ID or name is found in a common exclusion history file containing the history of exclusion processes.
A common exclusion-conditions definition history file is named as follows:
comexcludeDefn#.log
#: n is an integer 1 or 5.
Common exclusion-conditions definition history files are stored in the following locations:
- In Windows:
-
- Physical hosts:
-
console-path\operation\comexclude
- Logical hosts:
-
shared-folder\operation\comexclude
- In UNIX:
-
- Physical hosts:
-
/var/opt/jp1cons/operation/comexclude
- Logical host:
-
shared-directory/operation/comexclude
A common exclusion-conditions definition history file is created if it does not exist in the location at any of the times listed below. This is based on the assumption that the operation mode of common exclusion-conditions is set to extended mode.
-
When JP1/IM - Manager starts
-
When JP1/IM - Manager is running and a common exclusion-conditions definition is applied to JP1/IM - Manager
-
When JP1/IM - Manager is running and a common exclusion-conditions definition is enabled or disabled
A log entry in a common exclusion-conditions definition history file is generated in the following format:
{+ | -}serial-number process-time process-description
The serial-number is a serial number in the common exclusion-conditions definition history. The serial number can be from 00000001 to 99999999. When the number reaches 99999999, it is reset to 00000001. The serial number is also reset to 00000001 when JP1/IM - Manager restarts. The process-time is written in the following format: YYYY/MM/DD hh:mm:ss.SSS (where YYYY is the year, MM month, DD day, hh hour, mm minute, and ss.SSS second).
Generally, a log entry of a process is written in one line and a plus sign (+) is appended to the top of the line. When a log entry of a process spans multiple lines, a plus sign (+) is appended to the top of the line indicating the start of the process and a minus sign (-) is appended to the top of each subsequent line.
The following table describes what information is included in the process description.
No. |
Common exclusion process to be logged |
Information included in the process description |
---|---|---|
1 |
A common exclusion-conditions definition is updated (by using the System Environment Settings window in JP1/IM - View, or the jcochfilter -ef command). |
The contents of the applied common exclusion-conditions definition (dump of the definition file) are logged. Line 1: The common exclusion-conditions extended definition was updated. (line break) Line 2 and later: contents-of-the-updated-system-common-exclusion-conditions-extended-definition-file When the updated definition has an additional common exclusion-conditions extended definition, the information above is followed by the contents of the additional common exclusion-conditions extended definition file. Line 1: The additional common exclusion-conditions definition was updated. (line break) Line 2 and later: contents-of-the-updated-additional-common-exclusion-conditions-extended-definition-file |
2 |
An additional common exclusion-conditions definition is added (by using Exclude by Common Exclusion-Conditions in JP1/IM - View). |
The contents of the registered additional common exclusion-conditions definition are logged. Line 1: The additional common exclusion-conditions definition was registered. (line break) Line 2 and later: contents-of-the-registered-additional-common-exclusion-conditions-definition |
3 |
A common exclusion-condition is enabled (by using the jcochfilter -e/-on command). |
The ID of the enabled common exclusion-condition is logged.
|
4 |
A common exclusion-condition is disabled (by using the jcochfilter -e/-off command). |
The ID of the disabled common exclusion-condition is logged.
|
The following is an example of a common exclusion-conditions definition history file:
+00000001 2017/04/01 12:30:25.131 The common exclusion-conditions extended definition was updated. -DESC_VERSION=1 - -def hostA maintenance - cmt limit:2017/04/31 - id 1 - valid true - date 20170401-20170431 - week 1,2,3,4,5,6 - rtime 1000-1200 - cnd - B.ID IN 00000001 - E.SEVERITY IN Emergency Alert - B.SOURCESERVER IN hostA - end-cnd -end-def -The additional common exclusion-conditions definition was updated. -DESC_VERSION=2 - -def hostB maintenance - cmt limit:2017/04/31 - id A2 - valid true - ex-target action - date 20170401-20170431 - week 1,2,3,4,5,6 - rtime 1000-1200 - cnd - B.ID IN 00000002 - E.SEVERITY IN Emergency Alert - B.SOURCESERVER IN hostB - end-cnd -end-def +00000002 2017/04/01 12:40:51.849 The additional common exclusion-conditions definition was registered. -def hostC maintenance - cmt limit:2017/04/31 - id A3 - valid true - ex-target action - date 20170401-20170431 - week 1,2,3,4,5,6 - rtime 1000-1200 - cnd - B.ID IN 00000001 - E.SEVERITY IN Emergency Alert - B.SOURCESERVER IN hostC - end-cnd -end-def 00000003 2017/04/01 12:45:41.009 The common exclusion condition became enabled.
(7) Notes on common exclusion-conditions
-
The total number of common exclusion-conditions and additional common exclusion-conditions must be 2,500 or fewer, and the total size must be 15 MB or smaller.
-
JP1 events that common execution conditions prevent from being collected are excluded from the event monitoring targets. The excluded events are no longer displayed in the event list in the Event Console window. When you set common exclusion-conditions, carefully check the settings for event conditions and exclusion targets.
-
If you execute the jcochfilter command with the -ef option specified to apply the extended definitions of common exclusion-conditions, all the defined common exclusion-conditions are replaced. All the definitions of additional common exclusion-conditions that were added during event monitoring will be lost, so be careful.
-
The load on JP1/IM - Manager increases in proportion to the number of common exclusion-conditions and their contents, which might cause the number of monitored JP1 events per unit time to decrease. You should consider consolidating filter conditions for multiple hosts into one condition, for example, by using a regular expression in the filter condition.