Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features

From: "Shailaja Yadawad" <[email-masked]>
Date: Fri, 13 Feb 2004 08:50:42 -0700

Hi All,
 
At the moment a group of us are working on a draft-00-. The work is
about object definition for configuring and controlling the periodic
statistical sampling of user specified Data (ASN.1 INTEGER). As you
might be aware that usr history group of RMON2 (RFC2021) does address
this kind of requirement. Our proposed framework apart from containing
the mechanisms seen in the alarm and usr history groups of RMON2
contains also the additional features and functionality. In order to get
the ideas and inputs from congenial minds on the features that we are
working, a brief description of features is being posted in this WG.
Please do share your comments, inputs, additional features etc.
Thanks,Shailaja.  Discussion: Suppose if the user needs to collect
history for all the instances of a columnar object say e.g., on the
interface related statistics (ifTable of MIB-II) like packets sent for
all the interfaces by using the usrHistory group object definition, the
user is required to carry out configuration for each instance
separately. The usr History group does not provide a single point of
configuration for all the instances of the columnar objects.   It has to
be noted that there are some special requirements that arise because of
the above such condition. Following features address some such special
requirements. Features: (a) Goal: Simple configuration and Instance
Management: Objective: It must be possible to configure and control the
history collection for all the instances of the columnar object in a
simple way.   The OID of a columnar object variable consists of two
parts: a columnar OID and an index. Usually, the index part of the OID
is defined by implementers of the MIB or is dependent on the specific
type of the parameter that is being monitored. Hence it can have
arbitrary values. Also, these indices can vary from machine to machine.
For example, the index of the ifTable is a column called ifIndex. The
value of this ifIndex is not pre-determined and can be any arbitrary
integer value. It is difficult for a user to determine the complete OID
for such parameter.  There is another problem that arises vis-a-vis the
history collection of columnar variables. The numbers of instances for
these parameters are not fixed. This means that there could be new
instances that are added or existing ones removed, as per the dynamic
behavior of the system being monitored. For example, new interfaces
added to the system could result in new rows in the ifTable. Interfaces
removed would result in the deletion of existing rows. It becomes
difficult if an user needs to keep track of these additions and
deletions and make sure that the history collection configuration
reflects these changes.  A simple resolution to these kind of
requirement being providing the capability to the user to define only
the columnar part of the OID and allow the implementing application to
find all the instances of the table automatically. At the same time,
this would also allow the agent to keep track of additions and deletions
that occur as stated above. (b) Consistent reference to the resource: It
must be possible to track changing instances and automatically adjust
the history collection. Normally, the index part of columnar variables
maps to an instance of the system resource being monitored. However, if
the resource being monitored changes, it could result in a change to the
index part of the columnar variables also. As it is again left to
implementation what the index part is, there is no guarantee that an
index is mapped to the same instance of the system resource always.  For
example, consider the hrSWRunTable table in the Host resourcesMIB. The
index of this table is again an integer valued variable called
hrSWRunIndex. The HTTP server process might initially be associated with
index 7219. However, if it is restarted, it could get the index 9029.
Also, it is likely that a row with index 7219 might actually represent a
new process like notepad.exe.  If some columnar variable related to the
above table need statistical sampling, it cannot rely just on the OID of
that variable. It may result in the data not being collected for the
instance even if it is actually available. Or worse, it may collect
incorrect data assuming that the OID still represents the same instance.
It is also very difficult for an user to keep these synchronized.
Strictly speaking, this problem should not arise if the indices of
tables are defined and implemented in such a way that their mapping to
the underlying resource is ensured to be always unique. However, it is
observed in practice that indices of tables are usually just integer
valued numbers. It is also observed that there would be other columns in
the table which identify the resources in a more permanent manner. For
example, in the case of the hrSWRunTable, the name of the software could
serve as a good identifier. This problem is addressed by introducing a
concept of 'Identifier Object'. The Identifier Objects are one or more
Columnar Objects that will serve to uniquely identify one instance among
several ones of selected columnar objects. The MIB definition allows the
user to associate Identifier Objects to the columnar Object being
sampled. By doing so, it is now left to the monitoring application to
make sure that data is being collected for the right resource even if it
changes with time. (c) Instance Filtering: It must be possible to
selectively collect history on certain instances of a columnar object.
Sometimes, the user may not be interested in all the instances of a
given table. In such a case, usr can specify the OIDs of the specific
instances of interest. However, as described in the above points,
specifying the complete OID will again have a problem if there is a
change to the index part of such instances.  For example, consider again
the hrSWRunTable in the Host resources MIB. This would include all
processes running on the system. However the user might be interested in
monitoring only certain important processes like a HTTP server or other
major services.  The current draft allows the user to define filter
criteria specifying the instances to be monitored. The monitoring
application can now ensure that instances satisfying these criteria can
be monitored. Combined with the other points mentioned above, this would
handle cases where instances satisfying the criteria get added, removed
or modified. (d) Threshold Monitoring: Combining the aspect of threshold
monitoring with history collection: In addition to the above
considerations, the current object definition also tries to combine the
functionality of threshold-based monitoring with the history collection
functionality. It allows the user to define thresholds on the data being
monitored. Any violation of the threshold would result in a trap being
generated.