The <sample-period> element sets the sample period for the Harvester, in milliseconds. For example:

    <sample-period>5000</sample-period>

The sample period specifies the time between each cycle. For example, if the Harvester begins execution at time T, and the sample period is I, then the next harvest cycle begins at T+I. If a cycle takes A seconds to complete and if A exceeds I, then the next cycle begins at T+A. If this occurs, the Harvester tries to start the next cycle sooner, to ensure that the average interval is I.

One or more <harvested-type> elements determine the types of data to harvest. Each <harvested-type> element specifies an MBean type from which metrics are to be collected. Optional sub-elements specify the instances and/or attributes to be collected for that type. Set these options as follows:

• The optional <harvested-instance> element specifies that metrics are to be collected only from the listed instances of the specified type. In general, an instance is specified by providing its JMX ObjectName in JMX canonical form. However, you can use pattern-matching to specify instance names in non-canonical form, as described in Using Wildcards in Harvester Instance Names.

• If no <harvested-instance> is present, all instances that are present at the time of each harvest cycle are collected.

• The optional <harvested-attribute> element specifies that metrics are to be collected only for the listed attributes of the specified type. An attribute is specified by providing its name. The first character should be capitalized. For example, an attribute defined with getter method getFoo() is named Foo.

  The <harvested-attribute> element also supports an expression syntax for "drilling down" into attributes that are complex or aggregate objects, such as lists, maps, simple POJOs (Plain Old Java Objects), and various nestings of these types. See Specifying Complex and Nested Harvester Attributes, for details on this syntax. However, note that the result of these expressions must be a simple intrinsic type (int, boolean, String, and so on) in order to be harvested.

• If no <harvested-attribute> is present, all harvestable attributes defined for the type are collected.

• Attribute and instance lists can be combined in a type.

The Harvester supports WebLogic Server MBeans and custom MBeans. WebLogic Server MBeans are those that come packaged as part of the WebLogic Server. Custom MBeans can be harvested as long as they are registered in the local runtime MBean server.

There is a difference in how WebLogic Server and customer types are specified. For WebLogic Server types, the type name is the name of the Java interface that defines the MBean. For example, the server runtime MBean's type name is weblogic.management.runtime.ServerRuntimeMBean.

For custom MBeans, the Harvester follows these rules:

• If the MBean is not a ModelMBean, the type name is the implementing class name. (See Example 8-1.)

• If the MBean is a ModelMBean, the type name is the value of the MBean Descriptor field DiagnosticTypeName.

If neither of these conditions is satisfied (if the MBean is a ModelMBean and there is no value for the MBean Descriptor field DiagnosticTypeName) then the MBean cannot be harvested.

The <harvested-type> element supports a <namespace> attribute that lets you harvest metrics from MBeans registered in the Domain Runtime MBean Server. However, Oracle recommends that you limit the usage to harvesting only Domain Runtime-specific MBeans, such as the ServerLifeCycleRuntimeMBean. Harvesting of remote managed server MBeans through the Domain Runtime MBean Server is possible, but is discouraged for performance reasons. It is a best practice to use the resident Harvester in each managed server to capture metrics related to that managed server instance.

The <namespace> attribute can have one of two values:

• ServerRuntime

• DomainRuntime

If the <namespace> attribute is omitted, it defaults to ServerRuntime.

WLDF attempts to validate configuration as soon as possible. Most configuration is validated at system startup and whenever a dynamic change is committed. However, due to limitations in JMX, custom MBeans cannot be validated until instances of those MBeans have been registered in the MBean server.

In Example 8-2, the <harvested-type> element in the DIAG_MODULE.xml configuration file specifies that the ServerRuntimeMBean is to be harvested. Because no <harvested-instance> subelement is present, all instances of the type will be collected. However, because there is always only one instance of the server runtime MBean, there is no need to provide a specific list of instances. And because there are no <harvested-attribute> subelements present, all available attributes of the MBean are harvested for each of the two instances.

    <harvested-type>
      <name>weblogic.management.runtime.ServerRuntimeMBean</name>
    </harvested-type>

    <harvested-type>
      <name>weblogic.management.runtime.WLDFHarvesterRuntimeMBean</name>
        <harvested-attribute>TotalSamplingTime</harvested-attribute>
        <harvested-attribute>CurrentSnapshotElapsedTime
        </harvested-attribute>
    </harvested-type>

    <harvested-type>
      <name>myMBeans.MySimpleStandard</name>
      <harvested-instance>myCustomDomain:Name=myCustomMBean1
      </harvested-instance>
      <harvested-instance>myCustomDomain:Name=myCustomMBean2
      </harvested-instance>
    </harvested-type>

    <harvested-type>
     <name>weblogic.management.runtime.ServerLifeCycleRuntimeMBean</name>
     <namespace>DomainRuntime</namespace>
     <known-type>true</known-type>
     <harvested-attribute>StateVal</harvested-attribute>
    </harvested-type>