Two of the Most Common Mistakes Developing Scripts

When you are learning something new there are always periods of trial and error – especially when it comes to scripting. After taking Indeni Knowledge Language training, our community members put their skills to the test by writing commands and rules. We asked our Knowledge Experts what advice they would give to newbies, and we came up with the top two below. See below for some of the common mistakes made in developing Indeni scripts.

Common Mistake #1: Incomplete Input Validation

When receiving data from the network device, it is important to validate the data and consider empty or null data. For example, a device may have different type of interfaces. Some interface have tx-error stat and some other interface do not have tx-error stat. You are expecting the tx-error stat will trigger an alert once it cross certain threshold. The ind script for collecting this tx-error was written like this (pseudo code):

for( index_of_table = 1; index_of_table < index_interface + 1; index_of_table++ ){
    writeDoubleMetric(“tx-error”, tags, "gauge", 60, array_interfaces
[index_of_table, “tx-error”])
}

This will be a problem if some of the interfaces have no such metric. To correct this, we either initialize this metric for all interfaces to 0 at the beginning(not going to show here), or put a check before collecting it. Here is a pseudo sample after the correction:

for( index_of_table = 1; index_of_table < index_interface + 1; index_of_table++ ){
    If ( array_interfaces[index_of_table, “tx-error”] == “”) {
        array_interfaces[index_of_table, “tx-error”] = 0
   }
   writeDoubleMetric(“tx-error”, tags, "gauge", 60, array_interfaces
[index_of_table, “tx-error”])
}

Another example is the kernel table metric collection for a Palo Alto Networks firewall device. The kernel table rule is checking the actual entries against the table size limit. So both of the actual number of table entries and table limit should be present for the rule to work properly. The problem is, sometimes the device does not return the table limit simply because there isn’t a limit. The IND script should test if both of these two metric values are present; if any value is missing, we should not be collecting the metrics.
Here is the pseudo code which has the problem:

writeDoubleMetric(“fw-table-entries”, tags, "gauge", 60, tableEntries)
writeDoubleMetric(“fw-table-limit”, tags, "gauge", 60, tableLimit)
The following  pseudo code will fix the problem,
If (tableEntries != “” && tableLimit != “”) {
    writeDoubleMetric(“fw-table-entries”, tags, "gauge", 60, tableEntries)
    writeDoubleMetric(“fw-table-limit”, tags, "gauge", 60, tableLimit)
 }

The reason behind the metric value checking is, when a rule evaluates the data, there are three possible outcomes:

• Resolved with no issue
• Issue detected
• Unknown – incomplete data to compute the result

The “unknown” normally is rooted from empty metric and has been very problematic causing false positives and issues not automatically resolved.

Common Mistake #2: Missing or Incorrect Tags

A rule is typically vendor agnostic and is shared among many devices. In addition to making sure that the metric name in the IND script matches the metric name, the tag name is often overlooked.

For example, this is the templated cross vendor rule for checking memory usage. You will find the rule here.

Notice the “applicableMetricTag” field with the value “name”. Your IND script needs to have the tag called “name” and metric name “memory-usage”. Otherwise, you would not see the alert.

Here is an example of the IND script for Juniper SRX. You will need to collect the metric name “memory-usage” with a tag name “name”.

You will find the actual Indeni script here.

These lessons learned were crowd-sourced from our community of certified IT professionals. Are you interested in learning how to code in Indeni Knowledge Language? Get started today by joining the Indeni Crowd and turn your domain expertise into automation.

If you found this article to be helpful, please share with your social networks. If you have feedback or other best practices you use please comment below. Thanks!