Cisco Element Manager System Installation and Configuration Guide, 3.1
Performance Data Storage
Download this chapter
Performance Data StoragePerformance Data Storage
give_us_feedback

Table Of Contents

Performance Data Storage

Attribute Storage Criteria

History Storage Criteria

Defining history storage criteria

History storage criteria file format

Editing History Storage Criteria

Historical Data Exports

Export Format

Administering History Storage

Database Sizing

Example 1

Example 2

Example 3

Scenario 1

Scenario 2


Performance Data Storage

Cisco EMF provides a facility that allows for management of historical data for managed objects. The Attribute History subsystem of the Cisco EMF can maintain a historical record of the value of any attribute against a managed object. This historical data can be graphed by the Performance Manager in response to criteria input by a user. Refer to the Cisco EMF User Guide for information about the Performance Manager application.

The Attribute History subsystem does not poll for the values that are being stored. It is event driven and depends on another source to generate these events, for example an Element Manager. The event contains all information necessary to store data against the managed object being polled. You must ensure that objects and attributes you wish to store information for are being polled from another source, for example an Element Manager.

A user can set up the attribute storage criteria to view performance statistics, this is described in full in the Cisco EMF User Guide. History storage criteria can be set up, refer  to History Storage Criteria.

Caution If files are added to the system it is the administrator's responsibility for removing them, as the packaging system will not remove manually coded files.

Attribute Storage Criteria

The Attribute History subsystem is highly scalable as it uses the databasing pattern that has been applied across Cisco EMF which will allow the database to extend across multiple disks. The database size is only limited by the amount of disk space available. The growth of the database is determined not only by the purge criteria discussed in the section below, but by the summaries defined through the attribute storage criteria.

The Attribute History subsystem automatically purges the oldest data from its database to prevent the database from becoming excessively large. Deleting data may not be desirable so this may be dealt with as follows:

•Use the bulk export facility. This allows historical data to be dumped from the internal database which is optimized for fast access, to a flat file format which is suitable for archiving.

•Store summaries where a summary is data that has been generated over a time period, for example hourly. The data will be generated using one or more of the following summary rules:

–average—computes the average of the attribute values over the summary period

–total—computes the total of the attribute values over the summary period

–peak—determines the highest value over the summary period

–trough—determines the lowest value over the summary period

–logicalOR—generates either 1 or 0. This is typically used for status flags. Some attributes may have only two potential values, for example True or False; Yes or No; 1 or 0. When summaries are generated from values such as these and the "logical OR" rule is used, the summarized value is 1 if any value in the summary interval is 1. If all values in the summary interval are 0, then the summarized value is 0.

History Storage Criteria

History storage criteria allows a system administrator to specify the criteria Cisco EMF uses to store a historical record of attributes' values. Each history storage criteria can be identified by a unique name.

History storage criteria apply to a set of network elements and to a set of attributes on each of those elements. For each attribute on each network element specified in the history storage criteria, Cisco EMF stores and manages a historical record of the attribute's value.

Note If no history storage criteria are specified, no attributes on any objects are monitored.

Cisco EMF Performance Manager provides a facility that allows for management of historical data for managed objects. The Attribute History subsystem of the Cisco EMF framework can maintain a historical record of the value of any attribute against a managed object. This historical data can be graphed by the Performance Manager in response to criteria input by a user.

The Attribute History subsystem does not poll for the values that are being stored. It is event driven and depends on another source to generate these events, for example an Element Manager. The event contains all information necessary to store data against the managed object being polled. You must ensure that objects and attributes you wish to store information for are being polled from another source, for example an Element Manager.

Caution If files are added to the system it is the administrator's responsibility for removing them, as the packaging system will not remove manually coded files. Files set up by the Element Manager developer should not be changed by a system administrator.

Defining history storage criteria

For an object or an attribute to be monitored it must be included in a history storage criteria file. It is recommended that the history storage criteria files are stored in the <CEMF_ROOT>/config/historyCriteria directory.

A history storage criteria file has:

•A unique name

•A set of objects to which the storage criteria applies. This can be a list of objects, or an Object Group.

•A list of attributes on those objects. A history will be kept for these attributes,

•A list of summarizing intervals. This can be empty.

•A list of summarizing rules. This can be empty.

Note The list of summarizing periods and the list of summarizing rules are linked. If one list is empty then the other list will also be empty.

History storage criteria file format

