{"type":"model","meta":{"id":"/apps/pubhub/media/crosswork-network-controller-7-1/f445c17e25a1120e8fbde4bd413083d0fd88b2b3/42552ab7-d679-37b0-afe0-7313ad2e8c01","info":{"title":"Service Health Heuristic Packages APIs","description":"APIs for requesting rule and metric data stored by the Crosswork Service Health application.","termsOfService":"terms-of-service","contact":{"name":"Crosswork Team, Cisco","email":"support@cisco.com"},"license":{"name":"Cisco Software License Agreement","url":"http://www.cisco.com/public/sw-license-agreement.html"},"version":"7.1.0"},"security":[{"bearerAuth":[]}],"x-parser-conf":{"overview":{"markdownPath":"reference/ServiceHealth/sh_heuristic_packages_overview.md"}},"openapi":"3.0.1","servers":[{"url":"/crosswork/aa/hpmgr"}],"securitySchemes":{"bearerAuth":{"type":"apiKey","description":"Security token for authorizing requests for these APIs.","name":"Authorization","in":"header"}}},"spec":{"type":"object","description":"Metric Class instance","properties":{"MDTMetric":{"type":"object","properties":{"sensor_path_exact":{"description":"Exact YANG path of the subtree to get the current metric.\n Examples:\n * `openconfig-interfaces:interfaces/interface[name=GigabitEthernet0/0/0/2]/\n subinterfaces/subinterface[index=600]/state/admin-status`\n (subtree of one node) the administrative status of subinterface 600 of interface GigabitEthernet0/0/0/2\n * `openconfig-interfaces:interfaces/interface[name=tunnel-ip13]/state/counters`\n (subtree of height one) all counters of interface tunne-ip13\n * `openconfig-interfaces:interfaces/interface[name=tunnel-ip13]/state/counters/in-errors`\n (subtree of one node) the number of input errors on ineterface tunnel-ip13","type":"string"},"sensor_path_config":{"description":"Longest prefix for which the target router will actually return some value when configured.\n Example: configuring the sensor path on a IOS-XRV router\n `openconfig-interfaces:interfaces/interface[name=tunnel-ip13]/state/counters/in-errors`\n will not work (not resolved). However, configuring the sensor path\n `openconfig-interfaces:interfaces/interface[name=tunnel-ip13]/state/counters`\n will return a bag contaning the wanted value. The pipeline would then retrieve the specific leaf under this subtree (in this case, the value of `in-errors`) and assign it to the metric.\nIn Crosswork, there is a limitation on the number of collection jobs that can be supported. Currently, the limit is about 1000 jobs. Because of this, Service Health needs to subscribe at the gather path level and perform filtering on the resultant metric bag to get to the desired leaf that corresponds to the given metric.\nHence, for all deployment purposes, this field should be set to a valid gather path. In the current example, that would be `openconfig-interfaces:interfaces/interface`.","type":"string"}},"description":"Metric collected using telemetry plugin.","$$ref":"#/components/schemas/MetricImplMdtMetric"},"SNMPMetric":{"type":"object","description":"Metric Impl SNMP metric","properties":{"oid_path_config":{"type":"string","description":"OID path config"},"oid_path_exact":{"type":"string","description":"OID path exact"}},"$$ref":"#/components/schemas/MetricImplSnmpMetric"},"GNMIMetric":{"type":"object","description":"Metric Impl gNMI metric","properties":{"sensor_path_exact":{"description":"MDT corresponding comments apply to below gNMI fields","type":"string"},"sensor_path_config":{"type":"string","description":"Sensor path config"},"origin":{"description":"Specifies the metric origin if it is different from the YANG module. For IOS-XE, the origin needs to be specified as \"rfc7951\".\nFor XR, this field can be left empty.\nWhen this field is left empty, Service Health will attempt to extract the YANG module name from the sensor path and use the module name as the value for the origin.","type":"string"}},"$$ref":"#/components/schemas/MetricImplGnmiMetric"},"GNMITemplateMetric":{"type":"object","properties":{"sensor_path_exact":{"type":"string","description":"Sensor path exact"},"sensor_path_config":{"type":"string","description":"Sensor path config"},"sensor_path_device_feed":{"type":"string","description":"Sensor path device feed"},"origin":{"description":"Specifies the metric origin if it is different from the YANG module. For IOS-XE, the origin needs to be specified as \"rfc7951\".\nFor XR, this field can be left empty.\nWhen this field is left empty, Service Health will attempt to extract the YANG module name from the sensor path and use the module name as the value for the origin.","type":"string"}},"description":"\"GNMITemplateMetric\": {\n \"sensor_path_exact\": \"Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/vrfs/vrf[vrf-name={vrf}]/sessions/session[neighbor-address={neighbor-ip}]/connection-state\",\n \"sensor_path_config\" : \"Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/vrfs/vrf[vrf-name={vrf}]/sessions/session[neighbor-address={neighbor-ip}]/connection-state\"\n \"sensor_path_device_feed\": \"Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/vrfs/vrf[vrf-name={vrf}]/sessions/session\"\n }","$$ref":"#/components/schemas/MetricImplGnmiTemplateMetric"},"CLITemplateMetric":{"type":"object","properties":{"sensor_path_config":{"type":"string","description":"Sensor path config"},"sensor_path_exact":{"type":"string","description":"Sensor path exact"},"device_package_name":{"type":"string","description":"Device package name"},"function_name":{"type":"string","description":"Function name"}},"description":"\"CLITemplateMetric\": {\n \"sensor_path_config\": \"show cef {prefix}\",\n \"sensor_path_exact\": \"route/next-hop\".\n \"device_package_name\": \"showcefprefix\",\n \"function_name\": \"getCefPrefixInfo\"\n }","$$ref":"#/components/schemas/MetricImplCliTemplateMetric"},"CLIMetric":{"type":"object","properties":{"sensor_path_config":{"type":"string","description":"Sensor path config"},"sensor_path_exact":{"type":"string","description":"Sensor path exact"},"device_package_name":{"type":"string","description":"Device package name"},"function_name":{"type":"string","description":"Function name"}},"description":"The non-parameterized CLI metric.","$$ref":"#/components/schemas/MetricImplCliMetric"},"precedence":{"description":"The higher the value, the higher the precedence","type":"integer","format":"int64"},"convert_args":{"type":"object","description":"Convert arguments","additionalProperties":{"type":"object","properties":{"arg_substitutes":{"type":"array","description":"Argument substitutes","items":{"type":"object","properties":{"from":{"type":"string","description":"Pattern to be replaced"},"to":{"type":"string","description":"Value to be replaced with"}},"description":"The arg_substitutes object identifies each pattern (map key) and the value it is to be replaced with (map value). It performs substitutions in the order in which it identifies the patterns.","$$ref":"#/components/schemas/ArgConversionsArgSubstitutes"}}},"description":"Convert the input argument to this Metric Class instance before substituting its value in the sensor paths and OIDs. These conversions are handy in scenarios like the following. \nLet's assume that the ServiceConfig uses ifName as the argument and its value as 'GigabitEthernet0/0/5 612', but the ifName value in the incoming SNMP feed is 'Gi0/0/5.SI.612'. If the pipeline attempts to find a match using the incoming ifName argument value as is, then the pipeline will not find a matching interface. This is where conversions come into play. The incoming argument value needs to go through some conversions before the resultant value can be used to filter the interface entry of interest from the incoming SNMP feed. \nIn this example scenario, the conversions of interest are:\n - Substitute 'GigabitEthernet' with 'Gi'\n - Substitute ' ' with '.SI.'\nThese conversions effectively transform 'GigabitEthernet0/0/5 612' into 'Gi0/0/5.SI.612'.","$$ref":"#/components/schemas/MetricImplArgConversions"}},"val_mapping":{"type":"object","properties":{"values":{"type":"object","description":"Properties","additionalProperties":{"type":"string","description":"Additional properties"}}},"description":"Maps the result of the metric to a normalized output value. This allows for consistent interpretation across devices\nExample:\n\"value_mapping\": {\n \"values\": {\n \"dest-active\": \"active\",\n \"dest-not-active\": \"not-active\"\n \"1\": \"active\",\n \"2\": \"not-active\"\n \"true\": \"active\"\n \"false\": \"not-active\"\n },\n \"default\": null\n}","$$ref":"#/components/schemas/MetricImplValueMapping"},"device_output_labels":{"type":"array","description":"Device output labels","items":{"type":"string","description":"Items of Device output labels"}},"post_processing_expr":{"type":"string","description":"Post processing expression"},"only_when":{"description":"The only_when condition expresses the condition that needs to be satisfied in order to select a given implementation.\nThe given implementation can have the highest precedence value but if the only_when condition is not satisfied then the respective implementation will not be selected.\nCurrently only below 2 conditions are supported:\n \"AddressFamily({\u003cmetric-param\u003e}) == 'ipv4'\"\n \"AddressFamily({\u003cmetric-param\u003e}) == 'ipv6'\"\nExample, say metric param name is 'peer-ip-addr', then valid only_when expressions are:\n \"AddressFamily({peer-ip-addr}) == 'ipv4'\"\n \"AddressFamily({peer-ip-addr}) == 'ipv6'\". The only_when condition helps abstract out ipv4 vs ipv6 implementation-specific differences, such as the MIB OID or YANG module, and so on.","type":"string"}},"$$ref":"#/components/schemas/MetricImpl","title":"MetricImpl"}}