Analytics & Queries

• 1: System Analytics
• 2: S2QL User Guide
• 3: NL Queries and Aliases

1 - System Analytics

WAN Analytics

The network may face performance degradations for a variety of reasons. The issue could be intermittent or there could be an outage. While it’s important to monitor the WAN metrics to predict performance degradations, it is also important to identify the issues based on multiple data sources. Errors such as port errors/discards are seen over SNMP, but other events such as system reboots are conveyed by syslogs. Consolidating all the data sources to identify the health of a device is crucial.

Selector can gather events and information from various “virtual edge” sources, whether over the Internet, from wireless portions such as LTE, or tunneled portions using MPLS.

The Selector POC considers the following data sources for WAN analytics:

As part of the solution, the platform uses the following integrations:

1. SNMP—This integration is based on SNMP OIDs. The polling frequency is tunable and currently set to 60 seconds by default. Adding a new OID is as simple as navigating to the integrations page and adding a new group to poll.

Various data points are collected, such as system, interface, CPU, memory, BGP, and so on.

2. REST poller—The Selector platform has a rest poller integration for data sources that need to interact using rest APIs. The platform can perform GET and POST commands to process the raw data.

Other integrations are used to ingest vmanage and thousand eyes KPIs.

3. Inventory—Selector can have a configuration management database (CMDB) that is used to build an inventory of all the devices. The metastore2 integration helps to ingest static files provided with device name and latitude and longitude information used to display devices over a geographical map. Inventoried devices are polled by the SNMP engine to capture various metrics such as interface name, utilization, and so on. The table contains both WAN and wireless devices. If there are new fields that need to be ingested, the schema is modifiable. The Selector platform can collect configuration data through SSH or 3rd party integrations such as GIT, and track configuration changes, but the platform does not participate in configuration changes to the devices directly. Selector can also work with 3rd party configuration and automation platforms for configuration automations. Selector’s device-discovery capabilities enable customers to scan the network environment, identify devices, and populate Selector’s integrated CMDB.

   Detected devices are matched to a device profile to enable the automated instrumentation and monitoring of those devices.CMDB inventory status fields indicate the state of each device, which can be factored into alerting and notification workflows.

   As an open data platform, Selector readily integrates with data sources and downstream services and can integrate with CMDB or ERP platforms as required.

4. Syslogs—Selector is capable of ingesting syslogs, as mentioned in the previous section. The syslogs can be mined for patterns and further used in correlations. The logs that are redirected to the platform on UPD port 514 are ingested. Raw logs are converted to events through a process of labeling. Both raw logs and labeled logs can be viewed. Selector further leverages a combination of AI and ML to analyze log messages, identifying patterns and anomalies related to the rate, severity and content of the logs. This capability automatically identifies anomalies and the context of those anomalies, enabling correlation, root cause analysis, and ticket consolidation.

Raw Logs View

Labeling Process

Device_event_ml Table

Labeled logs are continuously trained and a model is created for inference. Any newly generated logs matching the respective labeled pattern are automatically identified as an event which further powers the correlations from the data sources.

Additionally, if there are data sources needing to use a python-sdk, the Selector platform can handle as well. For netflow, the Selector platform has a netflow collector to process these packets.

Wireless Analytics

The Selector platform can ingest data from multiple sources. When part of a POC, the wireless analytics are derived from ingesting metrics from various data sources. Correlated events can be identified to gain insights related to clients connecting to access points (APs). The performance of the APs can be derived leveraging all the data from WLC, controllers and switches (soon). End-to-end correlation within a given site are based on contextual data and joining across switches and routers at the site.

Selector considers the following data sources for wireless analytics:

The Selector platform ingests these data sources as part of a wireless observability POC. The mechanisms are the same for WAN analytics.

In addition to ingestion, the process of generating device health, creating an aggregated health for the WLC, and correlating the events are the same for WAN analytics. From the Selector platform perspective, the key parameters are metrics and labels. These are used to display various dashboards and therefore the process remains the same.