The format for defining the components in a history storage criteria file is as follows: 

STORAGECRITERIA

    STORAGECRITERIANAME    <name>


    <set of objects>


    ATTRIBUTE         <attribute name> <section>

    ATTRIBUTE         <attribute name> <section>


    SUMMARYINTERVAL <period>

    SUMMARYINTERVAL <period>


    SUMMARYRULE <rule>

    SUMMARYRULE <rule>

ENDSTORAGECRITERIA

The <set of objects> component may be either 

    OBJECTGROUP    <object group view path>

or 

    OBJECTGROUP    <group name>

or multiple lines of the following format: 

    OBJECT         <view path>

The <periods> component should be given in seconds, for example 86400 seconds = 1 day, 3600 seconds = 1 hour.

Valid summary rules are total, average, peak, trough, logicalOR, refer to Attribute Storage Criteria.

Examples of history storage criteria are as follows: 

Examples        

STORAGECRITERIA

        STORAGECRITERIANAME            subscriberCriteria1


        # Objects specified by an OG's name. This would typically be the format used

        # The name would correspond with the GROUP_NAME in the performance attributes

        # file for the controller

        OBJECTGROUP        myObjectGroupName


        ATTRIBUTE        PerfMib.subscriberInfo1                            SNMP

        ATTRIBUTE        PerfMib.subscriberInfo2                             SNMP


        # Summary interval of one day (86400 seconds)

        SUMMARYINTERVAL                86400


        SUMMARYRULE            average

        SUMMARYRULE            peak

        SUMMARYRULE            trough


ENDSTORAGECRITERIA                        

STORAGECRITERIA

        STORAGECRITERIANAME            subscriberCriteria2


        # Objects specified by an OG's containment path. The object group must exist 

        # in the containment when loading the storage criteria.

        OBJECTGROUP        ObjectGroups:/myObjectGroup

        ATTRIBUTE        PerfMib.subscriberInfo1                                 SNMP

        ATTRIBUTE        PerfMib.subscriberInfo2                                 SNMP

        ATTRIBUTE        PerfMib.subscriberInfo3                                 SNMP

        ATTRIBUTE        PerfMib.subscriberInfo4                                 SNMP

        ATTRIBUTE        PerfMib.subscriberInfo5                                 SNMP

        ATTRIBUTE        PerfMib.subscriberInfo6                                             
SNMP


        # 86400 seconds = 1 day; 3600 seconds = 1 hour

        SUMMARYINTERVAL                86400

        SUMMARYINTERVAL                3600


        SUMMARYRULE            average

        SUMMARYRULE            peak

        SUMMARYRULE            trough


ENDSTORAGECRITERIA                        


STORAGECRITERIA

        STORAGECRITERIANAME            subscriberCriteria3


        # Objects specified explicitly

        OBJECT        Physical:/Object1

        OBJECT        Physical:/Object2

        OBJECT        Physical:/Object3


        ATTRIBUTE        PerfMib.subscriberInfo1                             SNMP


        # No intervals or rules are specified, so only raw

        # data is stored


ENDSTORAGECRITERIA

Editing History Storage Criteria

Caution The HistoryAdmin facility must be run from the Cisco EMF Server.

To edit history storage criteria:

Step 1 From the command line on the terminal window, type

cd <CEMF_ROOT>/config/historyCriteria

Note When exporting data <CEMF_ROOT> is the Cisco EMF installation root directory (for example /opt/CEMF).

Step 2 Use any editor and create a new history storage criteria file or open and edit an existing history storage criteria file similar to the example History storage criteria file format.

Note You can change the attribute periods and rules when editing history storage criteria but not the object group.

Step 3 When the history storage criteria file is complete, save the file.

Step 4 Type ./cemf shell to get a Cisco EMF shell.

Step 5 Type run <CEMF_ROOT>/bin/historyAdmin add <directory>

or

Type run <CEMF_ROOT>/bin/historyAdmin edit <directory> to update Cisco EMF

Note <directory> is the name of the directory which contains the files you want to add.

The Performance Manager reflects the new or edited history storage criteria and updates which attributes are monitored and then displayed.

Historical Data Exports

The Attribute History Server has an 'export' facility that will export data to an ASCII readable file.

Although data will not be automatically exported to file, there is a utility that will allow for data to be exported to file in bulk, that is, 'historyAdmin export'. Cisco EMF does not provide a framework for scheduling these exports, and therefore it will be the responsibility of the administrator to provide a suitable mechanism, such as, 'cron' - a clock daemon provided by UNIX. However, consider the following when exporting:

