About Heuristic Packages
Crosswork Service Health uses Heuristic Packages as the core logic to monitor and report the health of services. Heuristic Packages define a list of rules, configuration profiles, supported subservices and associated metrics for every service type.
To access the Heuristic Packages, from the Main Menu, choose Heuristic Packages page has two tabs - System and Custom. The default set of Heuristic packages provided with Service Health are called system packages. These packages are available in the System tab. System packages cannot be modified. To customize a package to match your preferences you need to export, modify, and then import it back as a custom package. You can view the custom packages in the Custom tab.
. TheExpand each section in this page to get more details on the services monitored and the thresholds used to generate alerts. You can also hover your mouse over the information i icon for finer details and definitions.
-
Rules: Rules are used to structure services and the dependant sub-services and metrics within a specific service type. Dependencies within these rules help define the sub-services and the metrics that will required for generating the data to assess the health of the service. A service can depend on an individual sub-service, a list of sub-services of the same type, or sub-services of different types.
For list of rules supported in Service Health, see Basic and Advanced Monitoring Rules.
-
Configuration Profiles: Configuration Profiles define threshold values that act as benchmarks for assessing the health of the service. By setting specific threshold values, Configuration Profiles establish the criteria for determining when a monitored parameter is within an acceptable range or deviates from the norm.
Service Health with system heuristics package includes two configuration profiles - Silver and Gold for each of the service types (L2VPN and L3VPN). You can choose a profile option that aligns with your specific monitoring requirements. For instance, a Silver profile has more lenient thresholds compared to a Gold profile. You can create custom configuration profiles as needed.
-
Sub Services: Sub services are characterized by a list of metrics to fetch and a list of computations to apply to these metrics in order to produce a health status and associated symptoms for the service.
For example, the sub-service subservice.evpn.health monitors EVPN health. It is dependant on the metric metric.l2vpn.xconnect.pw.state. It evaluates an expression to check if evpn_state is Up and raises a symptom if degraded.
For list of sub-services supported in Service Health, see Reference - Supported Subservices.
-
Metrics: Metrics define the operational data that should be fetched from different device types. Service Health uses a metric engine to map device-independent metrics to device-specific implementations, supporting multiple combinations of platforms and operating systems.
For example, fetching the metric resource.cpu depends on the device type. For Cisco IOS XR devices, it uses Model-Driven Telemetry (MDT), while for Cisco IOS XE devices, it relies on CLI scraping using the command
show platform resources
.
In essence, there is a hierarchical relationship between Rules, Configuration Profiles, Sub services, and Metrics. Specifically, each Rule is mapped to a type of service, and depends on a number of sub-services to compute service health, sub-services use metrics and configuration profiles set threshold values for the metrics. Based on the values defined in these files, Service Health assesses the health of the service and builds the Assurance Graph.
Here is an example that illustrates the hierarchical relationship between Rules, Sub services, and Metrics.
Customizing Heuristic Packages
The Heuristic Package (HP) bundled with Service Health functions as an assurance model for monitoring L2VPN and L3VPN services. However, the configurations of underlay and overlay networking services may vary across deployments. While the Heuristic Package can adapt automatically to certain configuration variations, other variations cannot be seamlessly absorbed. Examples of such variations include changes in the service function pack model, the introduction of a new device type in VPN service deployment, or the introduction of new network features requiring monitoring. In these scenarios, customization may be necessary for configuration profiles, rules, metrics, or sub-service class definitions.
Refer to the section Build a Custom Heuristic Package for a basic example of how you can create a custom package by customizing the configuration profile for a service. For further details and assistance in building a custom package based on rules, metrics, or sub-services, reach out to Cisco's Customer Experience (CX) team or your Cisco account team.