Components of the Application

Does the application have subcomponents for which users might want separate data? Does the application provide the same data about different parts of the application? Define these subcomponents or parts as resources and provide the same statistics for each resource. For example, nscd provides the same set of statistics for resources such as ipnodes, networks, and services. The nscd StatsStore resources are the resources for which nscd provides caching.

For a class that has resources defined, any class-level statistics (statistics that are defined directly on the class) should also be defined on each resource.

Class-level statistics are a useful way to combine data across all resources so that users do not need to apply operations to the SSIDs. For example, for a class that has resources defined, the class-level statistic could be the sum or average of that same statistic for each resource.

The //:class.cpu//:stat.usage class-level statistic shows the total usage of all CPUs in the system, and the //:class.cpu//:res.id/0//:stat.usage resource statistic shows the total usage for one CPU. The value of //:class.cpu//:stat.usage is equal to the value of //:class.cpu//:res.id/*//:stat.usage//:op.sum. The nscd application does not provide any class-level statistics because users do not want to combine all positive hits, for example, for ipnodes, networks, services, and other nscd resources.

Another reason to define resources for your application is to use the resources to provide topology mapping so that users can access the statistics data in different ways.

Do not define resources that are not interesting to users. For example, CPUs are exposed as resources, but DIMMs are not.