Community
Participate
Working Groups
The perfmon user interface currently allows the user to select which resource counters (ie. %CPU_Time for the NT Processor) to monitor. There is a need to have an external API that returns a list of all the available counters (ie. % CPU Time) on a given windows machine. For the API call, we can provide the authentication information (username and password) and a windows host name, and we expect to get a list of these counters in return. The returned list should preserve a hierarchy, similar to the screenshot shown - a tree structure may be appropriate. This way when the data set is iterated through it is easy to know that the %CPU Time counter belongs to the NT Processor group. I suspect there is internal code that already has this functionality, however, an external Java API is required.
Created attachment 30821 [details] Counter selection We want a list back that is similar to the one in the UI. However, we should be receiving an exhaustive list (that is with all the counters and their children). We should not have to make a request for the child counters of any counter group (say NT Processor), the list returned should contain them.
update component
Raising priority to P1 for consuming IBM product, after discussing with Eric Labadie. (Submitter didn't have permissions to set priority.)
This is a duplicate of the combination of the Agent Variable Interface (bug 78498) and the Choreographable Agent Control Interface (bug 78500), which together provide generic but agent type specific programmatic APIs. It is also dependant on the Perfmon Agent being ported to the new Agent Controller. *** This bug has been marked as a duplicate of 78500 ***
The defect 78500 seems to be a generic interface for all agent control, however, this defect is specific to Windows Performance Monitor. Hence, this is a specific request and it should not be assumed that this capability will be present in the generic agent control. The defect 78500 seems very vague for us to even gauge if this capability is even in the scope of what is very briefly discussed in the defect. In addition, we should clarify that the list of counters that are returned are to be persisted into the TPTP Statistical Model and we should be given some feedback to know where to read the persisted information from (ie. from which node in the model). For the sake of tracking this specific requirement, and due to the incompleteness of 78500, this defect is now re-opened.
This defect may be specific to the perfmon agent but it would be wrong and a hack to produce a public (and therefore maintained) API for just the perfmon agent. The correct way to solve this is to produce an agent wide generic control API (enhancement 78498) and then to build common aspects of that API for aspects which are common among certain classes of agent (enhancement 78500). If the perfmon agent were ported to the new agent controller and provided a publicly accessible agent control API then by definition it would have at least have controls to fetch the tree and to turn on and off monitoring of perfmon counters. These controls would either represent the remote perfmon API tree structure on their own or the returned statistical model (fetched via the controls) would represent the tree structure. Listeners could be attached to the statistical model to listen for newly created model structures (note that this part is already possible). *** This bug has been marked as a duplicate of 78500 ***
cls
