Agent Plugin Facet

SnapshotReportFacet could look like this:

public interface SnapshotReportFacet {
   InputStream getSnapshotReport(String name, String description, Configuration snapshotConfiguration);
}

• "name" allows the caller to uniquely name this particular snapshot (probably something the user can type in at the UI page that will initiate the snapshot) or perhaps it just identifies one kind of snapshot, if a facet implementation can take more than one kind.

• "description" can be provided by the user to help identify this snapshot instance (maybe its the reason why the snapshot was taken such as, "see why the resource is reporting 100% CPU utilization").

• "snapshotConfiguration" tells the component facet what it should snapshot. This is defined in the agent plugin descriptor since each resource will have its own things it will need or be optionally configured to do. For example, the Agent descriptor could have this somewhere separate or (since it will be easier) somewhere in the plugin configuration:

  <c:configuration>
     <c:simple-property name="snapshotConfigEnabled" type="boolean" description="If true, the configuration preferences will also be collected." />
     <c:simple-property name="snapshotDataDirEnabled" type="boolean" description="If true, the contents found in the agent data directory will be collected, including the persisted inventory.dat file and the command spool file"/>
     <c:simple-property name="snapshotLogDirectory" type="file" description="The location of the log files that should be collected. If empty, no logs will be collected. This can be a directory name, in which case all files in that directory will be collected, or it can be an individual file name in which case just that file will be collected" />
  </c:configuration>

  If this will be in the plugin config, there would be no reason to have snapshotConfiguration parameter in the facet method since the component can get its plugin config already.

I originally thought we need a <snapshot-report> element, but I don't think we need to have that. Maybe?

There will need to be a new SnapshotReportManager in the plugin container. It will simply expose its API as a remote POJO API so the server can call it:

public interface SnapshotReportManager {
   InputStream getSnapshotReport(Resource resource, String name, String description, Configuration snapshotConfiguration);
}

The UI for now can be simple - in the Inventory tab we can have a subtab "Snapshot Report" that is shown only if the resource has one or more <snapshot-report> metadata elements (this is one reason we might need to have it - we need to have something in the data model so the server-side knows that it supports this, just like <operation> tells the server it supports the operation facet for example). The UI Inventory>SnapshotReport can look up the plugin descriptor, get the <snapshot-report> config elements for the resource, render the configuration (or just use the plugin configuration), let the user fill in the configuration, hit OK, that gets submitted to an SLSG "SnapshotReportManagerSLSB" which synchronously calls the agent. The server can slurp in the input stream, write the data somewhere (to disk, which won't support HA, or to DB will which) then pass back the location where the file was saved to the UI. Or we could immediately send the data to the UI by streaming it down. Or we can write the file to the rhq-downloads location and pass the URL to the server rhq-downloads page and let the user download it.

Server Side Analysis Plugin

We could optionally provide server-side analysis plugins that can be passed the snapshot report and the server-side plugin could analysis the report and spit out recommendations or findings about that report.