Documenting Rules

A sample template rule is available here.

package com.indeni.server.rules.library.templatebased.crossvendor

import com.indeni.ruleengine.Context
import com.indeni.server.rules.library.{ConditionalRemediationSteps, StateDownTemplateRule}

/**
  * Created by yoni on 4/5/17.
  */
case class cross_vendor_bgp_peer_down(context: Context) extends StateDownTemplateRule(context,
  ruleName = "cross_vendor_bgp_peer_down",
  ruleFriendlyName = "All Devices: BGP peer(s) down",
  ruleDescription = "Indeni will alert if one or more BGP peers isn't communicating well.",
  metricName = "bgp-state",
  applicableMetricTag = "name",
  alertItemsHeader = "Peers Affected",
  alertDescription = "One or more BGP peers are down.",
  baseRemediationText = "Review the cause for the peers being down.")(
  ConditionalRemediationSteps.VENDOR_CP -> "Consider reading Tobias Lachmann's blog on BGP: https://blog.lachmann.org/?p=1771",
  ConditionalRemediationSteps.VENDOR_PANOS -> "Consider starting at https://live.paloaltonetworks.com/t5/Configuration-Articles/BGP-Routes-are-not-Injected-into-the-Routing-Table/ta-p/54938 . You can also log into the device over SSH and run \"less mp-log routed.log\"."
)

Parameters "alertItemsHeader", "alertDescription", "baseRemediationText" and the second part (after the colon ":") of the "ruleFriendlyName" are documentation presented within Indeni .

The text from the parameter "ruleDescription" is displayed in the Indeni web UI in the Indeni Rules tab.

Guidelines for the documentation:

Alert Headings

Alerts convey important information related to the state of your infrastructure. Write short, descriptive, multiword alert titles.

Examples:

BGP peer(s) down
RX packets dropped

Description

Communicate something specific about your systems in simple language so that you can draw human attention to the particular systems that require attention.

Please capitalize "Indeni" in the ruleDescription.

Context (Optional)

Often you need to include additional information that provides a context for the alert. For example, which BGP peer is down.

A network device has many interfaces so it is important to know which interface(s) require investigation.

Remediation Steps

Provide actionable steps even if there are many possible cause to the problems. A good next step may be collecting additional information for escalation.

Example:

‘Use the "show interface" command to identify the reason for the err-disable interface state. After fixing the issue perform a "shut/no shut" on the port to re-enable it. It is possible to enable automatic periodic err-disable recovery by using the "errdisable recovery cause" configuration command.’

For cross vendor rules, provide vendor specific remediation steps. For example, packets dropped is a common problem across all network elements. Apply vendor specific commands to capture the interface transmitted and received packets counters for further troubleshooting.