Risks, Limitations And Assumptions

  • Application can handle Critical/Recovery failure notifications for below two cases when user enables App Failure Notifications in configuration
    • Connectivity Exception
    • Authentication Exception
  • Application will send any duplicate/repeat failure alert notification for every 6 hours.
  • The unique ID for the firewall has been changed from the Manager API to the Policy API. Consequently, during the migration of NSX-T devices from manager to policy mode, existing firewalls created using the Manager API will be removed, and new firewalls utilizing the Policy API will be created.
  • Application cannot control monitoring pause/resume actions based on above alerts. Metrics can be used to monitor the resources and can generate alerts based on the threshold values.
  • vmware-nsx-t Event/Alert polling will be started only if the user enables Event/Alert Polling in configuration.
    Notes:
    • Here Event/Alert polling support is given for vmware-nsx-t Alarms only.
    • When a status value which presents in Event/Alert Cleared Status field occurs, OpsRamp will create an Ok alert accordingly. Otherwise, OpsRamp will create an alert based on Event/Alert Severity Filter & Event/Alert Severity Mappings of the Event/Alert Polling configurations.
  • Application will publish event polling alerts on root resource if Alert on root resource is checked in the configuration, else alert will be published on respective resource.
  • Default values of Event/Alert Cleared Status configuration field are: ACKNOWLEDGED, SUPPRESSED, RESOLVED.
  • Possible vmware-nsx-t status values are OPEN, ACKNOWLEDGED, SUPPRESSED, RESOLVED.
  • Default/Possible values of Event/Alert Severity Filter configuration are CRITICAL, HIGH, MEDIUM, LOW.
  • We have provided default mappings to map vmware-nsx-t Severity with OpsRamp Severities as part of Event/Alert Severity Mapping configuration.
  • Users can modify them as per their use-case at any point of time from the application configuration page. Possible OpsRamp Severities are Critical, Warning, Ok, Info.
  • No support of showing activity logs.
  • The Template Applied Time will only be displayed if the collector profile (Classic and NextGen Gateway) is version 18.1.0 or higher.
  • This application supports both Classic Gateway and NextGen Gateway.
  • Below are the possible reasons for tunnel status related metrics of Transport Node can go missing:
    • Transport nodes which are connected to only VLAN transport zones wont have tunnel status metrics.
    • Tunnels are not setup when no NSX backed/ overlay VM is connected to the host.
    • BFD module could be errored and wiped all BFD tunnel related information.
      Transport node tunnel status related metrics nsxt_transportNode_TunnelStatus nsxt_transportNode_TunnelUpCount nsxt_transportNode_TunnelDownCount nsxt_transportNode_BfdAdminDownCount nsxt_transportNode_BfdDownCount nsxt_transportNode_BfdInitCount nsxt_transportNode_BfdUpCount nsxt_transportNode_BfdNoDiagnosticCount nsxt_transportNode_BfdControlDetectionTimeExpiredCount nsxt_transportNode_BfdEchoFunctionFailedCount nsxt_transportNode_BfdForwardPlaneResetCount nsxt_transportNode_BfdPathDownCount nsxt_transportNode_BfdConcatenatedPathDownCount nsxt_transportNode_BfdAdministrativeDownCount nsxt_transportNode_BfdReverseConcatenatedPathDownCount nsxt_transportNode_BfdNeighbourSignalledSessionDownCount
  • Latest snapshot metric support from Gateway 14.0.0.

Troubleshooting

Before troubleshooting, ensure all prerequisites prerequisites are met.

If VMware NSX-T integrations fails to discover or monitor, troubleshoot using the following steps:

  • Check if any alerts have been generated on the NSX-T resource or gateway, or if there are any error logs in vprobe.
  • If there is an error or alert related to the end device connectivity or authentication, try checking the reachability of the end device from the gateway with the following commands:
    • to ping the IP address provided in the configuration: {ping <IP Address>}
    • to try telnet: {telnet <IP Adress> <Port>}
    • To run an API:

      • Prepare the request payload by using below sample request: { “apiVersion”: “debug/v1”, “module”: “Debug”, “app”: “poly-trio”, “action”: “Reachability”, “payload”: { “ipAddressOrHostName”: “”, “protocol”: “https”, “port”: 443, “requestPath”: “”,

        “version”:“v1”,

        “requestMethod”:"<get/post>", “userName”: “”, “password”: “” } }

      • Encode the request payload to base64

      • Log in to the gateway concole and connect to the GCLI terminal using the below command: {## gcli}

      • Run the command using the previously generated base64 encoded string {## sdkappdebug <base64 encoded string>}

  • If there are no connectivity or authentication issues, reach out to the support team for further assistance.