Connecting a Customer Environment to Riverbed IQ Ops SaaS

This illustration shows how data sources residing in the customer environment connect to Riverbed IQ Ops:

Customer Environment Connectivity to IQ SaaS

Note these prerequisites:

  • The target data sources must be configured with credentials that permit Riverbed IQ Ops to connect and establish the two-way conversation that is needed for the data source to stream key measurements to Riverbed IQ Ops, and for the data source to process/reply to Runbook requests that occur over the course of an automated investigation.

  • The target Riverbed Edge platform needs to be selected and prepared (currently, Riverbed IQ Ops supports deploying Riverbed Edge on the following: AWS, Azure, and VMware ESXi).

  • Riverbed IQ Ops employs a Shared Responsibility Model for Riverbed Edge in which Riverbed supplies Riverbed Edge functionality on top of a Customer-supplied and managed VM.

    • Configure the Riverbed Edge gateway on your Riverbed IQ Ops tenant (see Configuring Riverbed Edge and Data Sourcess).

    • You must prepare a Customer-owned/managed VM environment upon which Riverbed Edge can be configured. (Currently, Riverbed IQ Ops supports deploying Riverbed Edge in a number of VM environments).

    • Then, use the Riverbed-supplied cloud-init or ISO file (depending on the VM Type) to configure Riverbed Edge functionality in the target VM-environment (see Configuring Riverbed Edge and Data Sources).

  • Once the Riverbed Edge gateway is configured, configure the target data sources on your Riverbed IQ Ops tenant (see Configuring Riverbed Edge and Data Sources).

Once all Riverbed Edge(s) and data source(s) are configured on the Riverbed IQ Ops tenant, data will begin to flow into the system and:

  • The Data Ocean begins to take shape:

    • This is a distributed repository of customer environment information that is accessible to Riverbed IQ Ops. It comprises a small amount of core information that is cached in the customer’s Riverbed IQ Ops tenant and the vast full fidelity data that resides in the native Riverbed data sources (e.g., while executing an automation, the Runbook may quickly retrieve cached information from the customer’s Riverbed IQ Ops tenant, or may issue a query directly to a data source to tap into high fidelity data).

  • Key Measurements begin to flow into the pipeline:

    • Ingest & Analytics: begins processing key measurements

      • Certain key measurements have a simple model (e.g. static threshold) that enable anomalies to be immediately detected/processed all the way through incident-generation and Runbook execution.

      • Other key measurements employ a more complex model (e.g time-series baseline) that require time to build. As a result, it takes time to detect anomalous behavior for these key measurements (and further process those anomalies into Incidents with associate Runbook-executions), e.g.,

        • It takes 2-days to build an initial daily-seasonal time-series baseline model, and 14-days to build an initial weekly-seasonal time-series baseline model.

        • Alert: While these models are building, the detection of anomalies and generation of associated Incidents will vary.

          • There will be no associated Indicators/Incidents for the first 2-days (while the initial daily-seasonal model is building).

          • After the initial daily-seasonal model is built (2-days after observing a new Key Measurement):

            • Anomalies to the daily-seasonal model are detected and associated Incidents are generated.

            • Simultaneously over the next 12-days: the system builds the 14-day/weekly-seasonal model.

          • After the initial weekly-seasonal model is built (14-days after observing a new Key Measurement):

            • Anomalies to the weekly-seasonal model are detected and associated Incidents are generated.

            • The system now continuously learns from the customer environment and evolves the weekly-seasonal model as the behaviors/patterns in the customer environment changes.