Representation of Meraki

The honeycombs are created for different data points, such as SNR, RSSI, Onboarding, and so forth. Violations are computed based on defined thresholds. The Selector platform can also add derived metrics such as channel switch identification, interface flaps, flap rate, and so on. This tracking is extensible if needed.

DNAC

Wyebot

Correlations

Wireless correlation is the same as with the WAN analytics.

Health Report

The health report for a site is built based on multiple kpi violations. The report considers all devices associated with a site such as routers, switches, and so on. The violations help in “bubbling up” site health depending on the device and number of impacted devices.

Each device can then be drilled down to reveal respective metrics and contributing KPIs for violations for behavior understanding.

Geographical maps are created to represent the devices or sites and to identify and show violations. Drill downs are created to allowing simpler user to query. For geographical maps to work, the latitude and longitude values need to be provided. These can come from inventory tables in vmanage or provided static files.

Site level views are created to easily navigate based on site ID instead of device name or region.

Long presses provide drill-down views on the same screen.

Report Generation and Exports

Users can generate automated reports on a monthly, weekly, or daily basis to generate network insights. These reports can be automated as emails as well, and the timeline is customizable. In addition, Selector can export data as either a PDF or in CSV format.

Topology Representation

The topology of a given site or across and between sites can be identified using. For example, LLDP and CDP data. These are obtained from SNMP and the topology is constructed based on identification of network nodes and edges.

Selector can also overlay metrics and color code in addition to representation. Customized color code definitions are also possible.

2 - S2QL User Guide

Selector Software Query Language (S2QL) User Guide

Table of Contents

Introduction

Main Query Structure and Keywords

Fetching Data

Details On How to Fetch Data Relevant to Draw Insights

Data Rendering

Advanced Query Capabilities

Best Practices for Queryables

Supported Rendering Styles and Usage Examples

Introduction

This document provides a comprehensive guide to the Query Builder, a key tool on the Selector Platform designed for answering your questions about your network using efficient data retrieval and intuitive data visualization. This guide offers in-depth explanations of how S2QL works, its advanced techniques, as well as examples to help construct effective queries to get best insights from your data. Back to TOC

Main Query Structure and Keywords

The Query Builder employs a structured syntax and a set of keywords to precisely define how data is fetched and displayed. This guide examines how to select data and then shows how to render the data effectively for the insights in the most intuitive manner. There are 2 overall steps: fetching data and data rendering.

Back to TOC

Fetching Data

Start by selecting the data you want to look at  Any search involves the following four most important components:

1. Data Source: where to search for data (called Queryables).

2. Filter conditions : what specific data you need for network insights (the where clause).

3. Specific data attribute : attributes of the data user is interested in (the in clause).

4. Time Range: the time range to use for the query.

The Selector platform collects and maintains data for long time periods (data retention timelines are configurable). This allows the platform to use ML to learn from past observations and to predict future behavior. The platform also supports network DVR operations to allow users to examine network conditions at a specific period in the past using the Time Range filter in the Query.

The following figure shows how the S2QL Queryable combines the where clause, the in clause, the time range, and some other organizing keywords (show-by, group-by) to create a widget to link to a dashboard on the Selector platform. All of these aspects of the S2QL are detailed in this guide. Note that the Queryable can be built using the UI or by typing.

Back to TOC

Details On How to Fetch Data Relevant to Draw Insights

1. Queryable (Data Source):  A Queryable is one of the most important constructs of the Selector platform. ****The Queryable specifies the origin of the data being processed. This could be a metric from a time series database (stored in Prometheus), a table from inventory or events database (stored in MongoDB database), or enriched logs from Loki.

• Syntax and Examples of filter condition:

  • Queryable: Flow_Count  (Specifies a metric named Flow_Count - metrics are stored in Prometheus database)

  • Queryable: Application_Mapping (Specifies a table that stores entities and events. for example, Application_Mapping - stored in MongoDb database)

  • Queryable: syslogs (Specifies log data from Loki database)

