QBA Exporatory Interface

MetricDb

MetricDb is a Juniper Apstra proprietary time-series database. Apstra components such as IBA, Audit, Anomaly, and System-Resource-Monitoring use MetricDb to store time-series/historic data about various aspects of the DC. This data includes network-traffic features (i.e. interface-counters, ecmp-imbalance etc.), device-health features (i.e. CPU usage), memory usage, temperature, power, transceiver stats, Controller features (i.e. audit, anomalies etc). When querying MetricDb, the ‘locator’ attribute specifies which of the previously mentioned graph sources to use. We recommend that you use ‘operational’ graph for QBA queries.

Graph

Apstra Graph database (Blueprint) is a knowledge-base of the running-state of the DC. Graph represents a single source of truth regarding infrastructure, policies, constraints etc. Apstra maintains the following copies of the graph:

• Config: Captures user intent in the form of security policies, preferred routes, network requirements etc.

• Staging: Represents the config graph plus the translation of the intent into automated administrative tasks across the DC.

• Operational: Captures the current running state of the DC.

The following is an example graph query:

graph_query = {
    "name": "graph",
    "from": {
        "source": "persisted_sysdb_files",
        "locator": ["{}/{}".format(base_dir, sysdb_stem),
                    blueprint_id,
                    "operation"]
    },
    "filter": "node('system', name='system', role=is_in(['leaf', 'spine']), deploy_mode='deploy').out('part_of_pod').node('pod', name='pod')",
    "select": {
        "keys": {
            "system_id": ["system", "system_id"],
        },
        "data": {
            "label": ["system", "label"],
            "role": ["system", "role"],
            "deploy_mode": ["system", "deploy_mode"],
            "pod_label": ["pod", "label"],
        }
    }
}

Note that the ‘locator’ parameter generally refers to “operational” graph. For more information about graph, see Graph.

As an example, let’s build a query that fetches data from these two data sources. Let’s say we want to improve the current DC inventory of optical transcievers, and gain insight into the most efficient maintenance windows for optical transceivers. We suspect that by visualizing temperature trends of the transceivers, we may be able to learn more and leverage this knowledge to anticipate failures or compare vendors.

We don't necessarily have a clear idea of what we're looking for, but we want to explore the data. We know that the Apstra IBA “Optical-transceiver” probe monitors various stats like temperature, power etc. from all optical transceivers in the DC. Within the stage of this probe, metricDb is enabled and collecting historical data. We can use the ‘2min-avg’ stage metric to collect ‘model’, ‘vendor’, and ‘temperature’ data. Additionally, we can customize this data fo rour needs using ‘hostname’, ‘role’, ‘label', and ‘ipv4_addr’ information about the system from Graph.

By combining these two data sources, we can classify the data per (system, interface) pair and plot a the trend of temperature variables over the last week, month, or year, based on data availability. The Exploratory interface tool is the GUI-based builder for queries like this. The example below shows this query in JSON format.

Advanced users might choose to bypass the Exploratory interface and make direct updates to the query instead. In such cases, you can run queries manually using ‘/api/qba/query’ rest-api endpoint. Note that this query comprises three subqueries:

• Subquery for MetricDb metric ‘Optical probe, 2min-avg’ stage

• Graph subquery

• Final subquery that combines the prior two subquery results to form the final, aggregated results

This query output can be plotted as a line graph to visualize trends. After the data is visualized, you can explore the information as you see fit. You might compare the data based on vendor, or any number of optical transceiver stats.

query = [
    # metric db query
    {
        # sub query can be referenced by name
        "name": "xcvr_metricdb",
        "from": {
            "source": "metricdb",
            "locator": ["iba", "sf-pod", "xcvr_probe", "2min-avg"],
            "between": {
                "begin": "2022-08-20T05:00:00",
                "end": "2022-08-27T05:00:00",
                "aggregation_interval": 3600
            }
        },
        "select" : {
            "keys": {
                "system": "system",
                "interface": "interface",
            },
            "data": {
                "model": "model",
                "vendor": "vendor",
                "temp": "temperature"
            }
        },
        "filter": [
            "or",
            ["=", "vendor", "juniper"],
            ["=", "vendor", "arista"]
        ],
    },

    # graph query
    {
        # sub query can be referenced by name
        "name": "graph",
        "from": {
            "source": "graph",
            "locator": ["sf-pod", "operational"]
        },
        "select" : {
            "keys": {
                "system_id": ["@", "system", "system_id"],
                "ifc_name": ["@", "interface", "if_name"]
            },
            "data": {
                "hostname": ["@", "system", "hostanme"],
                "role": ["@", "system", "role"],
                "label": ["@", "interface", "label"],
                "ipv4_addr": ["@", "interface", "ipv4_addr"]
            }
        },
        "filter": "node('system', name='system', system_id=not_none())."
              "out('hosted_interfaces')."
              "node('interface', name='interface')",
        "ordered": [
            {"system_id": "ascending"},
            {"ifc_name": "ascending"}
        ]
    },

    # To combine the above two query results, and show how 
    # each interface’s temperature is trending using simple 
    # linear regression. And sort the result in descending 
    # order, i.e. the one with faster rising temperature
    # is placed in the front.
    {
        "from": [
            {   # result of xcvr metricdb probe query
                "source": "query",
                "name": "xcvr_metricdb"
            },
            {   # result of graph query
                "source": "query",
                "name": "graph",
                "join": {
                    "system_id": "system",
                    "ifc_name": "interface"
                }
            }
        ],
        "select" : {
            "keys": {
                "system_id": ["@", "xcvr_metricdb", "system"],
                "ifc_name": ["@", "xcvr_metricdb", "interface"]
            },
            "data": {
                "temp_trend": ["slr", ["@", "xcvr_metricdb", "temp"]],
                "Hostname": ["@", "graph", "hostname"],
                "Ipv4_addr": ["@", "graph", "ipv4_addr"]
            }
        },
        "ordered": [{"temp_trend|coef": "descending"}]
    }
]