6.2.1 Monitoring functions of service linkage objects monitoring jobs

The monitoring function provided by the service linkage object monitoring job is a function that detects objects created, deleted, or updated on an object storage service in a cloud environment. Here, detailed information about the function and processing related to the monitoring processing for detecting this event is presented.

Organization of this subsection

(1) About the details of events to be monitored and the monitoring processing
(2) Behavior when the information acquisition command runs
(3) Processing for extracting object information on the cloud service
(4) About how to specify the names of monitoring target objects

(1) About the details of events to be monitored and the monitoring processing

The following explains the events monitored by cloud service linkage object monitoring jobs:

Table 6‒1: Types and details of events to be monitored
Item	Event type	Description of operations and conditions for detection
1	Creation	If an object that did not exist at some point in time does exist during the next monitoring interval, JP1 determines that the object has been created and issues an event notification. In addition, if an object already exists when the monitoring is performed for the first time, you can select an option for whether that established that the condition is met.
2	Deletion	If an object that did exist at some point in time does not exist during the next monitoring interval, JP1 determines that the object is deleted and issues an event notification. In addition, if the object does not exist when the monitoring is performed for the first time, you can select an option for whether that establishes that the condition is met.
3	Update	If an object existed at some point in time and a change occurs to an information value of the object during the next monitoring interval, JP1 determines that the object is updated and issues an event notification. Up to three information items can be specified as the monitoring targets. If multiple items are specified, the OR condition is used to determine whether the condition is established.

Details of the event detection processing described above are shown below.

Figure 6‒2: Details of the event detection processing

As explained above, extracted information is saved when the monitoring is performed for the first time. During the subsequent monitoring processes, JP1 compares the extracted information with the previously monitored information and determines whether the monitoring conditions for creation, deletion, and update are established.

JP1 uses the following criteria to determine whether the conditions are established:

For creation: It is considered that creation is performed if the object name specified as the monitoring target object name matches one of the extracted object names that did not exist previously. If the initial monitoring option is specified, the condition is met if a matching object exists when the monitoring starts.
For deletion: It is considered that deletion is performed if the object name specified as the monitoring target object name matches one of the extracted object names that existed previously. If the initial monitoring option is specified, the condition is met if no matching object exists when the monitoring starts.
For update: If the object name specified as the monitoring target matches the object name of the objects with differences in the extracted update monitoring target information compared to the previous monitoring, it is considered updated.

For details on behavior when the information acquisition command runs, see 6.2.1(2) Behavior when the information acquisition command runs. For details on the extraction processing, see 6.2.1(3) Processing for extracting object information on the cloud service. For details on how to specify the monitoring target object name, see 6.2.1(4) About how to specify the names of monitoring target objects.

To Page Top

(2) Behavior when the information acquisition command runs

There is an upper limit to the size that can be handled, because memory resources are consumed by the standard output and the standard error output for the information acquisition command to be executed for the monitoring processing.

When over the upper limit of the standard output, output the KNBB6306-E message to the service linkage object monitoring job log file, and the service linkage object monitoring job is terminated with abnormal.

You can change the upper limit value of the standard output with the environment setting parameter LimitObjMonStdOutSize.

The upper limit on the standard error output is 3,072 KB.

When over the upper limit of the standard error output, output the KNBB6307-W message to the service linkage object monitoring job log file, and the service linkage object monitoring job continues.

For each, consider using command options in a way that the amount of information to be acquired by the information acquisition command during operation will not exceed the upper limit explained above.

To Page Top

(3) Processing for extracting object information on the cloud service

A service linkage objects monitoring job executes a command to acquire object list information, extracts object names and updates monitoring target information from the list information, and determines whether the monitoring condition is met. It can have up to three update monitoring targets.

The service linkage objects monitoring job can deal with the object list information in JSON format. The object names and update monitoring target information are extracted by analyzing the JMESPath query syntax.

The results extracted through the JMESPath query syntax analysis must meet the following conditions:

