Monitor Policy

The monitor policy, acitoolkit.acitoolkit.MonitorPolicy, defines what statistical information is gathered and how long historical information is kept. It is also where events that are triggered by these stats are configured (to be supported).

Multiple monitoring policies can be defined and various APIC objects then reference the monitoring policy they are using. For example, a l1PhysIf object in the APIC has an attribute called monPolDn which is the distinguishing name of the monitoring policy that it references. In the toolkit, the l1PhysIf object is represented by the acitoolkit.acitoolkit.Interface class.

There are two types of monitoring policies:fabric and access and they are identified by the policyType attribute of the monitor policy. The fabric type is used to monitor ACI fabric interfaces while the access type is used to monitor ACI access or infra interfaces. The same class is used for both types of monitoring policies in the acitoolkit.

The monitoring policy is a hierarchical policy consisting of monitor policy class, acitoolkit.acitoolkit.MonitorPolicy, at the top with the following classes below it: acitoolkit.acitoolkit.MonitorTarget, acitoolkit.acitoolkit.MonitorStats, and acitoolkit.acitoolkit.CollectionPolicy.

The following diagram shows their relationship.

_images/monitorpolicyhier.png

CollectionPolicy is where the actual collection policy is defined. What it applies to is determined by where it is in the monitoring policy hierarchy. The three most important attributes of the collection policy are adminState, granularity and retention. Additional attributes are a name and description which are optional and can be set using the setName(<name>) and setDescription(<description>) methods respectively.

The adminState attribute can be enabled, disabled or inherited. If enabled, that granularity of statistics will be gathered. If disabled, that granularity of statistics will not be gathered and neither will any larger granularities. This is because the statistics gathered at one granularity are then rolled up into the larger granularity. If you don’t gather the finer one, then there is no data to roll up to the coarser one.

If the adminState is set to inherited, the current object does not determine the adminState. Instead, the adminState of the collection policy of the next higher level in the monitoring policy hierarchy will be used. This means that the adminState at the highest level of the monitoring policy cannot be set to inherited because there is no higher level to inherit from.

The granularity attribute can have one of the following values:

Value Meaning
5min 5 minutes
15min 15 minutes
1h 1 hour
1d 1 day
1w 1 week
1mo 1 month
1qtr 1 quarter
1year 1 year

This is the time interval over which the stats are initially gathered and the interval for which they are kept.

For example, if the granularity is 15min, then the cumulative stats for that granularity will start at 0 at the beginning of the 15 minute interval and will accumulate during the interval. At the end of the interval, the final values will be moved to the historical statistics if the retention attribute is so configured. The rate statistics will be the rate during the 15 minute interval and the rate averages will be the average rate during the 15 minute interval.

Statistics are only kept for granularities that have an adminState of enabled either explicitly or through inheritance and no finer (smaller) granularities are disabled.

The retention attribute determines how long historical data at a given granularity is kept. It can have one of the following values:

Value Meaning
none Do not keep historical data
inherited Use the policy from the next higher level of hierarchy
5min 5 minutes
15min 15 minutes
1h 1 hour
1d 1 day
1w 1 week
10d 10 days
1mo 1 month
1qtr 1 quarter
1year 1 year
2year 2 years
3year 3 years

It does not make any sense to have a retention period that is less than the granularity, however this is not checked for in the acitoolkit.

MonitorStats sets the scope for any collection policy under it. The scope here is a family of statistics. The possible scope values are as follows:

Value Description
egrBytes Egress bytes
egrPkts Egress packets
egrTotal Egress total
egrDropPkts Egress drop packets
ingrBytes Ingress bytes
ingrPkts Ingress packets
ingrTotal Ingress total
ingrDropPkts Ingress drop packets
ingrUnkBytes Ingress unknown bytes
ingrUnkPkts Ingress unknown packets

A more detailed description of the statistics can be found here.

The collection policies under the MonitorStats object determine the default collection policy for the set of statistics selected by the above scope.

Other attributes of the MonitorStats class are name and description which can be set with the setName(<name>) and setDescription(<description>) methods respectively. Setting these attributes is optional.

MonitorTarget sets the scope to a particular APIC target object for all of the collections policies below it. Currently, there is only one APIC target object type supported and that is ‘l1PhysIf’. The scope attribute is where the target type is stored. Support for additional target objects will be added as required. The scope attributed is initialized when the MonitorTarget is created and cannot be changed.

Other attributes of the MonitorStats class are name and description which can be set with the setName(<name>) and setDescription(<description>) methods respectively. Setting these attributes is optional.

MonitorPolicy is the root of the monitor policy hierarchy. This object must have name and policyType attribute. The policyType must be either fabric or access and the name must be unique for each policyType.

The monitor policy will be referenced by its policyType and name by individual APIC objects.

The monitor policy contains the default collection policies as well as any MonitorTarget objects that specify a more specific scope.

The monitor policy must contain a CollectionPolicy for each granularity and the adminState and retention attributes of the CollectionPolicy cannot be inherited because they are at the top of the inheritance tree. When a MonitorPolicy object is created, it will be initialized with the appropriate CollectionPolicy objects, which, in turn, will be set to a default administrative state of disabled. This means that these polies must be overwritten if stats should be collected. They can either be explicitly replaced with the add_collection_policy(<CollectionPolicy object>) method, or implicitly replaced by more specific collection policies in the inheritance hierarchy.

Policy Resolution

The ultimate policy that is applied to any counter is determined by walking through the monitoring policy from the top down. The collection policy at each level of the hierarchy determines how statistics will be kept for those statistics that are in scope.

For example, the collection policy for each granularity is specified at the top of the hierarchy under the MonitorPolicy object. These collection policies will apply to all statistics unless overwritten by a more specific policy under a MonitorTarget object.

If there is a MonitorTarget object, it will set the scope for the monitoring policy to be more specific for the collection policies under it. Initially, the only target supported is ‘l1PhyIf’ which is for an Interface object. Any collection policies under this MonitorTarget will override the corresponding collection policy under the MonitorPolicy parent object. It is possible that there are no collection policies specified at this level.

If there are MonitorStats objects under the MonitorTarget object, they will set the scope to be even more specific for the collection policies under them. Each MonitorStats object can have under it collection policies for any of the granularities.