Blade(s) down-cisco-nxos

Blade(s) down-cisco-nxos

Vendor: cisco

OS: nxos

Description:
Indeni will alert one or more blades in a chassis is down.

Remediation Steps:
Review the cause for the blades being down.
|
|Most of the module related failures (such as the module not coming up, the module getting reloaded, and so on) can be analyzed by looking at the logs stored on the switch. Use the following CLI commands to identify the problem:
|•show system reset-reason module
|•show version
|•show logging
|•show module internal exception-log
|•show module internal event-history module
|•show module internal event-history errors
|•show platform internal event-history errors
|•show platform internal event-history module
|Further details can be found to the next CISCO troubleshooting guide:
|https://www.cisco.com/en/US/products/ps5989/prod_troubleshooting_guide_chapter09186a008067a0ef.html

How does this work?
This script logs into the Cisco Nexus switch using SSH and retrieves the modules state by using the “show module” command.

Why is this important?
Report the status of the systems modules/line cards.

Without Indeni how would you find this?
The administrator has to poll the data and monitor the state the modules manually.

nexus-show-module

name: nexus-show-module
description: Check the hardware modules state
type: monitoring
monitoring_interval: 5 minute
requires:
    vendor: cisco
    os.name: nxos
    hsrp_engine: true
comments:
    blade-state:
        why: |
            Report the status of the systems modules/line cards.
        how: |
            This script logs into the Cisco Nexus switch using SSH and retrieves the modules state by using the "show module" command.
        without-indeni: |
            The administrator has to poll the data and monitor the state the modules manually.
        can-with-snmp: true
        can-with-syslog: true
steps:
-   run:
        type: SSH
        command: show module | xml
    parse:
        type: XML
        file: show_module.parser.1.xml.yaml

chassis_blade_down

// Deprecation warning : Scala template-based rules are deprecated. Please use YAML format rules instead.

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

import com.indeni.server.rules.RuleContext
import com.indeni.server.rules.library.templates.StateDownTemplateRule
import com.indeni.server.rules.RemediationStepCondition

/**
  *
  */
case class chassis_blade_down() extends StateDownTemplateRule(
  ruleName = "chassis_blade_down",
  ruleFriendlyName = "Chassis Devices: Blade(s) down",
  ruleDescription = "Indeni will alert one or more blades in a chassis is down.",
  metricName = "blade-state",
  applicableMetricTag = "name",
  alertItemsHeader = "Blades Affected",
  alertDescription = "One or more blades in this chassis are down.",
  baseRemediationText = "Review the cause for the blades being down.")(
  RemediationStepCondition.VENDOR_CP -> "If the blade was not stopped intentionally (admin down), check to see it wasn't disconnected physically.",
  RemediationStepCondition.VENDOR_CISCO ->
    """|
      |Most of the module related failures (such as the module not coming up, the module getting reloaded, and so on) can be analyzed by looking at the logs stored on the switch. Use the following CLI commands to identify the problem:
      |•show system reset-reason module
      |•show version
      |•show logging
      |•show module internal exception-log
      |•show module internal event-history module
      |•show module internal event-history errors
      |•show platform internal event-history errors
      |•show platform internal event-history module
      |Further details can be found to the next CISCO troubleshooting guide:
      |https://www.cisco.com/en/US/products/ps5989/prod_troubleshooting_guide_chapter09186a008067a0ef.html""".stripMargin
)