2. Where (Filter condition) : The where keyword (UI filter group) applies filters to the query, narrowing down the data by matching specified conditions. The where clause utilizes key-value pairs, comparison operators, and logical operators to create precise filtering criteria.

• Syntax and Examples of filter condition:

  • where: site = ‘uk32’ (Filters data with the site value equal to uk32)

  • where: flow_count > 25000 (Filters data with the flow_count value greater than 25000)

  • where: direction = ‘DC internal’ or direction = ‘DC outbound’ (Filters data where the direction value is either DC internal or DC outbound)

  • Note that the where clause supports comparison operators (`=`, `!=`, `>`, `<`, `>=`, `<=`), logical operators (`and`, `or`), as well as regular expressions.

3. In (Data Attributes):  A Queryable points to a data source where enriched data resides in multiple attributes (or columns). To answer a specific question and to derive business insights, a user might want to select only specific attributes of the Queryable. The in keyword selects specific columns. Using attributes allows more targeted data retrieval, helping users to focus on the relevant aspects of the data to answer user questions and to generate insights.

• Syntax and Examples:

  • site, device_type in (Selects the site and device_type columns from the Queryable)

  • response_time in (Selects the response_time column from the Queryable)

  • Note that if the in keyword is omitted, then all columns from the Queryable are retrieved and presented in table format.

  

4. Time (Time Range): The time keyword defines the time range for the query. The range  allows for historical analysis, real-time monitoring, or future projections.

• Syntax and Examples:

  • time: last 30 minutes (Queries data from the last 30 minutes)

  • time: last 7 days (Queries data from the last 7 days)

  • time: between 03/25/25 12:00 and 03/25/25 13:00 (Queries data between 12:00 and 13:00 on March 25, 2025)

  • time: next 7 days (Queries data for the next 7 days; used for projections)

  • If the time clause is not explicitly mentioned in the query, the query picks the “time range” selected in the “time picker.”

  • Note that the time keyword in the Querable overrides any time window set in the UI.

  

  To set a <start_time> and <end_time> time range, you must follow the MM-DD-YYYY HH-MM-SS format guideline.

  

  Back to TOC

Data Rendering

After fetching the selected data, it is equally important to render it in the most intuitive user-friendly way. The Selector platform allows many data rendering options.  

Drop down menus show the rendering styles available for each metric on Query Builder UI.

Drop down menus show the rendering styles available for each metric on Query Builder.

If you do not pick a rendering style, the S2QL picks what it thinks is the best way to render the data. All queries have a default rendering style. For example, an inventory database is always rendered as a simple table with rows and columns. You can render multiple Queryables on a line plot. For best results, limit the multiple queries to two or three at most.

Keywords for Selecting Render Types in Query Builder Bar:

1. As: The as keyword (called renders in the UI) determines the visual representation of the queried data. The Query Builder supports a variety of render styles, each suited for different types of data and analysis.  A complete list of all rendering options available on the platform is at the end of this chapter.

• Syntax and Examples:

  • as Line Plot (Renders the data as a line plot)

  • as Table (Renders the data as a table)

  • as Honeycomb (Renders the data as a honeycomb)

  • Note that other available render styles include Heat Map, Timeline Map, Event Plot, Topology View, DOPO Map, Path, HTML Text, Big Text, Donut, and Sunburst. Some styles are not available in all Queryable data forms.

2. Show-By: The show-by keyword is used to arrange and organize the visual elements (tiles or honeycombs) in the portal. It is particularly relevant for Honeycomb and Sunburst render styles.

• Syntax and Examples:

  • show-by site, device (Arranges the tiles or honeycombs by site, and then by device)

Back to TOC

Advanced Query Capabilities

