Analyze alerts with AI in Cisco Cloud Control

Use AI-assisted root cause analysis of alerts to help network operations teams with the correlation of network issues impacting the application availability and performance.

Before you begin

Cisco Cloud Control compares network and application telemetry to help determine whether a supported alert is associated with network or application degradation.

The workflow supports:

  • ThousandEyes alerts

  • Meraki Assurance alerts that contain a ThousandEyes application alert

Make sure the integrations that provide the alert, network telemetry, and application telemetry are configured for your organization. If a required data source is unavailable, the analysis might return a partial result or an error.

About the analysis

Network Application correlates a supported alert with network and application evidence. It assesses whether the observed degradation is more consistent with:

  • A network issue

  • An application issue

  • An inconclusive result

The analysis compares two time windows:

  • The incident window associated with the selected alert

  • A preceding healthy baseline window of comparable length

Depending on the alert and the available data, the analysis can use ThousandEyes test results, Meraki WAN and topology information, and Splunk Observability Cloud APM data.

Analyze an alert

  1. In Cisco Cloud Control, open the Actions tab. Locate the alert that you want to analyze. You can analyze a ThousandEyes alert or a Meraki Assurance alert that contains a ThousandEyes application alert.

  2. When you click the alert, the analysis is triggered automatically. The workflow retrieves alert and test data, compares the incident and baseline windows, and correlates the available network and application signals.

  3. Review the leading assessment. The report indicates whether the evidence is more consistent with a network issue, an application issue, or an inconclusive result.

  4. Review the network evidence. Network evidence can include changes in:

    • DNS resolution time

    • Connection time

    • TLS handshake time

    • Network transport time

    • Latency Packet loss

    • Jitter Network path information

    • BGP information

      For a Meraki-initiated alert, the report can also include affected networks, WAN loss and latency, and device or uplink topology.

  5. Review the application evidence.

  6. Review the key findings and affected scope. Use the findings to determine:

    • What changed between the baseline and incident windows

    • Which networks, sites, or services might be affected

    • Which signals support the assessment

    • Whether the customer WAN edge corroborates the network findings

  7. Review any unavailable or skipped evidence. Optional Meraki information might be unavailable if the required data has not yet been ingested into Splunk. An unavailable enrichment signal does not necessarily prevent the core analysis from completing.

  8. Continue the investigation in the linked Cisco Cloud Control, Splunk Observability Cloud, ThousandEyes, or Meraki view.

Use the report as supporting evidence. The analysis helps narrow the likely fault domain, but it does not replace product-specific investigation or incident-response procedures.

Result

The report summarizes the network-versus-application assessment, key findings, affected scope, and supporting telemetry available for the selected alert and time windows.

Troubleshooting

If the analysis does not complete If the workflow returns an error or does not produce a report:

  1. Confirm that the selected alert is a supported ThousandEyes or Meraki Assurance alert.

  2. Confirm that the alert is still within the available data-retention window.

  3. Confirm that the ThousandEyes integration is configured and its access token is valid.

  4. For a Meraki alert, confirm that the Cisco Meraki Add-on for Splunk is ingesting the required alert and WAN telemetry.

  5. Confirm that relevant APM trace and root-service latency data is available in Splunk Observability Cloud.

  6. Retry the analysis after the required telemetry becomes available. If the problem continues, contact your administrator or support team through the approved support path.