The extraction result of an object name must be a JSON array with a string as its element^{#1, #2}.
The extraction result of update monitoring target information^{#3, #4} must be a JSON array with one of strings, numeric values^#5, or Boolean values and null values as its element (mix of types allowed).
If update monitoring target information^{#3, #4} is specified, the number of values to be extracted must be equal to the number of array elements of Object name^#6.

#1: If the same object name is output several times within an array, the update information of the last output number of array elements is enabled.
#2: Null characters cannot be used for object names.
#3: The update monitoring target information is an optional item and therefore does not need to be specified if update monitoring is not enabled in the monitoring condition. In addition, if you want to enable update monitoring, specify up to three monitoring targets.
#4: If nothing is specified for the update monitoring target information even though update monitoring is enabled in the monitoring condition, a KNBB6103-E message is output to the service linkage objects monitoring job log file and the service linkage objects monitoring job ends abnormally.
#5: Numeric data must be an integer value with a range from -10,995,116,277,760 to 10,995,116,277,760. Values other than this value (values outside the scope, decimal fractions, and exponent notations) are rounded to other values and might not be extracted to valid values. Therefore, the processing for monitoring completion might not work properly. Alternatively, the object monitoring job might be terminated abnormally with the KNBB6107-E message saying that numerical information that cannot be handled by service linkage object monitoring jobs was detected.
#6: The update monitoring targets do not have to be specified in the same order of the definitions of Update monitoring target 1, Update monitoring target 2, and Update monitoring target 3. Check that the number of update information fields with a value specified for it is the same as the number of object name elements.

A KNBB6106-E message if the above conditions are not met, or a KNBB6105-E message if an error occurs in extract processing according to the JMESPath query syntax is output to the service linkage objects monitoring job log file. Then the service linkage objects monitoring job ends abnormally.

Verify that the above specifications work for extraction and then configure monitoring processing. For the JMESPath query syntax, see the JMESPath official website.

As shown in the following example, you can extract a list of object names and the size, the update date/time, and the owner of each object from the standard output result of the information acquisition command as the update monitoring target information and use this information as the monitoring target:

Information acquisition command (displays a list of objects below /objects in JSON format)
```
get-object-info list /objects
```

Command execution result (Object names, update dates/times, sizes, and owners are displayed as object list information in the standard output)

{
    "Information": [
        {
            "ObjectName": "object01",
            "ObjectUpdateTime": "2024-09-01T00:00:00+00:00",
            "ObjectSize": 100,
            "ObjectOwner": "User01"
        },
        {
            "ObjectName": "object02",
            "ObjectUpdateTime": "2024-09-01T12:30:30+00:00",
            "ObjectSize": 200,
            "ObjectOwner": "User02"
        }
    ]
}

Specification methods and extraction results related to the extraction processing (JMESPath query statement)

Object name
  Specification method: Information[].ObjectName
  Extraction result: [ "object01", "object02" ]
Update monitoring target 1 (update date/time)
  Specification method: Information[].ObjectUpdateTime
  Extraction result: [ "2024-09-01T00:00:00+00:00", "2024-09-01T12:30:30+00:00" ]
Update monitoring target 2 (size)
  Specification method: Information[].ObjectSize
  Extraction result: [ 100, 200 ]
Update monitoring target 3 (owner)
  Specification method: Information[].ObjectOwner
  Extraction result: [ "User01", "User02" ]

The extracted information (see above) and the specifications in 6.2.1(4) About how to specify the names of monitoring target objects are used to carry out the monitoring processing as shown in 6.2.1(1) About the details of events to be monitored and the monitoring processing.

To Page Top

(4) About how to specify the names of monitoring target objects

The name of an object to be monitored is specified in the custom event job definition.

You can specify a monitoring object with a single object name or monitoring objects with multiple object names. You need to specify a generic name with a wildcard character (*) to specify multiple objects. A generic name can use the wildcard character (*) only.

Review the following notes if you use the wildcard:

The * section matches any character string.
If you want to use the asterisk (*) itself, use a preceding \ character to escape the asterisk (*).
If you want to use the backslash (\) itself, use a preceding \ character to escape the backslash (\).
If a character other than the asterisk (*) is specified immediately after a backslash (\), the backslash (\) is ignored.

Example: If \a is specified, it is handled as a.
If a character string ends with a backslash (\), the backslash (\) is ignored.

Example: If a\ is specified, it is handled as a.
If two or more consecutive asterisks (*) are specified, the second and subsequent asterisks (*) are ignored.

Example: If a** is specified, it is handled as a*.

To Page Top