1. Order-By:  The order-by keyword facilitates drill-down analysis by querying additional columns from the backend. While order-by doesn’t impact the initial visualization, it provides contextual information when users drill down into the data.

• Syntax and Examples:

  • order-by device_type, location (Groups the data by device type. and uses location for drill-down)

2. Group-By:  The group-by keyword facilitates drill-down analysis by querying additional columns from the backend. While group-by doesn’t impact the initial visualization, it provides contextual information when users drill down into the data.

• Syntax and Examples:

  • group-by device_type, location (Groups the data by device type and location for drill-down)

3. Column Aliases: Column aliases allow assignment of user-friendly names to columns, enhancing the clarity and readability of the visualization.

• Syntax and Examples:

  • device_health: Site Health (Assigns the alias Site Health to the device_health column)

  • Note that aliases aliases have several important restrictions, as shown below:

4. Multi-Queryable:  The Multi-Queryable feature enables the plotting of multiple metrics on a single line plot. It is exclusively supported for the Line Plot render style.

• Syntax and Examples:

  • Queryable: Metric1 | Metric2 (Plots both Metric1 and Metric2 on the same line plot)

  • Note that the metrics must share the same set of labels or a similar family of labels for this feature to work correctly. These restrictions are shown below:

5. Aggregation Queries: This feature provides statistical insights into numerical values stored in a mongo table. Use cases include reporting based on availability, roll-up tables, and entity-related data like uptime availability. For example, if device availability is a numerical value in the inventory table, this function allows end users to see “average” device availability over a selected time window. Aggregation is not supported for metrics or logs

• To use aggregate functions, start with the aggregate keyword.

• Follow with the function (for example, count).

• End with the column name (for example, device).

• The following Aggregate Functions are supported:

  • count: this provides the count of unique instances that match a given filter condition

  • max: the maximum value of the set that matches a filter condition (default)

  • min: the minimum value of the set that matches a filter condition

  • median: the median value of the set that matches a filter condition

  • avg / average: the average value of the set that matches a filter condition

6. Nested Queries: Nested queries are used to filter information within a JSON structure. In the where clause, you can specify a nested filter within a JSON structure as shown below:!!

Back to TOC

Best Practices for Queryables

• Use Meaningful Aliases: Assign clear and descriptive aliases to columns for better understanding.

• Leverage Filtering: Utilize the where clause to focus on specific data subsets.

• Optimize Time Ranges: Choose appropriate time ranges for your analysis to avoid excessive data retrieval.

• Explore Visualizations: Experiment with different render styles to find the most suitable representation for your data.

• Validate Your Queries: Regularly test and validate your queries to ensure accuracy and efficiency.

Back to TOC

Supported Rendering Styles and Usage Examples

Standard Data Rendering Styles

Render Style	Description	Example Usage
line-plot	Data is generically rendered as a series of connected points	Numerical metrics packets transmitted traffic volume
table	Data is rendered as a simple array of rows and columns	tabular view of inventory
log-table	Data in log events is rendered in a simple table of rows and columns	Viewing frequency of syslogs and events over time grouped by severity.
big-text	Data is rendered as text with font proportional to the predominance of the information	Important highlights: Network availability Network uptime
donut	Data is rendered as a hollowed-out pie chart with color proportions equal to the predominance of the information	Piechart view : Device availability
gauge	Data is rendered as a type of speedometer arc	Speedometer view: Device availability
stacked-area-plot	Data is rendered as a series of lines stacked and coded to show the separation of values as areas	Average CPU usage by site.
event-plot	Events are generically rendered as a series of points connected by lines	Events: Events ordered by time
stacked-event-plot	Events are rendered as a series of lines stacked and coded to show the separation of values as areas	Events Events are ordered chronologically and grouped by frequency
sunburst	Data is rendered as a radial treemap (multi-level pie chart) organized as a set of nested rings	Vendor distribution KPI breakdown of a device
analysis	Categorical and numerical distribution of the data that is being rendered	Distribution of alert events to find the most common alert

