LIVE Webinar: Dec. 19, 1pm CSTLearn how to overcome the challenges posed by containerized microservices in highly dynamic IT environments.
451 Research: Key Trends in Machine Learning, AI & Cloud
Zenoss is the only enterprise monitoring solution certified Nutanix Ready - Integrated.
Zenoss Partner Portal
Become a Partner
Learn. Discuss. Participate.Join thousands of Zenoss users and experts to learn, discuss and participate in the Zenoss Community.
Customer Support Portal
Zenoss Learning Center
Forrester Insights:Powering Digital Transformation With Intelligent Monitoring & Analytics
Customers for LifeAt Zenoss, our customers are at the core of everything we do.
Request A Demo
This ZenPack provides support for monitoring Cisco Unified Computing Systems(UCS). UCS Manager, UCS-Mini, stand-alone C-Series rack-mount servers and E-Series servers are supported.
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.
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 configured for them in UCS Manager.
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.
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.
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.
The upgrade to 2.1.0 from previous versions will update the device class for UCS-Manager. As a consequence, without removing the device and re-adding the device, you may see an older device class.
In addition, the report Free Slots has now been renamed: Free Memory Slots.
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.
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
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:
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. Confirmed that the issue was resolved by a software update to the 2.2.8f version on the UCS side.
View the discussion thread.
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.