•Exports should be done to an external disk as they could be extremely large.

•Administration of the export area should be done. If not, then the export area may become full.

•Exports should be performed at off-peak intervals. Exporting is a costly operation in terms of database access and should be done only when required.

•Ensure a path to exported files exists on the Server.

Export Format

Data will be exported to files with the following format: 

Object:<object path>

Object class:<object path>


Attribute:        <attribute name>

Summary rule:<rule>

Summary interval:        Raw | <summary interval>


<date> <time> <valueType> <value>


Data exported: <current date/time>

•The "Object class" entry is optional.

•The "Summary rule" entry will only be present if the interval is not "Raw".

•Timestamps will be in human readable format.

•Statuses will indicated when polling started or stopped, missed polls, or polled values. Where the status is a 'stopped' or a 'missed' poll, the attribute value will be set to null.

A file can contain data for multiple objects, attributes, summary rules and summary intervals. Fields will be separated by either tab,space or comma.

Example 

> historyAdmin export dumpFile TAB 10 all raw criteria1


Object: exampleView:/site_1/bay_1/agent_1/rack_1/linecard_2/port_2

Object Class: testPort


Attribute: LocalDB:TEST.dtIndex1

Summary interval: Raw



09 Jun 1999 11:50:03                Polled        10

09 Jun 1999 11:50:23                Polled        10

09 Jun 1999 11:50:43                Polled        15

09 Jun 1999 11:51:03                Missed            <no value>

09 Jun 1999 11:51:23                Polled        20

09 Jun 1999 11:51:43                Polled        20

09 Jun 1999 11:52:03                Polled        0

09 Jun 1999 11:52:23                Polled        5

09 Jun 1999 11:52:43                Polled        0

09 Jun 1999 11:53:03                Polled        10

09 Jun 1999 11:53:23                Polled        0

09 Jun 1999 11:53:43                Polled        15

09 Jun 1999 11:54:03                Polled        0

09 Jun 1999 11:54:23                Polled        20

09 Jun 1999 11:54:43                Polled        0

09 Jun 1999 11:55:03                Polled        15

09 Jun 1999 11:55:23                Polled        0

09 Jun 1999 11:55:43                Polled        10

09 Jun 1999 11:56:03                Polled        0

09 Jun 1999 11:56:23                Polled        5

09 Jun 1999 11:56:43                Stopped           <no value>


Data exported: Sun Jun 27 17:17:35 1999

Administering History Storage

A command line facility is provided to perform various operations on Attribute Storage Criteria. It is recommended that the history storage criteria files are stored in the <CEMF_ROOT>/config/historyCriteria directory. From the command line, in the correct directory type historyAdmin help .

Step 1 Type ./cemf shell in the bin directory to get a Cisco EMF shell.

Step 2 The Cisco EMF shell creates paths and environment variables required by every Cisco EMF binary.

Running historyAdmin help gives 

Usage: 

  add [<directory of criteria> | file ]

  edit [<directory of criteria> | file ]

  export <filename> <separator> <max file size(KB)> [all | <number_of_days>] 
[summary|raw] <criteria name> ... 

  get attributes <object path> ...

  get data <no. of values> [raw | <interval> <rule>] <object path> <attribute>

  get purge

  get criteria <criteria name> ...

  help

  list

  remove <criteria name> ...

  set purge <min. values> <max. values> <min. age>


  <separator> :== TAB | SPACE | COMMA

The following commands are available:

•add <file or directory of history storage criteria>—allows an administrator to dynamically add new history storage criteria

•edit <file or directory of history storage criteria>—allows an administrator to dynamically edit existing history storage criteria

•export <filename> <separator> <max file size> [all | <number of days>] <criteria name> ...—This exports data for the given criteria to the given file. The separator can be TAB, SPACE or COMMA, and this specifies how fields in the exported file are separated. The data is split into several files, with the maximum size of each file being specified via the <max file size> option. All data can be exported for the given criteria, or data for the last specified number of days. The export facility is run from the Server.

•get attributes <object path> ...—displays attributes being monitored on specified objects

•get data <no. of values> [raw | <interval> <rule>] <object path> <attribute>—allows a specified number of values to be retrieved, for a given attribute on a given object. Either raw data or summarized data (of a specified interval and rule) can be retrieved.