Render Styles Ideal for Showing Health Status

Render Style	Description	Example Usage
map	Data is rendered on a map. This is a special format.	Showing health of devices across the US based on latitudes and longitudes.
threshold-violation-matrix	Data is rendered as color-coded areas from “cold” to “hot” to emphasize violations	Packet drops, latency, and availability across different sites
honeycomb	Data is rendered in six-sided cells to emphasize violations.	Important high-lights: Device status Site status
timeline-heatmap	Data is rendered along a time line as a color range from “cold” to “hot”	change of health of device over period of time

Render Types Ideal for Network Visualization

Render Style	Description	Example Usage
topology	Network date is rendered as a plot of connected devices, sites, or other equipment	BGP adjacency connections between ASNs
topomap	Network data is rendered as a plot of connected devices, sites, or other equipment against a geographical map	BGP adjacency connections between ASNs shown on a world map based on latitudes and longitudes.
path	Network data is rendered as a directional graph. This is a special format.	Displaying the intermediate hops in a segment routing path based on user defined source and destination sites.
pathmap	Network data is rendered as a directional graph on a map. This is a special format.	Displaying the intermediate hops in a segment routing path on a world map based on defined latitudes and longitudes.

Back to TOC

3 - NL Queries and Aliases

Natural language (NL) queries allow more free-form requests for information from the Selector S2 platform. Instead of using the strict syntax used in the Selector Software Query Language (S2QL), NL use is more like typical human questioning.

So, instead of using a complex string such as:

device:DeviceName in device_health as honeycomb where site=~CC00|CC-CITY1|SITE1|DEV1

An NL query in the GUI or with Slack would look like:

GUI NL Command: device status

Slack NL Command: /select device status

Both NL commands give the user a honeycomb grid of device status which can be drilled down into to visualize further details.

Use of Aliases

NL queries work by mapping NL queries to a series of aliases that stand for the S2QL equivalent. Aliases are best thought of as “query shortcuts.” This process lets the NL process see that the queries “Where are we driving?” and “What place are we going in the car?” are very similar, so the LLM can map them to the same alias for S2QL, such as “destination in automobile.”

Any sentence can be mapped to any alias. However, users must still be aware of the role that aliases play. Because the process tries to map NL to aliases, the better the context provided, the easier it is for the LLM to find the closest alias to the NL query.

For example, if the following aliases have been stored:

• bgp status
• bgp health

If the user asks, “How is BGP doing?” the system has a hard time finding the correct alias to choose. The problem is that “status” and “health” are very similar words, so the system struggles to separate them. Therefore, when aliases are created, it is important to make sure to distinguish aliases with context that adds NL similarity and not NL ambiguity. In this case, better aliases would be:

• bgp overall status
• bgp device health

Once more context is added, the NL query “How is BGP doing?” would correctly map to bgp overall status.

Named Entity Recognition and Structured Labels

Named Entity Recognition (NER) is the NL feature that allows specific queries (such as What is the status of device XTZ123?) to be generalized (What is the status of device yyy? where “yyy” can stand for any device.).

The challenge here is to have NER aware of all possible device label replacements. The process starts with the concept of entity scraping as the Selector Software runs.

Entity Scraping, Enumerations, and Label Autopopulation

Entities for NL processing are structured labels and their corresponding values that are extracted from incoming deployment data. They serve as identifiable data points that can be referenced in structured queries.

Enumerations or Enums are a complete list of all possible values for a given label, as gathered by the Selector software as it runs.

Label Autopopulation is a way used by the Selector Software to gather label values as the software runs, a process called automatic label population.

Together, these three aspects of NER work together to allow NL queries. Each of these concepts is described in this section.

Entities

Examples of entities would be things like:

• Region: USA
• Router ID: XYZ123

These entities help users interact with the system dynamically by allowing queries to reference known data points.

How Does Entity Scraping Work?

