We’re pleased to announce the availability of HealthBot Release 3.1.0. With this release, the new and changed features include:
HealthBot now conforms to Juniper Networks’ Flex Software Subscription Licensing (Flex) model. The Flex model supports the following three tiers of licenses: free, advanced, and premium. The free tier allows you to run the application, add some devices, and run basic playbooks with those devices. Advanced and premium licenses are paid tiers and allow you access to run advanced playbooks and use TSDB high-availability respectively. Flex licensing also allows for the purchase of HBOT-C1, HBOT-C2, HBOT-C3, and HBOT-C4 device licenses which allow you to manage specific numbers of different device types in HealthBot.
In addition to creating its own, new Kubernetes cluster during install and upgrade, HealthBot can be installed on exiting Kubernetes clusters. During the healthbot setup portion of an upgrade, the installer checks whether Kubernetes was already used in the existing installation. If so, the Kubernetes version is checked and upgraded to version 1.17.2 if needed. Then the upgrade of HealthBot continues. If Kubernetes was not used, the upgrade simply continues. During a new installation, if you choose to use Kubernetes with HealthBot, you are given the opportunity to enter information about your existing Kubernetes cluster, if one exists. This allows for better integration with existing network infrastructures.
In addition to the median prediction machine learning algorithm, HealthBot now supports the Holt-Winters prediction algorithm. This offers additional ways to train and use HealthBot prediction capabilities.
HealthBot now supports user-defined tagging of fields for use in identifying the application within flow data, setting different thresholds for network events, or enhancing the machine learning capabilities of HealthBot. To do this, you create tagging profiles that look for specific conditions. When the conditions are met, new fields and custom keys can be created within the rules applied to a device or device-group.
HealthBot now supports sample subscriptions to Junos OS and third-party devices using the gNMI RPC protocol. Using SAMPLE-mode subscriptions allows HealthBot to support existing OpenConfig sensors on a wide variety of third party devices that support the gNMI RPC. For Junos OS devices that do not support gNMI, an error is returned and HealthBot falls back to OpenConfig RPC.
When you provide details during the add device workflow, you can now select other vendor and fill in the Vendor Name and OS Name along with the iAgent Port Number to allow HealthBot to communicate using SSH with the third-party device. HealthBot uses SaltStack and the Netmiko proxy to ensure that the SSH communication is performed correctly. This implementation also allows for the use of SSH keys between device and HealthBot rather than user credentials.
Device and Device Group health monitor pages have been combined into one page which is available by navigating to Monitor > Health in the left navigation bar.
As an enhancement to the HealthBot’s reporting capabilities, you can now enter a list of XPATH statements that correspond to field definitions. This list provides a snapshot of those fields that then appear as a tree hierarchy in the details of future reports. These field snapshots can be compared to provide insight about changes to those fields over time.
HealthBot’s single REST API server has been enhanced so that HealthBot now uses two REST API servers. One single-threaded server is used for device configuration changes and has a base URL of: https://<server-ip>:8080/api/v2/config/. The second, multi-threaded server, is used for operational API calls that do not affect device configuration. This operational API server has a base URL of: https://<server-ip>:8080/api/v2/ The configuration server continues to serve “v1” API calls with the base URL of https://<server-ip>:8080/api/v1/.
You can now use the eval formula to evaluate a go language (golang) expression in field definitions. The expression that is evaluated must be a valid golang expression. If other field names are used in the expression, they must be prefixed with a dollar sign ($). In addition, each referenced field and operator should be separated by space characters. For example:
This feature can also make use of the tagging feature described above.