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.
The CiscoUCS ZenPack provides monitoring of Cisco Unified Computing System (UCS) devices. This includes UCS modeling, monitoring, and capacity services.
This ZenPack provides monitoring services for Cisco Unified Computing Systems(UCS). UCS Manager, UCS-Mini, stand-alone C-Series rack-mount servers and E-Series servers are supported.
This ZenPack provides support for Cisco UCS Manager Platform and Cisco Integrated Management Controller (CIMC). In general the following features are provided:
UCS Manager monitoring data is collected using the UCS Manager XML API. When adding a UCS Manager to Zenoss it is important to provide the shared virtual IP address of your UCS domain's fabric interconnects. This allows Zenoss to continue monitoring when one fabric interconnect is undergoing maintenance or fails. Your Zenoss collector must be able to connect to the UCS Manager application on port 443/tcp.
Additional capacity features:
The following components will be automatically discovered through the Cisco UCS Manager host, user and password you provide. The properties and relationships will be periodically remodeled to provide automatically up-to-date monitoring when the system configuration changes.
The following metrics will be collected according to the statistics reporting interval, zCiscoUCSManagerPerfInterval.
Zenoss will create events for all UCS faults collected through the management API. The UCS fault life-cycle closely matches that of the Zenoss event life-cycle. When a UCS fault clears, the equivalent events will be cleared in Zenoss.
Upon initially connecting to the UCS Manager Zenoss will process the full list of open faults. Subsequently it will subscribe to and only receive new faults and updates to existing faults. Initial connections to UCS Manager can occur on a restart of UCS Manager, Zenoss or after a temporary connectivity issue between the two is resolved.
The following fields will be populated for each event.
The CiscoUCS ZenPack adds portlets that provide an at-a-glance view into specific areas of the UCS Domain. Portlets are viewed on the first page upon login. Portlets can be added or removed using the dashboard and portlet controls.
The Topology View provides a high-level, architectural view of UCS domains and their physical network connections. The view displays how infrastructure in the UCS Domain is integrated. The view is scalable and exportable to a .png file. Additionally, clicking on a node or edge shows a more detailed view of the associating nodes/edges, events generated and dependency view.
The Bandwidth Usage View provides the bandwidth usage information of resources in the UCS server level and network level of a particular domain, and projected exhaustion date ranges for the following metrics:
The Dependency View is a feature added to the Dynamic Service View ZenPack.
The Dependency View shows you the resources that are dependent on device, as well as the resources that the device depends upon. There are several places where you can see the Dependency view:
When the Dynamic View ZenPack is installed, a Dynamic View screen will be available on UCS Manager devices. This view shows a simplified topology of the more important elements being managed and how they're related. The view will show slightly different types of elements for UCS Classic, Mini and Modular.
When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact and root cause analysis capabilities for services running on Cisco UCS Manager. The service impact relationships described below are automatically added. These will be included in any services that contain one or more of the explicitly mentioned components.
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 switch card failure will imply that all related ports are also failed.
The following reports are included with this ZenPack. They can be found in the Cisco UCS Reports report organizer:
Stand-alone C-Series and E-Series monitoring data is collected using UCS Rack-Mount Servers CIMC XML API and E-Series Servers CIMC XML API respectively. These APIs are nearly-identical and therefore provide roughly the same monitoring functionality.
Note: CIMC firmware version 1.5 is the minimum supported version.
The following components will be automatically discovered. The properties and relationships will be periodically remodeled to provide automatically up-to-date monitoring when the system configuration changes.
The following metrics will be collected every 5 minutes by default. This can be controlled with the zCiscoUCSCIMCPerfInterval configuration property. Unless specifically noted these metrics are available from C-Series and E-Series servers.
Zenoss will create events for all UCS faults collected through the CIMC API. Most CIMC faults disappear from the API after they're cleared. Zenoss will clear the corresponding Zenoss events when this occurs. The timestamp of corresponding Zenoss events will match the UCS fault's timestamp. So it is important that both Zenoss servers and the UCS servers have relatively accurate clocks.
The CIMC API doesn't provide a timezone offset for when faults occurred, so Zenoss has to assume that the time is UTC. If the server is configured to a timezone other than UTC, it will result in Zenoss misreporting the time events occurred by the opposite of the server's timezone offset.
Faults are collected from the CIMC interface once every 60 seconds by default. This can be changed using the zCiscoUCSCIMCEventsInterval configuration property.
The following additional fields and potentially more will also be populated for each event. These are the fields native to a UCS CIMC fault record. If a fault occurs that has other fields, those will be added with the same ucs.cimc prefix.
When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact and root cause analysis capabilities for services running on Cisco UCS C-Series and E-Series servers. The service impact relationships described below are automatically added. These will be included in any services that contain one or more of the explicitly mentioned components.
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 fan module failure will imply that all related fans are also failed.
Installation should be performed as per usual instructions.If installing manually, ensure that all prerequisites ZenPacks listed in the Releases section are installed.
Note: For the customers with UCSCapacity ZP 1.6.0 installed, it is recommended to contact zenoss support prior to upgrade.
CiscoUCS ZenPack version 3.0.0 integrates the features from the older UCSCapacity ZenPack. Therefore it is important to upgrade UCSCapacity to 2.0.0 to preserve metric data and migrate all features and templates to CiscoUCS.
NOTE: Failure to follow these instructions will cause data loss and damage to Zenoss!
If upgrading from 2.8.0 to 3.0.0 with UCSCapacity ZenPack installed, you must first upgrade the UCSCapacity ZenPack to 2.0.0 and then upgrade CiscoUCS ZenPacks.
The required order of operations in this case is:
Note that after upgrade of both UCSCapacity ZP to 2.0.0 and CiscoUCS ZP to 3.0.0,Aggregation Pools will be removed until the next modeling cycle.Historic metric data is retained and will resume collection after they are remodeled.
In order to avoid monitoring and modeling issues, you have to use unique MAC addresses within your network, it can be configured over MAC Pools component on Cisco UCS Manager instance.
The Cisco UCS C3260 Rack Server is only supported by the UCS Manager XML API. There is no CIMC API support for the C3260 at this time.
A MAC pool is a collection of network identities, or MAC addresses, that are unique in their layer 2 environment and are available to be assigned to vNICs on a server. If you use MAC pools in service profiles, you do not have to manually configure the MAC addresses to be used by the server associated with the service profile.
In a system that implements multi-tenancy, you can use the organizational hierarchy to ensure that MAC pools can only be used by specific applications or business services. Cisco UCS Manager uses the name resolution policy to assign MAC addresses from the pool.
You can specify your own MAC addresses or use a group of MAC addresses provided by Cisco. To assign a MAC address to a server, you must include the MAC pool in a vNIC policy. The vNIC policy is then included in the service profile assigned to that server.
You can read more about MAC Pools on the official Cisco website.
Use the following steps to start monitoring UCS Managers using the Zenoss web interface.
Alternatively you can use zenbatchload to add Cisco UCS Managers 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 endpoints can be added under the same /Devices/CiscoUCS/UCS-Manager section.
ucsm1 setManageIp=<address>, zCiscoUCSManagerUser=<username>, zCiscoUCSManagerPassword=<password>
You can then load the endpoint(s) with the following command.
NOTE: To add an LDAP user, you would prepend "ucs" to the Domain name as such:
Use the following steps to start monitoring standalone UCS C-Series servers using the Zenoss web interface.
Alternatively you can use zenbatchload to add stand-alone Cisco UCS C-Series servers 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 servers can be added under the same /Devices/CiscoUCS/CIMC/C-Series section.
server1 setManageIp=<address>, zCiscoUCSManagerUser=<username>, zCiscoUCSManagerPassword=<password>
Use the following steps to start monitoring UCS E-Series servers using the Zenoss web interface.
Alternatively you can use zenbatchload to add Cisco UCS E-Series servers 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 servers can be added under the same /Devices/CiscoUCS/CIMC/E-Series section.
server1 setManageIp=<address>, zCiscoUCSManagerUser=<username>, zCiscoUCSManagerPassword=<password>
NOTE: You can skip the data collection for particular datapoints defined under CIMC XML API datasources with xpath_skip_query property located in the datapoints, use XPath syntax while adding the custom skip rules.
/CiscoUCS (used for UCS-Manager)
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 UCS ZenPack folder in the repository to see the following resources added by the bundle.
Domains can be used to create ad hoc views using the following steps:
NOTE: Ad Hoc Views may require minimum 24 hours to populate data.
3.0, 3.1(1x), 3.1(2b)
2.2, 3.1(1x), M4, M5
If you see collection errors messages like CIMC Maximum sessions reached (554), this may indicate connections are not being released properly. This can happen for several reasons, but can also result from manual testing of Zenpython or other application accessing the Cisco XML API. Setting zCiscoUCSCIMCReuseSessions to false, which will close sessions after each collection and hopefully mitigate this issue. See Configuration Properties for more information on this zProperty.
CIMC Maximum sessions reached (554)
In cases where a CIMC device contains lots of components and it takes more than zCollectorClientTimeout's value to model the device, the modeling session will be interrupted due to the timeout. It leads to inappropriate data modeling in Zenoss and session leakage on the modeled CIMC device. The solution will be to increase zCollectorClientTimeout property to 300 seconds or higher, by default, it's 180 seconds. You can set the property in "Configuration Properties" section on a specific CIMC device or whole device class. After the timeout is changed, the leaked session must be closed on the actual CIMC device, there are several ways how it can be done with a privileged user:
Connect to CIMC via SSH and run the following commands:
set enabled no
set enabled yes
Another recommendation will be to create a read-only user on a CIMC device and use it for monitoring purposes in Zenoss.
In case you see one of the following errors while connecting to a CIMC device:
You have to check whether the zCiscoUCSCIMCSSLProtocol zProperty on your CIMC device in Zenoss corresponds to the appropriate SSL/TSL protocol used on the actual target CIMC device.
If you observe negative or unrealistic values in both graphs and reports related to some specific Cisco UCS Manager, the first thing would be to check whether the firmware version of the Cisco UCS Manager is greater than 2.2.8f.Confirm that the issue was resolved by a software update to the 2.2.8f version on the UCS side.