This section reproduces the man page for the mfwkadm command, a maintenance command in man page section 1M. Use this command to manage the contents of a node agent, including all of the modules for components being monitored and any monitoring rules, also known as jobs, that you have defined on this node. Some of the terms and descriptions in the man page have been modified here to match those used in this document.
The mfwkadm utility is the command line interface for managing the Monitoring Framework agent, also called the node agent. The node agent runs inside the Common Agent Container. The mfwkadm utility can be used to stop and restart the node agent and to manage the monitoring jobs it performs. This command should be run from the same host where the node agent is running. The order of the arguments of this command presented here must be respected.
To change the language of the output messages, set the LC_MESSAGE environment variable to your locale. The mfwkadm command will use the messages contained in the file named JesmfMessages_locale.pm in the lib/resources directory. If the locale has no corresponding file of messages, or if no locale is specified, the mfwkadm command will use the default set of messages in the file JesmfMessages.pm.
The mfwkadm utility has the following subcommands. Those marked with an asterisk (*) require the Common Agent Container to be running and the node agent to be loaded:
start
stop
restart
list-params (*)
list-modules (*)
info (*)
pm-job (*)
opstat-job (*)
thrsh-job (*)
Depending on the number of Common Agent Container modules to load, there is a delay of a few seconds to a few minutes between starting the node agent and the availability of the mfwkadm utility. During this period of time, commands fail with an explicit message.
The following options are supported.
Display the usage summary.
Start the Monitoring Framework node agent and its associated component product modules without stopping the Common Agent Container.
This action first deploys the node agent and then deploys the associated component product modules in the Common Agent Container. This facility is a wrapper on top of the cacaoadm utility's lock and undeploy subcommands.
The start subcommand only starts the node agent and the Java ES component modules associated with the Monitoring Framework. Component modules have the prefix com.sun.cmm.
Security: The start subcommand can be run only by the user who launched the Common Agent Container. Otherwise an error message similar to the following will be displayed:
Error occured in mfwkadm Problem running /usr/sbin/cacaoadm unlock com.sun.mfwk 2>&1. Stdout/Stderr: This command must be run by user: [root]. |
Stop the Monitoring Framework node agent and its associated Java ES component modules in the Common Agent Container.
This action first stops any Java ES component's modules deployed in the Common Agent Container, and then stops the node agent. This facility is a wrapper on top of the cacaoadm lock and unlock subcommands.
The stop subcommand stops only those Java ES component modules associated with the Monitoring Framework and then the node agent itself. Component modules have the prefix com.sun.cmm.
Security: The stop subcommand can be run only by the user who launched the Common Agent Container. Otherwise an error message similar to the following will be displayed:
Error occured in mfwkadm Problem running /usr/sbin/cacaoadm unlock com.sun.mfwk 2>&1. Stdout/Stderr: This command must be run by user: [root]. |
Restart the Monitoring Framework node agent and its associated Java ES component modules in the Common Agent Container.
This action will attempt to stop and then start the node agent and its associated modules in the Common Agent Container in the same way as the stop and start subcommands.
Security: The restart subcommand can be run only by the user who launched the Common Agent Container. Otherwise an error message similar to the following will be displayed:
Error occured in mfwkadm Problem running //usr/sbin/cacaoadm unlock com.sun.mfwk 2>&1. Stdout/Stderr: This command must be run by user: [root]. |
List all the configuration parameters related to the Monitoring Framework node agent.
Security: There is no user restriction for this command.
Display a list of those component product modules that implement the Common Monitoring Model (CMM) and that are loaded into the Common Agent Container. This subcommand also lists all running instances of each installed Java ES component. Each component can have zero, one, or more running instances.
Security:For users other than the one who launched the Common Agent Container, the list of installed Java ES components does not include component instances.
Display information on the named runningInstance. The runningInstance must match a running instance listed in the output of the list-modules subcommand.
The displayed information includes:
For each type of monitoring job, all observable objects associated with the running instance, sorted by their class name. Observable objects are those on which you can create a performance monitoring job, an operational status job, or a threshold monitoring job using the pm-job, opstat-job, or thrsh-job subcommands, respectively.
For each class of observable objects, all of its observable attributes, including the name and type of each.
Security: For users other than the one who launched the Common Agent Container, no information will be displayed.
Display the list of all currently observable classes of objects for which you can create performance monitoring jobs.
Display the list of all currently observable objects for which you can create performance monitoring jobs. By default all objects of all observable classes and in every domain will be listed. The list of objects is sorted by their class name.
Specifying the optional objectClass will restrict the output to observable objects of that specific class. The objectClass must be one of the classes listed by the pm-job observable-classes subcommand.
Specifying the optional objectDomain will restrict the output to observable objects in that domain. The domain of an object is the string preceding the colon (“:”) character in an object's name.
Display the list of all observable attributes in the specified objectClass. Attributes are displayed with their name and type. The objectClass must be one of the classes that supports performance monitoring jobs, as listed by the pm-job observable-classes subcommand.
Displays the list of all currently defined performance monitoring jobs. Jobs are listed for each object having a defined performance job, and objects are sorted by their class name. The information displayed for each job is the same as displayed by the pm-job info subcommand.
Security: For other users than the one who launched the Common Agent Container, no jobs will be displayed.
Display verbose information about a performance monitoring job named jobName. The jobName must be one displayed by the pm-job list subcommand. This subcommand displays the following information:
The name of the performance monitoring job.
The type of the performance monitoring job, either “by object” or “by class.” Jobs by object monitor one or more named object instances, whereas jobs by class monitor every instance of an object class. Note that it is not possible to create jobs by class with the mfwkadm utility.
The state of the performance monitoring job: active on-duty, active off-duty, or suspended. An active on-duty job is currently scheduled to run and is collecting data. An active off-duty job is running but not collecting data because the current time is out of its working schedule. A suspended job is not running nor collecting any data. Use the pm-job suspend and pm-job resume subcommands to change the running state of a performance monitoring job.
The granularity in seconds of the performance monitoring job. This is the interval for data collection by this job.
The reporting period of the monitoring job. The reporting period times the granularity equals the notification frequency. For example, if the granularity period is 10 seconds and the reporting period is 6, a job reporting by event will collect data every 10 seconds and will send a notification including 6 reports every 60 seconds (10*6). If the job is also reporting by file, it will send an event every 60 seconds containing the locations of the 6 generated files.
Whether the performance monitoring job is reporting by event. This means the results of the performance monitoring job are sent as notifications to a registered client.
Whether the performance monitoring job is reporting by file. This means the reports of the performance monitoring job are written in local files and notifications containing the filenames are sent to registered clients.
The report format of the performance monitoring job, which is always XML.
The schedule of the performance monitoring job. The schedule specifies what days and times the job is active on-duty or active off-duty (collecting data or not, respectively).
Then for a job by-object:
The list of observed objects, ordered by name.
If only a subset of observable attributes are specified, the observed attributes of the observed objects are listed by name and type.
And for a job by-class:
The list of observed classes, ordered by name.
If only a subset of observable attributes are specified, the observed attributes of the observed classes are listed by name and type. These attributes are common to all classes.
Security: For users other than the one who launched the Common Agent Container, no information will be displayed.
Creates a new performance monitoring job on one or more objects. The mfwkadm command cannot create jobs by class. When creating performance monitoring jobs, the following parameters can be set:
A string uniquely identifying the performance monitoring job. The jobName cannot be already in use by any other performance monitoring job.
The time specified in seconds between the initiation of two successive collections of measurement data, while the job is active on-duty. Examples of granularity period can be 300 seconds (5 minutes), 900 seconds (15 minutes), 1800 seconds (every half-hour), 3600 seconds (every hour). A granularity period of 300 seconds is sufficient in most cases. For some measurements it can be more meaningful to collect data with larger granularity periods.
One or more observable objects that the performance monitoring job will collect data from and report on. The objectName must be one displayed by the pm-job list or pm-job observable-objects subcommands. Specifying multiple object=objectName parameters will create a single performance monitoring job that monitors multiple objects.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Delete a performance monitoring job named jobName. The jobName must be one displayed by the pm-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Suspend a performance monitoring job named jobName. A suspended job is not active and will no longer collect data, regardless of its schedule. However, the job remains defined and can be made active again with the pm-job resume subcommand. The jobName must be one displayed by the pm-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Resume a performance monitoring job named jobName. A resumed job will begin collecting data and sending reports according to its schedule. The jobName must be one displayed by the pm-job list subcommand. This is the counterpart to the pm-job suspend subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Display the list of all currently observable classes of objects for which you can create operational status monitoring jobs.
Display the list of all currently observable objects for which you can create operational status monitoring jobs. By default all objects of all observable classes and in every domain will be listed. The list of objects is sorted by their class name.
Specifying the optional objectClass will restrict the output to observable objects of that specific class. The objectClass must be one of the classes listed by the opstat-job observable-classes subcommand.
Specifying the optional objectDomain will restrict the output to observable objects in that domain. The domain of an object is the string preceding the colon (“:”) character in the object's name.
Display the list of all observable attributes in the specified objectClass. Attributes are displayed with their name and type. The objectClass must be one of the classes listed by the opstat-job observable-classes subcommand.
Displays the list of all currently defined operational status monitoring jobs. Jobs are listed for each object having a defined operational status job, and objects are sorted by their class name. The information displayed for each job is the same as displayed by the opstat-job info subcommand.
Security: For other users than the one who launched the Common Agent Container, no jobs will be displayed.
Display verbose information about an operational status monitoring job named jobName. The jobName must be one displayed by the opstat-job list subcommand. This subcommand displays the following information:
The name of the operational status monitoring job.
The type of the operational status monitoring job, either “by object” or “by class.” Jobs by object monitor a named object instance, whereas jobs by class monitor every instance of an object class. Note that it is not possible to create jobs by class with the mfwkadm utility.
The state of the operational status monitoring job: active on-duty, active off-duty, or suspended. An active on-duty job is currently scheduled to run and is collecting data. An active off-duty job is running but not collecting data because the current time is out of its working schedule. A suspended job is not running nor collecting any data. Use the opstat-job suspend and opstat-job resume subcommands to change the running state of an operational status monitoring job.
The granularity in seconds of the operational status monitoring job. This is the interval for data collection by this job.
Whether the operational status monitoring job is reporting by event. This means the results of the operational status monitoring job are sent as notifications to a registered client.
Whether the operational status monitoring job is reporting by file. This means the reports of the operational status monitoring job are written in local files and notifications containing the filenames are sent to registered clients.
The report format of the operational status monitoring job, which is always XML.
The schedule of the operational status monitoring job. The schedule specifies what days and times the job is active on-duty or active off-duty (collecting data or not, respectively).
For a job by-object, the list of observed objects, ordered by name.
For a job by-class, the list of observed classes, ordered by name.
Security: For users other than the one who launched the Common Agent Container, no information will be displayed.
Creates a new operational status monitoring job on one or more objects. The mfwkadm command cannot create jobs by class. When creating performance monitoring jobs, the following parameters can be set:
A string uniquely identifying the operational status monitoring job. The jobName cannot be already in use by any other operational status monitoring job.
The time specified in seconds between the initiation of two successive collections of measurement data, while the job is active on-duty.
One or more observable objects that the operational status monitoring job will collect data from and report on. The objectName must be one displayed by the opstat-job list or opstat-job observable-objects subcommands. Specifying multiple object=objectName parameters will create a single operational status job that monitors multiple objects.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Delete an operational status monitoring job named jobName. The jobName must be one displayed by the opstat-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Suspend an operational status monitoring job named jobName. A suspended job is not active and will no longer collect data, regardless of its schedule. However, the job remains defined and can be made active again with the opstat-job resume subcommand. The jobName must be one displayed by the opstat-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Resume an operational status monitoring job named jobName. A resumed job will begin collecting data and sending reports according to its schedule. The jobName must be one displayed by the opstat-job list subcommand. This is the counterpart to the opstat-job suspend subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Display the list of all currently observable classes of objects for which you can create threshold monitoring jobs.
Display the list of all currently observable objects for which you can create threshold monitoring jobs. By default all objects of all observable classes and in every domain will be listed. The list of objects is sorted by their class name.
Specifying the optional objectClass will restrict the output to observable objects of that specific class. The objectClass must be one of the classes listed by the thrsh-job observable-classes subcommand.
Specifying the optional objectDomain will restrict the output to observable objects in that domain. The domain of an object is the string preceding the colon (“:”) character in the object's name.
Display the list of all observable attributes in the specified objectClass. Attributes are displayed with their name and type. The objectClass must be one of the classes listed by the thrsh-job observable-classes subcommand.
Displays the list of all currently defined threshold monitoring jobs. Jobs are listed for each object having a defined threshold job, and objects are sorted by their class name. The information displayed for each job is the same as displayed by the thrsh-job info subcommand.
Security: For other users than the one who launched the Common Agent Container, no jobs will be displayed.
Display verbose information about a threshold monitoring job named jobName. The jobName must be one displayed by the thrsh-job list subcommand. This subcommand displays the following information:
The name of the threshold monitoring job.
The multiplicity of the threshold monitoring job. In this release, only simple threshold jobs that monitor one attribute on one object are possible.
The state of the threshold monitoring job: active on-duty, active off-duty, or suspended. An active on-duty job is currently scheduled to run and is collecting data. An active off-duty job is running but not collecting data because the current time is out of its working schedule. A suspended job is not running nor collecting any data. Use the thrsh-job suspend and thrsh-job resume subcommands to change the running state of a threshold monitoring job.
The granularity in seconds of the threshold monitoring job. This is the interval for data collection by this job.
The schedule of the threshold monitoring job. The schedule specifies what days and times the job is active on-duty or active off-duty (collecting data or not, respectively).
The alarm configuration of the threshold monitoring job. This is the alarm that will be triggered when the observed value of the monitored attribute crosses the defined threshold value. The display includes the alarm's type and severity.
The observed object of the threshold monitoring job.
The attribute name to which the threshold is applied.
The value of the threshold that will trigger an alarm.
The direction of the value's progress that will trigger an alarm at the threshold, either RISING or FALLING.
The tolerance offset of the threshold. When the direction is RISING, an alarm will not be triggered again until the observed attribute is less than the thresholdValue-offsetValue. When the direction is FALLING, an alarm will not be triggered again until the observed attribute is more than the thresholdValue+offsetValue. This behavior holds true even when the offset is zero.
Security: For users other than the one who launched the Common Agent Container, no information will be displayed.
Creates a new threshold monitoring job that monitors one attribute on a single object. When creating threshold jobs, the following parameters can be set:
A string uniquely identifying the threshold monitoring job. The jobName cannot be already in use by any other threshold monitoring job.
The observable object on which the threshold monitoring job will collect the attribute values to compare against the threshold. The objectName must be one displayed by the thrsh-job list or thrsh-job observable-objects subcommands.
The time specified in seconds between the initiation of two successive observations of the attribute value, while the job is active on-duty.
The name of the attribute for which the threshold monitoring job gathers values and compares compare them to the threshold. The attributeName must be listed by the thrsh-job info or thrsh-job observable-attributes subcommands.
The type of the observable attribute to be monitored. The attributeType must be listed by the thrsh-job info or thrsh-job observable-attributes subcommands.
The value of the monitored attribute that will cause this threshold job to trigger an alarm when crossed in the direction specified by thresholdDirection.
The offsetValue determines the tolerance of the threshold job in triggering successive alarms. The offsetValue must be zero or a positive value. After an alarm event is triggered, no new alarm event will be triggered until the value of the monitored attribute exceeds the range defined by the offsetValue and the thresholdDirection.
When the direction is RISING, an alarm event will not be triggered again until the observed attribute value is less than thresholdValue-offsetValue. When the direction is FALLING, an alarm event will not be triggered again until the observed attribute value is more than thresholdValue+offsetValue. This behavior holds true even when the offsetValue is zero.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Delete a threshold monitoring job named jobName. The jobName must be one displayed by the thrsh-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Suspend a threshold monitoring job named jobName. A suspended job is not active and will no longer collect data, regardless of its schedule. However, the job remains defined and can be made active again with the thrsh-job resume subcommand. The jobName must be one displayed by the thrsh-job list subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
Resume a threshold monitoring job named jobName. A resumed job will begin collecting data and sending reports according to its schedule. The jobName must be one displayed by the thrsh-job list subcommand. This is the counterpart to the thrsh-job suspend subcommand.
Security: This subcommand can be run only by the user who launched the Common Agent Container.
The following fictional scenario demonstrates how to use the mfwkadm utility, along with its options and subcommands.
The list-modules subcommand shows the Java ES component instances on the current host and their corresponding modules in the Common Agent Container. The following example lists two installed components, Directory Server having no running instances and Web Server having one running instance.
$ mfwkadm list-modules Installed products and their running instances: ============================================== Instances for installed product: com.sun.cmm.ds:collectionID=/opt/SUNWdsee/ds6, name=Sun Java(TM) System Directory Server,type=CMM_InstalledProduct ------------------------------- No instance. Instances for installed product: com.sun.cmm.ws:collectionID=/var/opt/SUNWwbsvr7, name=WebServer,type=CMM_InstalledProduct ------------------------------- /wsPrefix/com.sun.cmm.ws:name=https-hostname.example.com,type=CMM_ApplicationSystem |
The following info subcommand displays observable objects in the Web Server instance, with their classes and attributes for each job type.
$ mfwkadm info /wsPrefix/com.sun.cmm.ws:name=https-hostname.example.com,\\ type=CMM_ApplicationSystem Information about running instance: /wsPrefix/com.sun.cmm.ws: name=https-hostname.example.com,type=CMM_ApplicationSystem ================================== Observable objects for performance jobs: --------------------------------------- + Objects of class: com.sun.cmm.settings.CMM_ApplicationSystemSetting /wsPrefix/com.sun.cmm.ws:name=https-hostname.example.com-setting, type=CMM_ApplicationSystemSetting Observable attributes: Caption [STRING] ConfigurationDirectory [STRING] CreationClassName [STRING] Description [STRING] DirectoryName [STRING] ElementName [STRING] InstanceID [STRING] Name [STRING] URL [STRING] + Objects of class: com.sun.cmm.settings.CMM_KeepAliveSetting /wsPrefix/com.sun.cmm.ws:name=process-1-keepalive-setting, type=CMM_KeepAliveSetting Observable attributes: AllocationUnit [STRING] Caption [STRING] ConnectionsUpperBound [LONG] CreationClassName [STRING] Description [STRING] ElementName [STRING] InputUnit [STRING] InstanceID [STRING] LowerAllocationLimit [LONG] LowerInputLimit [LONG] LowerOutputLimit [LONG] Name [STRING] OtherAllocationUnit [STRING] OtherInputUnit [STRING] OtherLowerAllocationLimit [LONG] OtherLowerInputLimit [LONG] OtherLowerOutputLimit [LONG] OtherOutputUnit [STRING] OtherUpperAllocationLimit [LONG] OtherUpperInputLimit [LONG] OtherUpperOutputLimit [LONG] OutputUnit [STRING] QueuedUpperBound [LONG] SecondsTimeout [LONG] TimeoutUpperBound [LONG] UpperAllocationLimit [LONG] UpperInputLimit [LONG] UpperOutputLimit [LONG] ... |
The following command shows the list of defined performance monitoring jobs. In this example, there is one performance job called myPerfJob that monitors one object:
$ mfwkadm pm-job list BY_OBJECTS performance jobs: =========================== Performance job information for: myPerfJob ------------------------------- Type: BY_OBJECTS State: ACTIVE_ON_DUTY Granularity period: 30 Reporting period: 1 By event: EVENT_SINGLE By file: EVENT_SINGLE Report format: XML Schedule: Global start time: Immediately Global stop time: Forever Weekly schedule: Everyday Daily schedule: All day Observed objects: /wsPrefix/com.sun.cmm.ws:name=virtualServer-hostname.example.com- webApp-/-stats,type=CMM_VirtualServerWebModuleStats Observed attributes: All available BY_CLASSES performance jobs: =========================== No jobs found. |
The following command creates an operational status monitoring job related to two observable objects obtained from the opstat-job info or opstat-job observable-objects subcommands:
$ mfwkadm opstat-job create myOpStatJob granularity=60 \\ object=/wsPrefix/com.sun.cmm.ws:name=process-1,type=CMM_UnixProcess \\ object=/wsPrefix/com.sun.cmm.ws:name=process-1-DNSCache1,type=CMM_DnsCache |
The following command suspends the job created above:
$ mfwkadm opstat-job suspend myOpStatJob |
The following command shows the observable classes for the potential threshold monitoring jobs:
$ mfwkadm thrsh-job observable-classes Threshold jobs observable classes: ================================= com.sun.cmm.cim.CIM_ScopedSettingData com.sun.cmm.cim.CIM_SettingData com.sun.cmm.cim.CIM_StatisticalData com.sun.cmm.cim.statistics.CIM_EthernetPortStatistics com.sun.cmm.cim.statistics.CIM_NetworkPortStatistics com.sun.cmm.cim.statistics.j2ee.CIM_J2eeJVMStats com.sun.cmm.cim.statistics.j2ee.CIM_J2eeStatistic com.sun.cmm.settings.CMM_ApplicationSystemSetting com.sun.cmm.settings.CMM_KeepAliveSetting com.sun.cmm.settings.CMM_QueueTimeoutSetting com.sun.cmm.settings.CMM_RFC2788ApplicationSystemSetting com.sun.cmm.settings.CMM_ScopedSettingData com.sun.cmm.settings.CMM_SoftwareResourceSetting com.sun.cmm.settings.CMM_SWRBufferSetting com.sun.cmm.settings.CMM_SWRLimitSetting com.sun.cmm.settings.CMM_SWRQueueSetting com.sun.cmm.settings.CMM_VirtualServerSetting com.sun.cmm.statistics.CMM_ApplicationSystemStats com.sun.cmm.statistics.CMM_ApplicationSystemWatchdogStats com.sun.cmm.statistics.CMM_ConnectionQueueStats com.sun.cmm.statistics.CMM_DnsCacheStats com.sun.cmm.statistics.CMM_EthernetPortStats com.sun.cmm.statistics.CMM_FileCacheStats com.sun.cmm.statistics.CMM_HTTPResponsesStats com.sun.cmm.statistics.CMM_JVMJSR174ExtStats com.sun.cmm.statistics.CMM_JVMJSR174Stats com.sun.cmm.statistics.CMM_JVMStats com.sun.cmm.statistics.CMM_NetworkPortStats com.sun.cmm.statistics.CMM_OperatingSystemStats com.sun.cmm.statistics.CMM_ProcessorStats com.sun.cmm.statistics.CMM_ProcessStats com.sun.cmm.statistics.CMM_QueueTimeoutStats com.sun.cmm.statistics.CMM_RFC2788ApplicationTableStats com.sun.cmm.statistics.CMM_ServiceStats com.sun.cmm.statistics.CMM_SoftwareResourceStats com.sun.cmm.statistics.CMM_SolarisEthernetPortStats com.sun.cmm.statistics.CMM_SolarisNetworkPortStats com.sun.cmm.statistics.CMM_SolarisOperatingSystemStats com.sun.cmm.statistics.CMM_SolarisProcessorStats com.sun.cmm.statistics.CMM_SolarisProcessorSysinfoStats com.sun.cmm.statistics.CMM_SolarisProcessorVmStats com.sun.cmm.statistics.CMM_Statistic com.sun.cmm.statistics.CMM_SWRBufferStats com.sun.cmm.statistics.CMM_SWRCacheStats com.sun.cmm.statistics.CMM_SWRLimitStats com.sun.cmm.statistics.CMM_SWRQueueStats com.sun.cmm.statistics.CMM_UnixOperatingSystemStats com.sun.cmm.statistics.CMM_UnixProcessStats com.sun.cmm.statistics.CMM_VirtualServerWebModuleStats com.sun.cmm.statistics.CMM_WebModuleStats |
The following command shows the observable attributes for threshold jobs that monitor objects of class com.sun.cmm.statistics.CMM_SWRQueueStats found in the previous example:
$ mfwkadm thrsh-job observable-attributes \\ class=com.sun.cmm.statistics.CMM_SWRQueueStats Threshold jobs observable attributes: ==================================== Class: com.sun.cmm.statistics.CMM_SWRQueueStats Attributes: BufferSize [LONG] EntriesCount [LONG] EntriesHighWaterMark [LONG] EntriesLowWaterMark [LONG] EntriesTotal [LONG] ErrorCount [INTEGER] FailedOperations [LONG] LowerLimit [LONG] OperationsCount [LONG] OtherLowerLimit [LONG] OtherUpperLimit [LONG] OverflowsCount [LONG] QueuedCount [LONG] QueuedHighWater [LONG] SampleInterval [LONG] TotalQueuedCount [LONG] UpperLimit [LONG] |
The following command is another example of job creation, here with a threshold job:
$ mfwkadm thrsh-job create myThreshJob granularity=30 \\ object=/wsPrefix/com.sun.cmm.ws:name=process-1-threadPool-NativePool-stats,\\ type=CMM_SWRQueueStats attributeName=EntriesCount attributeType=LONG \\ thresholdValue=1000 thresholdOffset=10 thresholdDirection=RISING |
The following example demonstrates the output of the thrsh-job info subcommand for the threshold monitoring job created in the previous example:
$ mfwkadm thrsh-job info myThreshJob Threshold job information for: myThreshJob ----------------------------- Type: SIMPLE State: ACTIVE_ON_DUTY Granularity period: 30 Schedule: Global start time: Immediately Global stop time: Forever Weekly schedule: Everyday Daily schedule: All day Alarm configuration: Type: QualityOfServiceAlarm Severity: INDETERMINATE Threshold definition(s): Object: /wsPrefix/com.sun.cmm.ws:name=process-1-threadPool- NativePool-stats,type=CMM_SWRQueueStats Attribute: EntriesCount [LONG] Value: 1000 Direction: RISING Offset: 10 |
The following exit values are returned:
Successful completion
An error occurred
Attribute Type |
Attribute Value |
---|---|
Availability |
SUNWmfwk |
Interface Stability |
Contract Private |
cacao.5, cacaoadm.1m