Service Impact 5.5.0 CA
This is a controlled-availability release. If you are interested in updating to this release, please contact your Zenoss representative.
This release improves overall performance, better handles commit conflicts, simplifies relationship building, and reduces the time needed to change production states. To support this release, many ZenPacks were updated, to improve performance in defining Service Impact relationships, and reduce inconsistencies by consolidating edge providers with the DynamicView ZenPack.
For version information, please see the compatibility matrix on the Release Notes page.
- In previous releases, adding a dynamic service was very quick, because the Service Impact database included all of the devices and components in the ZODB. In this release, Service Impact creates a background job to copy the devices and components it requires, which can take a few minutes to complete. Scripts that utilize the Service Impact JSON API must be updated to wait for the job to complete before proceeding.
- When you change the metatype configuration, the Service Impact database is updated to add or remove nodes. Depending on which items are changed, processing the changes can take 30-90 minutes in very large environments.
- (IMP-740) During a graph update, the
zenimpactgraphscript creates one worker process for each available CPU core. Each worker requires up to 2GB of main memory. Without it, the host where the update is running may become unstable.
- (ZEN-31884) Occasionally, graph update fails with
ModelCatalogError: Exception performing search. The workaround is to re-run the update.
- After installing one or more ZenPacks that have updated relationship providers, rebuild the graph. For more information, see Rebuilding the graph database.
|Exporting an empty dynamic service organizer results in a traceback.
|When debug logging is enabled, the log files consume all available space within 10 minutes and crash the Impact container.
|Impact diagrams show the wrong content in the icon type field.
|State change events stop processing, and a null pointer exception is thrown.
|Performance during graph update deteriorates under certain conditions.
|Graph updates cannot handle a large number of interlocking changes at the same time.
|The upgrade script does not properly handle the starting version information.
|Solr timeouts during graph updates.
|The upgrade to 5.4.x silently removes leading spaces from dynamic service names, which changes their sort order.
|The relationship edges built during graph update are not cached, which slows overall update performance.
|Building relationships is slower in 5.4.x than in 5.3.x.
|Impact state is calculated using event tags, not elements or subelements.
|Adding a device organizer generates asymmetric relationships.
|Model changes can cause lengthy graph updates.
|Relationships among Cisco UCS devices are missing (Impact 5.4.x installed).
|Model change events that do not affect any dynamic services are being sent to Impact for processing.
|Graph update consumes more memory until memory is exhausted and the container crashes.