17. 09. 2021 Attilio Broglio NetEye, Unified Monitoring

Monitor Cisco APIC (Application Policy Infrastructure Controller) in NetEye 4

Introduction

The Cisco APIC is the main architectural component of Cisco ACI. It’s the unified point of automation and management for the Cisco ACI fabric, policy enforcement, and health monitoring, and it optimizes performance and agility. In this article we’ll integrate this solution into the NetEye platform using a simple and customizable approach

Solution

The main components of this NetEye plugin are:

Command
- (Script) check_APIC.py
Service Template
- (Active) generic-active-apic-service
- (Passive) generic-passive-apic-service
Service Set
- APIC Passive Service Set
Host Template
- generic-apic-host

The solution we describe is built on a python script named “check_APIC.py” developed here at Würth Phoenix. It communicates with the Cisco APIC API based on the API definition /api/node/class/faultSummary.json. A call to this URL returns information about the faults collected by APIC.

A typical response looks like the one shown here:

{
	"totalCount": "2",
	"imdata": [{
		"faultSummary": {
			"attributes": {
				"cause": "cause1",
				"childAction": "",
				"code": "F0001",
				"count": "1",
				"descr": "Description1",
				"dn": "fltcode-F0001",
				"domain": "external",
				"nonAcked": "1",
				"nonDelegated": "1",
				"nonDelegatedAndNonAcked": "1",
				"rule": "rule1",
				"severity": "warning",
				"status": "",
				"subject": "smart-licensing",
				"type": "config"
			}
		}
	}, {
		"faultSummary": {
			"attributes": {
				"cause": "cause2",
				"childAction": "",
				"code": " F0002",
				"count": "1",
				"descr": "Decription2",
				"dn": " fltcode-F0002",
				"domain": "infra",
				"nonAcked": "1",
				"nonDelegated": "1",
				"nonDelegatedAndNonAcked": "1",
				"rule": "rule2",
				"severity": "warning",
				"status": "",
				"subject": "relation-resolution",
				"type": "config"
			}
		}
	}]
}

Each entity has 3 fields (domain, severity, and nonDelegatedAndNonAcked) that are used to group the alarm information. In this example we have two faults that are:

not delegated: nonDelegated
not acknowledged: nonAcknowledged

where these faults are relative to different domains:

external
infra

The script correlates the information obtained from the API with the corresponding services in NetEye (i.e., services for external and infra warnings). In order to make this work in NetEye we created a specific command “check_apic”:

Command definition for the check_apic.py script

This command accepts some arguments for dynamically configuring the script:

This command is then configured inside the service template for an active check “generic-active-apic-service” and defined with these 4 fields.

Definition of an ad-hoc template for the passive service

Definition of the fields for the passive service

Then we create a Service Set “APIC Service Set” where we insert all these passive services like external_warning, external_critical etc..

Definition of a passive service inside the service set

At this point the active service and the “service set” can be added to a host template or to a host:

Example of services enabled on the target host

Conclusion

Thanks to the python script and this NetEye configuration, APIC entities can be easily monitored. The final results for the generic APIC services appear like this:

Moreover, if the user needs to group the information about several domains (i.e., access and infra) into just one, this can be done by creating a “new” domain group passive service, i.e. “aggregated_a_i”:

aggregated_a_i_critical
aggregated_a_i_major
aggregated_a_i_minor
aggregated_a_i_warning

then adding it to the list of APIC domains:

and finally modifying the hardcoded list of DOMAINS present in the python script.

DOMAINS= {
  "access"		: ["access"],
  "external"		: ["external"],
  "framework"		: ["framework"],
  "infra"		: ["infra"],
  "management"		: ["management"],
  "security"		: ["security"],
  "tenant"		: ["tenant"],
  "aggregated_a_i "	: ["access","infra"]
}