The NL query process continuously “scrapes” incoming data from various sources to identify and store entities. This process is performed by periodic pollers that extract relevant information from:

• Loki (log aggregation, etc)
• Prometheus (metrics monitoring, etc)
• MongoDB (database collections)
• Dashboard variables

These pollers can be enabled or disabled based on deployment configurations. In MongoDB, specific collections can also be targeted for entity extraction.

Entity scraping settings, including poller activation and MongoDB collection targeting, can be adjusted in the configuration section of the deployment.

Enumerations

Enumerations (Enums) provide a complete list of all known values for a given label. For example, when querying enums for s2_inst, the system returns all detected instances, such as:

• customer1-s2m
• customer1-staging
• s2dev

Enumerations Improve the Querying Experience

To illustrate enumeration use, consider the following querybuilder example:

When a user selects a filter value for a label (such as ticker), the NL process automatically retrieves all known values for that label. This provides a list of valid options for the selection, enhancing usability and reducing errors.

While users can select from the suggested values, they can also enter a custom value if needed.

Label Autopopulation

Entity storage in Selector NL processing enables automatic label population in various features. This functionality is leveraged in two situations:

1. Maintenance Window (MW) creation (covered in this section)
2. Alias resolution (covered in the next section)

Autopopulation in Maintenance Window Creation

When creating a Maintenance Window (MW), users can enable label autopopulation.

Note that:

• If enabled, when a user provides a description during MW creation, the Event Consolidator Service (ECS) queries the NL process for any detected entities.
• If a match is found in the s2_entities table, the MW is automatically assigned a label.

For example, if you create a Maintenance Window with the description

“Ticket opened for the machine 12345”

• If “12345” is a recognized router_id in s2_entities, the NL process automatically assigns a MW label router_id = 12345

This feature streamlines the MW creation process by ensuring labels are applied correctly without manual input.

Aliases and Alias Resolution

Aliases are a core feature of NL processing and enables you to create shortened, more human-readable, and easier-to-remember versions of complex S2QL queries. This simplifies query execution, making it more intuitive and user-friendly.

Example of a Basic Alias

• Alias: all kpi violations
• S2QL Equivalent: s2ap_infra_health_by_kpi as honeycomb where s2ap_infra_health_by_kpi_violation > 0 show-by kpi_name, s2_inst group-by role, kpi_name, s2_inst

Once this alias is created and saved, you can invoke the query by simply typing “all kpi violations” instead of manually entering the full S2QL query.

When a user submits a query, the Collab Service first checks for alias resolution. If an alias match is found, it is automatically converted to its S2QL equivalent before execution.

Dynamic Alias Resolution

The Selector NL process supports dynamic alias resolution, allowing aliases to include template-like placeholders for entities. These placeholders enable flexible query execution based on user input.

Example of a Dynamic Alias

• Alias: show kpi violations for {{S2_INST1}}
• S2QL Equivalent: s2ap_infra_health_by_kpi as honeycomb where s2_inst={{S2_INST1}} show-by kpi_name

In this example, the string {{S2_INST1}} acts as a dynamic placeholder that represents an entity value.

How It Works:

1. The user types: show kpi violations for s2m
2. The NL process detects the S2_INST1 placeholder and substitutes s2m in its place.
3. The final S2QL query executed: s2ap_infra_health_by_kpi as honeycomb where s2_inst=s2m show-by kpi_name

Accessing and Editing Aliases

Aliases are accessed on the UI through their settings:

When selected, a list of aliases is displayed:

Each alias contains the phrase (alias), some metadata like timestamp and creator, and finally the s2ql.

You can perform CRUD operations from this page. All CRUD operations go through the same endpoint.

One important field to note is the source field. Sources can be these types:

• Users–an alias created by the user
• Widgets–an alias created from widgets by setting name of widget as an alias and the s2ql of widget as alias s2ql

Users

