Analyzer Customizing
Customizing for N1 AA Analyzer
Administration ⇒ Analyzer ⇒ Customizing
All changes are optional
The entries with the naming convention servergroup.analyzer.constants.constantname are passed to the MDX Queries. Where servergroup is a placeholder for none or an existing server group, and constantname is a placeholder for any name you choose.
The predefined constants delivered along with N1 AA are described in N1 AA Analyzer: Server Group Utilization.
You may add entries here, if you need them for your own MDX Queries. For more information, see Views.
N1 AA Analyzer specific customizing is done here. The following parameters are supported:
Table 3–1 Analyzer Parameters
Parameter |
Description |
Example value |
---|---|---|
none.analyzer.n1data.maxsizemb |
Maximum size of the local Performance Collector file in MB. This file, /var/opt/SUNWn1aa/n1data, exists on every N1 AA client. The data import job reorganizes this file if it exceeds the customized size (log rotation). The parameter none.analyzer.n1data.maxsizemb is server group spanning valid. This means that the value is set for all server groups.If the parameter servergroup.analyzer.n1data.maxsizemb exists, it overwrites the parameter none... within this specific server group. |
5 |
Import resource consumption data collected by the Performance Collector on the N1 AA Clients into the database
Administration ⇒ Scheduling
Optional - but recommended
Even if you can trigger a data import into the database manually, see Maintenance, it is easier to schedule a regular data import job in the background. To do this, create an N1 AA scheduling job by using the following properties:
Name = AnalyseDataImportJob
Use this exact name.
Class = com.sun.web.admin.n1aa.analyzer.AnalyseDataImportJob
Persistence = Persistent
Start = Enter the date and time this job is to be first executed.
Interval = Recommended value: 86400 (daily import).
The data import is executed for each physical host that has the Data Import option enabled, regardless of the server group. For more information, see Customizing. Note that within this execution, existing repository information is assigned properly, while new repository information is automatically created using default properties which you have to maintain. Refer to the following table:
Table 3–2 Repository Information
New repository information |
Behavior |
Default properties |
---|---|---|
New CPU type name or speed |
A new CPU type is being created. See CPU Types. |
Normfactor = 1.0 |
New SRM project |
A new component is being created. See Applications and Components. |
Name = SRM project Application = None |
Reorganization of resource consumption data
Administration ⇒ Scheduling
Optional - but recommended
Having too much informations in the N1 AA Analyzer cube (historical resource consumption data) slows down response times. Therefore, old data can be moved to an archive table contained in the N1 AA database, see Maintenance. It is your choice if this should be done periodically without user interaction. All you have to do is create an N1 AA scheduling job using the following properties:
Name = ArchiveUnarchiveJob
Class = com.sun.web.admin.n1aa.analyzer.ArchiveUnarchiveJob
Parameter = a "timestamp '-infinity'" "timestamp without time zone 'now' - interval '12 month'"
Use this exact string beginning with the character a. This means, that all data that is older than 12 months is archived. You may change the period of 12 months to a shorter value, for example 6 months, if your data growth is very high.
Persistence = Persistent
Start = Enter the date and time this job is to be first executed
Interval = Recommend 86400 (daily reorganization)
Maintain CPU normalization factors.
Administration ⇒ Analyzer ⇒ Customizing
Mandatory - but can be done or changed at any time later on.
The CPU types are automatically recognized in your landscape and corresponding entries are automatically created for each new CPU type as performance data is imported. Normally, there is no need to create or delete an entry manually. However, it is important to maintain the proper CPU normalization factor after a new entry was created automatically.
CPU type: Type of the CPU as recognized and applied by the N1 AA Analyzer.
Normfactor: New entries created automatically by the N1 AA Analyzer data import job have the default value of 1.0. Adjust this value to reflect the relative CPU throughput as compared to the existing CPUs in your landscape.
The outcome of normalization is that N1 AA stores all measured CPU utilization. Based on the Normfactor of the CPU type, N1 AA calculates and also stores normalized CPU seconds. In the simplest case, this is consumed seconds * Normfactor. In this way, MDX queries can be defined based on CPU seconds or normalized CPU seconds. See the predefined MDX Queries as an example of how to use either CPU seconds or normalized CPU seconds.
Exercise care when deleting CPU types. You lose all related resource consumption data that has been collected by the Performance Collector on the N1 AA Clients and imported into the database.
Maintain applications in your N1 AA Analyzer landscape
Administration ⇒ Analyzer ⇒ Customizing
Mandatory - but can be done or changed at any time
Maintain the applications of your landscape. An application is a group of components measured by the N1 AA Analyzer, see Components.
For example, the SAP system D01 is maintained here as the application SAP-D01. Later, you assign measured components to the application SAP-D01: An oracle database, an SAP central instance, and one or more SAP application servers.
The assignment of components to applications has an impact on how your MDX queries work. This impact is because each of them is based on the component/application model. For more information, see Views.
Be careful when deleting an application. You lose all subsequent components and all related resource consumption data that have been collected by the Performance Collector on the N1 AA Clients and imported into the database. In order to keep these components, assign them to another application.
Maintain components of your N1 AA Analyzer landscape.
Administration ⇒ Analyzer ⇒ Customizing
Mandatory - but can be done or changed at any time
Components are automatically recognized as running SRM projects in your landscape. Corresponding entries are created for each new component as performance data is imported. Normally, there is no need to create or delete an entry manually. It is important to maintain the following properties:
Component: Name of the component, that is displayed in the GUI. The default name, as generated automatically by the data import job, is identical to the SRM project name. You are free to create meaningful names. For example, SAP-D01-CI for the central instance of the SAP system D01.
Application: New components, as generated by the data import job, are assigned to the default application None. Assign the component to an existing application. For example, assign the component SAP-D01-CI to the application SAP-D01.
SRM Project: This is the SRM project name that was measured. It is assumed, that the component is always started and running in this SRM Project. You do not have to modify this project, as long as this reflects reality.
You are free to assign and reassign components to applications in any way. However, the assignment does have an impact on how your MDX queries work. This is because each of them is based on the component/application model. For more information, see Views.
Best Practice
Components that are unique in your landscape. For example, the central instance of SAP system D01.
Start them in a dedicated, landscape-wide unique, SRM-project. In this way, you measure the resource consumption of this component of the landscape separately because SRM-project = component.
Assign the component to an application other than None.
Components according to the default SRM projects: system, default, and user.root. You can always find these components because the default SRM projects are always running.
Assign them to the application None.
Additional server-bound system components. For example, a BMC Patrol Agent.
Default behavior: The load is included in one of the default SRM projects. Therefore, no additional component is be available.
If you would like to measure the load separately, start those components in a dedicated project but let the new component be assigned to the application None.
Deleting a component erases all related resource consumption data that has been collected by the Performance Collector on the N1 AA Clients and imported into the database.