6.3.7 ssoapmon action definition file (ssoapmon.def)
The ssoapmon action definition file contains definitions of ssoapmon daemon process actions. If you have made any changes in this definition file, perform one of the following operations to apply these changes:
-
Execute the ssoapcom -r command.
Note that the changes might not become valid depending on the key that has been changed.
-
Restart the ssoapmon daemon process.
- Organization of this subsection
(1) Format
The following is a format for the ssoapmon action definition file.
(2) Description
The next table lists the items that must be or can be defined in an ssoapmon action definition file.
Key name |
Value |
---|---|
threshold-event: <<on>> |
Specify whether to issue the process status change event, service status change event, and application status change event to NNMi. To issue these events, specify on. To not issue these events, specify off. Even when on is specified, the incidents that are filtered with the event filter definition file (ssoevtfilter.conf) will not be issued. Note that if off is specified, no event is issued even when destinations are specified in the event destination definition file (ssodest.conf). |
status-event: <<on>> |
Specify whether to issue the monitoring status change event to NNMi. To issue the event, specify on. To not issue the event, specify off. Even when on is specified, the incidents that are filtered with the event filter definition file (ssoevtfilter.conf) will not be issued. Note that if off is specified, no event is issued even when destinations are specified in the event destination definition file (ssodest.conf). |
nnm-urlaction-coop:#1 <<on>> |
Specify whether to use the NNMi map cooperation function (action cooperation). To use the function, specify on. To not use the function, specify off. |
nnm-map-coop:#1 <<on>> |
Specify whether to use the NNMi map cooperation function (symbol cooperation). To use the function, specify on. To not use the function, specify off. |
map-status-warning:#1 <<minor>> |
Specify the NNMi node status that corresponds to the warning-level application status for the NNMi map cooperation function (symbol cooperation). The warning-level application status can correspond to the warning, minor, major, or critical NNMi node status. For the correspondence between the application status on SSO and the status registered with NNMi, see 2.6.3(2) Correspondence between the statuses managed in SSO and the severity statuses registered in NNMi. |
map-status-critical:#1 <<major>> |
Specify the NNMi node status that corresponds to the critical-level application status for the NNMi map cooperation function (symbol cooperation). The caution-level application status can correspond to the major or critical NNMi node status. For the correspondence between the application status on SSO and the status registered with NNMi, see 2.6.3(2) Correspondence between the statuses managed in SSO and the severity statuses registered in NNMi. |
max-client:#1 <<16>> ((1 to 99)) |
Specify the maximum number of concurrent sessions with the windows and commands#2 that connect to the ssoapmon daemon process. |
change-my-address:#1 <<none>> |
When the monitoring manager has multiple IP addresses or when it is operating in a cluster system, specify the operating IP address of SSO in the n.n.n.n format. (n is an integer from 0 to 255.) In other cases, specify none.
The operating IP address of SSO defined in the ssoapmon action definition file is the destination IP address for the event that is issued by the APM on the monitoring server to the monitoring manager. |
snmp-address: <<default>> |
When operating SSO in a cluster system, specify a logical IP address in the n.n.n.n format. (n is an integer from 0 to 255.) By using this specification, you can use a fixed logical IP address as the monitoring manager IP address that is allowed to pass through the firewall located between the monitoring manager and monitored servers. If multiple logical IP addresses are available, specify the logical IP address at which the monitoring server can communicate with all monitored servers. In other cases, specify default. When default is specified, the local host IP address that enables communication with the monitoring server is used as the monitoring manager IP address that is allowed to pass through the firewall. If multiple local host IP addresses are available for this purpose, the monitoring manager IP address is undefined. Specification of this key is invalid for TCP health check. |
max-snmp-session:#1 <<32>> ((1 to 99)) |
Specify the maximum number of monitored servers that are concurrently connected to the monitoring server. |
max-logfile-size: <<4>> ((1 to 32 megabytes)) |
Specify the maximum size of a log file. |
logfile-num: <<3>> ((1 to 10)) |
Specify the number of the log files. |
trace: <<off>> |
Specify whether to output a trace file for troubleshooting at failure occurrence. To output the trace file, specify on. To not output the trace file, specify off. |
max-tracefile-size: <<4>> ((1 to 32 megabytes)) |
Specify the maximum size of a trace file. |
tracefile-num: <<3>> ((1 to 10)) |
Specify the number of the trace files. |
event-lost-limit: <<50>> ((3 to 160 seconds)) |
Specify the number of seconds during which the system will wait before determining that the APM-issued SNMP trap event has been lost. Specify the maximum interval for event delay.#3 |
event-lost-retry: <<1>> ((0 to 5 times)) |
Specify the number of retries to be attempted when the event is lost. If monitoring cannot be restarted even after retry was attempted the specified number of times, the system then determines that the event was lost. |
omit-unknown-event: <<off>> |
Specify whether to suppress the unknown event#4 that is issued at the detection of APM communication failure (communication error occurrence, stop event reception, or event loss detection) and issue a process and service monitoring failure event. To issue an unknown event (a status change event that has changed to the Unknown status) at the detection of communication failure, specify off. To issue a process and service monitoring failure event instead of issuing the unknown event at the detection of communication failure, specify on. As many unknown events as the number of processes are issued. If you want to collectively manage unknown events, specify the issuance of the process and service monitoring failure event. |
snmp-dump: <<off>> |
Specify whether to output an SNMP packet dump for troubleshooting at failure occurrence. To output the SNMP packet dump, specify on. To not output the SNMP packet dump, specify off. |
max-dumpfile-size: <<8>> ((0 to 99 megabytes)) |
Specify the maximum size of the SNMP packet dump trace file. When 0 is specified, the trace is acquired without limiting the file size. |
sso-start-hcheck-interval:#1 <<0>> ((0 to 60 seconds)) |
Specify the interval at which to execute the system health check at SSO startup in units of the number of monitored servers specified by sso-start-hcheck-unit. |
sso-start-hcheck-delay:#1 <<0>> ((0 to 600 seconds)) |
Specify the delay in starting the system health check at SSO startup. |
sso-start-hcheck-unit:#1 <<1>> ((1 to 32)) |
Specify the number of monitored servers for which to sequentially execute the system health check at SSO startup at the intervals specified by sso-start-hcheck-interval. |
apm-start-hcheck-delay: <<0>> ((0 to 600 seconds)) |
Specify the delay in starting the system health check at the reception of APM start event. |
hcheck-retry-count:#5 <<2>> ((0 to 10 times)) |
Specify the number of retries to be attempted when SSO fails in the health check in communication with APM. When 0 is specified, the health check is not retried. |
hcheck-retry-interval:#5 <<30>> ((0 to 3,600 seconds)) |
Specify the interval of retries (in seconds) to be attempted when SSO fails in the health check in communication with APM. When 0 is specified, the interval of the health checks on agents is used. |
max-apmevtfile-size: <<4>> ((1 to 32 megabytes)) |
Specify the maximum size of a TCP event logging file. |
apmevtfile-num: <<3>> ((1 to 10)) |
Specify the number of the TCP event logging files. |
max-apm-session:#1 <<40>> ((1 to 99)) |
Specify the maximum number of sessions to receive TCP events from APM. |
connect-retry-interval: <<10>> ((3 to 60 seconds)) |
Specify the interval of retries to be attempted when SSO fails in the TCP connection to APM. |
apm-incident-check-interval:#6 <<5>> ((0 to 60 seconds)) |
Specify the interval at which whether an APM incident has occurred is checked. When 0 is specified, APM incidents are not checked. |
apm-incident-delete:#6 #7 <<on>> |
Specify whether to delete APM incidents. Specify on to delete the incidents that occur during the interval of APM incident checks. Specify off to not delete them. When on is specified, all the APM incidents on NNMi are deleted when the ssoapmon daemon process starts. |
max-incident-logfile-size: <<4>> ((1 to 32 megabytes)) |
Specify the maximum size of an incident logging file. |
incident-logfile-num: <<3>> ((1 to 10)) |
Specify the number of the incident logging files. |
func-trace: <<on>> |
Specify whether to output a function trace for investigation of a failure. To output a function trace, specify on. To not output a function trace, specify off. Note that if on is specified for the func-trace: key, the amount of memory used by the ssoapmon process increases by 5 MB, and a 5-MB function trace dump file is output. |
nnm-start-policy: #1 <<0>> ((0 or 1)) |
Specify using 0 or 1 the operation of the ssoapmon daemon process for when there is a failure to acquire NNMi linkage information (node information) while starting up SSO.
|
tcpevent-select-time: <<800>> ((1 to 600,000 milliseconds)) |
Specify the maximum time to wait for reception of a TCP event from APM. |
Timing |
Description |
---|---|
When an APM stop event is received |
When an Agent for Process stop event is received from APM |
When health check fails |
When the health check on APM fails |
When a communication error occurs |
When a request (to change a monitoring condition, change the monitoring interval, or update the status) to APM fails |
When an event loss is detected |
When an event sent from APM is lost |
When coding definitions in an ssoapmon action definition file, note the following:
-
If the definition file includes multiple definitions for the same item, the definition written last is assumed to be valid, and those definitions preceding the last definition are ignored.
-
When omitting the specification of a key on a line, omit the whole line.
-
The maximum number of files that ssoapmon daemon process can open at the same time is obtained by the following formula:
(max-client value) + (max-snmp-session value) + (max-apm-session value) + 20
-
The value of the max-client: key can be calculated by the following formula:
max-client ≥ (number-of-concurrently-opened-windows#1 + number-of-concurrently-executed-commands#2) x number-of-monitoring-managers
- #1: The concurrently opened windows are as follows:
-
Process Monitor window, Process Configuration window, and Process Reference window
- #2: The concurrently executed commands are as follows:
-
ssopsset, ssopsstart, ssopsstop, ssopschk, ssoapcom, ssopscvt, ssopsshow
-
The value of the max-snmp-session: key can be calculated by the following formula:
max-snmp-session > number of monitored servers that cannot communicate with the monitoring manager
- Note
-
If the number of monitored servers that cannot communicate with the monitoring manager exceeds the value of the max-snmp-session: key, the health check might be delayed and not be executed according to the settings. If this occurs, adjust the settings so that the number of monitored servers matches the above formula, or extend the health check interval.
-
The value of the max-apm-session: key can be calculated by the following formula:
max-apm-session ≥ ((number-of-monitored-servers) / (1 + (number-of-retries-by-APM))) x 1.2 (safety-factor)
- Note
-
If the value of the max-apm-session key exceeds 99 (maximum specifiable value) when the value is calculated with a maximum number of retries by APM, reduce the value of the key to 99, and then enable regular health checks.
For details on setting the retry count for APM, see 6.4.7 Event TCP notification definition file (apmtcpsend.conf).