S2AP has an integration function called the Natural Language Phrases List where you can edit, add, and test all aliases. This list can be found on the right-hand side of the query bar at the top:

Through the Actions button you can add an alias like this:

The first entry line is for the actual s2ql queryable. The second line gives the alias name to which the LLM maps.

Widgets

Selector uses widgets in dashboards to show all the necessary data for the customer and the deployment. Widgets form the core representation of what users want to query. For this reason, all widgets are added as aliases where the widget title is the alias name.

Because of this widget aliasing, it is important to establish a good naming convention for widgets to have a good representation of aliases. If a widget is deleted, added, or edited, this is shortly reflected on the Natural Language Phrases List.

Note that widget aliases cannot be edited on the Natural Language Phrases List editor. Therefore, if users want to change an alias of source widget, they must directly edit the main widget.

Intelligent Alias Matching

One of the key advantages of aliases is that they do not require an exact match. You can enter queries with:

• Minor misspellings
• Slight variations in wording
• Different phrasing (e.g., “violations for device” vs. “violations of device”)

NL processing intelligently matches the input to the most relevant alias and processes the query accordingly. This allows for a more flexible and user-friendly querying experience.

Limitations of Entity/Filter Matching

While alias matching is lenient, entities/filters require exact spellings (for example, router_id or s2_inst or region)

Since the NL process performs a direct substitution for these values, they must be spelled correctly and match exactly as stored in the system.

Alias Label Autopopulation

While aliases significantly streamline the query process, their manual construction can sometimes be complex or unintuitive. Users must follow specific rules when inserting template placeholders, and mistakes can result in nonfunctional aliases.

For example, if you want the alias:

“device events for devices abc and def*”*

To resolve to the following S2QL query:

device_events_ml as table where device=abc or device=def

You might struggle with how to define dynamic fields needed:

• Should you use {{DEVICE}}, {{DEVICE1}}, or {{DEVICE_1}}?
• How should it handle multiple devices (such as {{DEVICE2}})?

To address this, the NL process supports alias label autopopulation using entity recognition. Instead of requiring you to manually insert template fields, the NL process can automatically detect and normalize them as follows.

1. Create an alias with a natural language query (such as “device events for devices abc and def”) but without template placeholders.
2. Enter the corresponding S2QL query as usual.
3. The NL process scans the S2QL query for potential filter values (such as abc and def for device).
4. The NL process searches for these values in the alias text and dynamically assigns template placeholders where applicable.
5. The alias is normalized so that future queries can be processed dynamically without manual intervention.

Here is an example:

After clicking save and creating the alias, the alias page appears as follows:

This autopopulation feature is especially useful for those inexperienced with alias creation and/or dealing with aliases that are overly complex. It can also be used to test out the validity of an alias–if the NL process is not able to resolve and normalize, then this entity does not exist in the s2_entities collection.

Best Practices for NL Queries

Here is a brief list of best practices when using NL queries and aliases.

When building NL queries:

Start an existing widget:

1. Use the "NL Phrase" button for the widget.

2. Type in an NL phrase that can be used to invoke the widget. Reference any entities in the s2ql in the NL phrase, and the NL phrase is automatically generalized, such as:

    “*Show me the status of router xxx interface yyy*”

Use the query builder:

1. Get the query built as the user prefers, including filters, sorting, groups, and so on.

2. "Add Phrase"

3. For any entity filters needing to be generalized, ensure that a reference to those entities in the NL phrase.

Use Copilot to build dashboards.

When building NL Aliases:

• Make NL queries at least 3 words long.
• The NL queries should be meaningful.
• Create entity-specific NL queries so that the system learns the broader label names (a generic query is generated from a specific query from created aliases).
• Avoid semantic overlap when possible (status of devices and health of devices).
• Avoid use of phrases like Show me…, What is the…? For example, instead of using show me the status of devices, just use status of devices. The extra words should not cause problems, but it is better to limit the alias to meaningful words.