This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.
This ZenPack provides support for monitoring the Cisco Application Centric Infrastructure (ACI) via the Cisco Application Policy Infrastructure Controller (APIC).
Released: 2020-07-02 Compatible with Zenoss 4.2.5 - 6.5.0, Zenoss Cloud Requires: PythonCollector ZenPack
This ZenPack adds the following features to Zenoss.
The following components will be automatically discovered through a controller (APIC).
The following datapoints will be collected every 5 minutes by default. The individual health scores can be configured to collect at a different interval using the zCiscoAPICHealthInterval configuration property. All other statistics are pre-aggregated to 5 minute intervals by the APIC, so collecting on a different interval would lead to inaccurate results. For this reason the collection interval for all other statistics cannot be changed in Zenoss.
Zenoss periodically polls the APIC for faults and creates Zenoss events when they occur. The APIC fault life-cycle closely matches that of a Zenoss event. This means that corresponding Zenoss events will automatically clear when their APIC fault counterparts clear.
Note: APIC fault events may reoccur in Zenoss if they're close in Zenoss, but not cleared on the APIC. For this reason it is recommended that the APIC fault events be acknowledged in Zenoss instead of closed until they are actually resolved on the APIC.
Note: Zenoss attempts to set the timestamp on fault events to the timestamp the APIC reported their occurrence instead of the time that Zenoss collected them. For this reason it is recommended that both your APICs and Zenoss servers keep accurate time. Zenoss will attempt to determine any time difference between the Zenoss collector server and the APIC and adjust event timestamps accordingly.
The following fields will be populated for each event.
The following additional fields and potentially more will also be populated for each event. These are the fields native to an APIC fault. If a fault occurs that has other fields, those fields will be added with the same cisco.apic prefix.
When combined with Zenoss Service Dynamics, this ZenPack adds built-in service impact and root cause analysis capabilities for services running on the ACI fabric. The service impact relationships shown in the diagram and described below are automatically added and maintained. These will be included in any services that contain one or more of the discovered components listed above.
Most of the impacts described above follow the default policy of a node being in the worst state of the nodes that impact it. For example, a single controller fabric node failure will imply that all controlled switches are failed. In cases like these the default policy is not appropriate and a custom policy will be used instead.
Use the following steps to start monitoring an APIC using the Zenoss web interface.
Alternatively you can use zenbatchload to add APICs from the command line. To do this, you must create a file with contents similar to the following. Replace all values in angle brackets with your values minus the brackets. Multiple APICs can be added under the same /Devices/Network/Cisco APIC section.
my-apic setManageIp='192.0.2.77', zCiscoAPICUsername='admin', zCiscoAPICPassword='changeme'
You can then load the endpoint(s) with the following command.
When adding an APIC to Zenoss, you must enter a Hostname or IP Address. This address must be of one of the controller nodes for a fabric. You should not add each controller node as a separate device in Zenoss. Zenoss manages the entire cluster through one controller node at a time. Adding multiple controller nodes in the same cluster will result in Zenoss performing double or even triple monitoring of the same data.
Zenoss will automatically discover both the in-band and out-of-band management addresses for each controller node in the cluster on an ongoing basis. If at any point Zenoss is unable to communicate with a controller node, it will round-robin through the other controller nodes until it finds one that's reachable. Monitoring will continue through a functioning controller node. This allows Zenoss to provide uninterrupted monitoring of the fabric when individual controllers are taken offline for maintenance, or go offline for other reasons.
It is important to configure Zenoss appropriately to use the correct management address(es) for your APIC cluster. This is done by configuring the zCiscoAPICMgmtInterface property. The following options are available.
Choosing out-of-band will cause Zenoss to use the configured out-of-band (OOB) management addresses. In-band will cause Zenoss to use the in-band management addresses. Choosing static will result in Zenoss only using the provided address to manage the cluster and means that no failover to other controller nodes is possible. Static should only be used in situations where Zenoss is accessing a controller node through NAT and wouldn't be able to access the other controller nodes via their out-of-band or in-band management addresses.
The username and password provided when adding an APIC to Zenoss must have the admin role for Zenoss to successfully model and monitor the fabric. It is acceptable to use an admin read-only role as Zenoss never performs writes.
To grant the user admin read-only permissions you must configure the user in the APIC portal to have both role admin and role read-only. If your APIC has a single role labeled read-only admin it will not work.
The current release is known to have the following limitations.
Installing this ZenPack will add the following items to your Zenoss system.
This ZenPack provides additional support for Zenoss Analytics. Perform the following steps to install extra reporting resources into Zenoss Analytics after installing the ZenPack.
You can now navigate back to the Cisco APIC ZenPack folder in the repository to see the following resources added by the bundle.
Topics can be used to create ad hoc views using the following steps. Topics are a layer on top of domains that are more focused on a certain type of data.
Domains can also be used to create ad hoc views using the following steps.