•get purge—displays the criteria which are used to automatically purge old data

•get criteria <storagecriteria name> ...—displays details of specified history storage criteria

•help—displays the above help

•list—displays all history storage criteria which are currently being used

•remove <storagecriteria name> ...—removes history storage criteria and any historical data which was being stored for them

•set purge <min. values> <max. values> <min. age>—allows the administrator to change the purge criteria

Database Sizing

Understanding how data is stored is extremely important as a badly configured system can lead to unnecessarily large disk requirements. Explanation of how the summaries are generated is detailed in the following examples.

Example 1

Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Daily and monthly summaries are required for upstreamPower using an average summarizing rule.

Summarization occurs when any data of a higher granularity is about to be deleted. In this example, deleting raw data only generates the daily summaries, not the monthly summaries. Monthly summaries are generated when daily summaries are about to be deleted. Data is not purged until summaries which depend on that data can be calculated.

Example 2

Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. A SixMonthly summary is required for upstreamPower using an average summarizing rule.

In this example, raw data is deleted only when there is enough data for the SixMonthly summary. This overrides the 'maxValueCount' parameter discussed above, so the Attribute History Storage will potentially have to store over 19000 values for 10000 managed objects.

Even if SixMonthly summaries are all that is required, collecting weekly summaries would save on disk space.

Example 3

Raw data is collected every 15 minutes on attribute upstreamPower for 10000 cable modems. Data will be purged according to the auto-purging rules specified above.

Estimating the size of one day's stored data will be reflective of the overall disk space required each day. For each summary including raw, the Attribute History Storage will store the last 1000 values of an attribute on an object.

The following figures have been calculated for monitoring 30 attributes on each of 10,000 objects. The value of each attribute is monitored using the "average" summarizing rule at hourly, daily and weekly intervals. Each attribute is polled at 15 minute intervals. All attributeValues are AttrInt32Values. The formula used is:

db size per sample = (no. of objs) x (no. of attrs per obj) x (bytes required if value changes | bytes required if value does not change) x (no. of values collected over time interval) x (4/3 = Overhead of using ObjectStore collections)

Only changes to a value are databased and the size of one value is 24 bytes (includes pointer to value, timestamp and status flag). If a value does not change only 4 bytes are required to store the timestamp.

Scenario 1

If the value of each integer attribute on an object changes every 15 minutes.

Table 14-1 Scenario 1 Calculation

Sample
Calculation
Total

raw

30 x 10000 x 24 x 1000 x 4/3

9.6 GB

hourly

30 x 10000 x 24 x 720 x 4/3

6.9 GB

daily

30 x 10000 x 24 x 30 x 4/3

0.29 GB

weekly

30 x 10000 x 24 x 4 x 4/3

0.04 GB

after 30 days

 

~16.83GB


The total shown for a 30 day interval is only approximate but it serves as an indication of how large the attribute history database can become. The database growth rate applied to the above example will slow down as the purge criteria will limit this growth. After a year, the database size will be approximately 19 Gigabytes and it will grow to a maximum of 31 Gigabytes after 20 years.

A lot of disk space is required in the above example but this is a worst case scenario where the value is always changing against each attribute. The number of monitored attributes against each object contributes greatly to the disk space required so if disk space is an issue be wary of what attributes should be monitored.

The value of 1000 in the table above reflects the maxValueCount referred to earlier.

Scenario 2

A more likely behavior pattern is that two integer attributes per object change value every 15 minutes, the remaining 28 changing only twice per day in the same hour.

Table 14-2 Scenario 2 Calculation

Sample
Calculation
Total

raw

( (28 x 10000 x 4 x 940 x 4/3) + (28 x 10000 x 24 x 60 x 4/3)) +

(2 x10000 x 20 x 1000 x 4/3)

2.6 GB

hourly

((28 x 10000 x 4 x 690 x 4/3) +

(28 x 10000 x 24 x 30 x 4/3)) +

(2 x10000 x 24 x 720 x 4/3)

1.8 GB

daily

30 x 10000 x 24 x 30 x 4/3

0.29 GB

weekly

30 x 10000 x 24 x 4 x 4/3

0.04 GB

after 30 days

 

~4. 7 GB


This is only approximate but the Attribute History Storage can manage the database size much better in this scenario. As it only stores value changes, it is unlikely that the database will ever grow beyond 9 Gigabytes.