Hitachi

JP1 Version 12 JP1/SNMP System Observer Description, Operator's Guide and Reference


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:

Organization of this subsection

(1) Format

The following is a format for the ssoapmon action definition file.

[Figure]

(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.

  • When the monitoring manager has multiple IP addresses:

    Specify an IP address at which SSO can communicate with the monitoring server. You can freely select one of the monitoring manager's IP addresses at which SSO can communicate with the monitoring server.

  • When operating SSO in a cluster system:

    Specify a logical IP address.

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.

  • 0: Do not stop the daemon process.

  • 1: Stop the daemon process.

tcpevent-select-time:

<<800>> ((1 to 600,000 milliseconds))

Specify the maximum time to wait for reception of a TCP event from APM.

#1: If you change the value of this item, you must restart the ssoapmon daemon process.

#2: The following lists the windows and commands that connect to the ssoapmon daemon process:

  • Process Monitor window

  • Process Reference window

  • Process Configuration window

  • ssoapcom command

  • ssopschk command

  • ssopsset command

  • ssopsshow command

  • ssopsstart command

  • ssopsstop command

#3: The value of the event-lost-limit: key must be a value that is calculated by the following formula:

event-lost-limit = A x 2 + 40

The value of A must be the greater value of the following keys in the respective definition files:

- DINTERVAL: key of the event-delay configuration file (apmdelay.conf)

- apm-incident-check-interval: key of the ssoapmon action definition file (ssoapmon.def)

#4: The following table describes the timings of suppressing unknown events.

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

#5: The health check is retried at the following timings:

  • When a start event is received from APM

  • When the health check interval has passed since the last health check succeeded

  • When an event other than the stop event is received from the APM recognized by SSO as stopped APM

  • When the ssoapcom -H command is received

  • When an error is detected in TCP connection or event transmission or reception during the event notification from APM on TCP

#6: An APM incident is an incident converted by NNMi from an event that was reported to NNMi as an SNMP trap by APM.

#7: The number of SNMP traps NNMi can receive is limited. If the number of traps received by NNMi comes close to the maximum limit, the SNMP trap events from APM are not converted any more, and process monitoring is thereby disabled. For this reason, be careful to prevent the number of traps received by NNMi from coming close to the maximum limit. For the SNMP trap reception by NNMi and the specifications of the conversion of received SNMP traps into incidents, see the NNMi Help.

When coding definitions in an ssoapmon action definition file, note the following: