Selector AI Presents at Cloud Field Day 26

Multi-Cloud Observability with Selector

Watch on YouTube
Watch on Vimeo

In this Cloud Field Day 26 session, Reza Koohrangpour, head of product marketing at Selector, introduced the company and framed the problem it aims to solve in bringing cloud and network operations together. He explained that Selector’s founders previously led switching and routing at Juniper and that the team combines networking and AI expertise drawn from companies such as Juniper, Cisco, VMware, Google, and Nutanix. He described Selector as a networking team that built an AI platform, rather than an observability company that later discovered networking. The company has roughly 125 employees, shipped its first product in 2021, and counts Fortune 1000 organizations as about 75 percent of its customers, most of whom use it for tool consolidation, alert noise reduction, and automated incident remediation.

Koohrangpour argued that the core challenge in hybrid cloud observability is not a shortage of data but a lack of shared context. Large enterprises often run around 100 separate dashboards across network, infrastructure, application, and cloud domains, and each tool shows only its own slice of the environment. When an incident triggers tens of thousands of alerts, those alerts arrive without any connection to one another, leaving operators to correlate them manually. As a result, teams spend hours just identifying what the problem is and who owns it before any fix begins. He attributed this to the vertical pipeline design common in most tools, where metrics, logs, events, configurations, and CMDB data each have their own collector, store, and view, forcing someone to reconstruct context after the fact during high-pressure incidents.

Selector’s answer is a horizontal architecture that organizes processing by stage rather than by data type, moving from collection to normalization, then correlation and root cause analysis, and finally explainable output for the operator. The key differentiator, Koohrangpour stressed, is that every record delivered to an operator already carries topology, ownership, and maintenance context, because Selector attaches context as data moves in rather than reconstructing it as data moves out. He summarized the offering as three layers that build on one another: full-stack observability that brings cross-domain data into a single pane of glass, a shared correlation and causation layer that produces root cause insights, and Selector Foundry, an agentic runtime launched the day before the presentation that uses AI agents to investigate issues and take action.

 

Personnel: Reza Koohrangpour

The Hybrid Observability Problem, Solved with Selector

Watch on YouTube
Watch on Vimeo

Reza Koohrangpour of Selector framed hybrid cloud observability as an operational problem more than a technological one. Each cloud provider, whether AWS, Azure, or Google Cloud, brings its own services, data models, and telemetry, while the enterprise side adds SNMP and other traditional networking protocols. These domains have operated as separate silos for years, so when an incident occurs, operators must manually correlate data across them and speak every one of those languages. Koohrangpour also pointed to the cost side: every new tool adds another console, another skill set, and another integration that someone has to build and maintain by hand.

Koohrangpour argued that the largest and least discussed cost in mean time to resolution is coordination, not diagnosis. Because incidents span so many domains, teams spend time pulling in specialists, asking the cloud engineer to join the bridge and bring evidence, and working out what the problem is and who owns which piece. That effort never shows up on a dashboard. He gave three reasons the problem persists. First, application paths constantly shift across data centers, cloud, and on-premises networks, so there is no reliable dependency map, and the topology an operator sees is often a week old and unrelated to the current incident. Second, there are many potential failure points, including accounts, service accounts, regions, VPCs, and transit, with the gaps between them, such as transit gateways and interconnects, being the hardest to troubleshoot because nobody clearly owns them. Third, providers lack a standard data model.

He then explained why existing tools have not closed this gap, attributing it to the lack of a unifying standard in three areas. Constructs differ across platforms, so an operator investigating a single Kubernetes incident may need to navigate GKE, AKS, EKS, OpenShift, and Nutanix terminology. Data models also diverge: Azure organizes around resource groups, AWS around accounts, and Google Cloud around projects, making even a simple operational question hard to answer consistently. Logs add further friction, arriving as syslog, pub/sub messages, or query results, in varying versions, formats, and locations, which slows any investigation. The transcript ends after this problem statement, before Koohrangpour describes how Selector’s platform addresses these challenges.

Personnel:

An Operational Model for Cloud Agentic Applications with Selector

Watch on YouTube
Watch on Vimeo

In this Cloud Field Day 26 session, Sirish Kondi, who leads the data infrastructure team at Selector, walked through the engineering behind the platform’s hybrid cloud capabilities using a scenario in which an on-call engineer is alerted that a Dallas application is no longer reachable. On-premises environments offer natural boundaries such as sites and data centers where ownership can be assigned, but cloud architectures are flat, with VPCs, subnets, VMs, and routers all at the same level, making it harder to know who should look first. If a BGP session between the two environments fails, the on-premises team receives an SNMP trap and the cloud team receives an unreachability notification, yet nothing ties the two together. To close that gap, Selector built five additions modeled on its existing on-premises tooling: a cloud collection engine, a uniform naming convention, grouping into constructs, a cloud alarm engine, and query access through its agents.

Kondi explained that cloud collection works in two ways. Selector polls provider APIs to build performance trends, but rate limits restrict polling frequency, so short-lived events can slip between intervals. It therefore also subscribes to provider-generated events and alerts, which caught a link-down event in his example that polling missed, although a brief spike to 92 percent interface utilization went undetected. Because provider resource IDs reveal little about which cloud, account, or region they belong to, Selector assigns each resource a normalized name composed of cloud, account, region, and type, followed by the native ID, in a format that works the same way across AWS, Google Cloud, and Azure. That structure turns a question like “what happened in this region” into a simple prefix match. Resources are then organized into constructs such as VPC, WAN edge, compute, Kubernetes, and security perimeters, which customers can extend with their own groupings such as GPUs. Each construct is defined by what can be measured on it, such as CPU, memory, disk, and uptime for compute or address space, routes, and quotas for a VPC, so an incoming alarm arrives already tied to a construct and a team to engage.

The alarm engine normalizes the different event models of Google Cloud Monitoring, Google Cloud audit logs, and AWS CloudWatch using the same naming format, then links each alarm back to the affected resources, so an on-premises SNMP trap and a cloud alarm triggered by the same BGP failure are recognized as one event. Selector’s Rosetta agent now has about 18 cloud-specific tools and works with external LLMs to build queries against this curated data, answering questions like why an application is unreachable when its VM appears healthy or which interconnects currently have BGP sessions down. In response to a delegate asking what happens when the root cause lies in an uncollected source, Kondi said Selector inventories all resources it has permission to read, such as every project in a Google Cloud account, and lets customers exclude items rather than having to list everything that should be monitored, which helps expose coverage gaps. Selector also builds a deterministic path between on-premises and cloud resources by combining VPC route tables, hub route tables, and router BGP tables. Returning to the Dallas scenario, Kondi showed how the platform traces the problem through interconnect data, normalized names, constructs, and alarms to pinpoint the WAN edge as the source, so that the team can take over.

Personnel: Sirish Kondi

Troubleshooting Application Reachability in a Hybrid Cloud Demonstration by Selector

Watch on YouTube
Watch on Vimeo

John Heintz, who leads Selector’s pre-sales engineering team, demonstrates how an operator would use the platform to troubleshoot application reachability problems whose causes are hidden across hybrid infrastructure. In the first scenario, an operator named Michael receives a Slack alert (ServiceNow or another ticketing tool would work the same way) reporting that an application called Cloud Field Day is unreachable from one probe, likely because of firewall drops at the VPC level, while the interconnects appear healthy. Heintz clarified that Selector itself, not the LLM, identifies the cause by detecting anomalies such as firewall drop rates deviating from their baseline, and the LLM only renders the collected data into readable text and recommendations, optionally drawing on company runbooks. Following the alert’s link into the portal, the operator sees that the VM is up, that Selector’s PingMesh probe shows the application unreachable, and that a firewall rule edit denying traffic from an IP range sits on the path between probe and application. Anomaly thresholds can be static values or machine learning baselines tuned per metric, with ML favored for drops, utilization, errors, and discards. Heintz noted that Rosetta routes requests to specialized agents, so keywords like “debug” or “root cause” prompt the Loom investigation agent to run a full analysis while simpler questions get direct answers.

Heintz then showed the same incident investigated conversationally, asking Rosetta step by step about reachability, the cloud path, and interconnect health, with each answer drawing on different skills. Delegates asked whether the system learns from repeated investigations, and Heintz explained that users can refine answers through feedback, which builds new skills on the fly, while a thumbs-down rating and pre-deployment QA with expected responses help keep answers accurate. Conversations are stored and can be queried later, such as asking how a colleague fixed an issue last week, and multi-user conversations are in development. Before enabling agentic features, Selector builds a metadata store of customer application names, site names, locations, and terminology, continuously refreshed through APIs to tools such as ServiceNow, Dynatrace, and AppDynamics, and it can ingest Confluence pages and Visio diagrams. He pointed out where the LLM added genuine value, explaining that Google firewall rules are evaluated strictly by priority, and showed that a single generic “debug” prompt runs the entire multi-step investigation at once. Investigations rely mainly on ingested data but can use MCP to fetch information at runtime, and Rosetta can take corrective actions if granted permissions under its own service identity, though most customers keep accounts read-only and route changes through partners such as Itential with a human in the loop.

The second scenario involved an application in Chicago whose VMs were healthy but unreachable because two BGP sessions had dropped, removing the routes to the application even though the physical layer was fine. Heintz emphasized that the dashboard widgets are generated dynamically from the devices and events in each incident, and that stitching together data plane and control plane information helps separate application, infrastructure, network, and cloud teams avoid the usual all-hands bridge call. Asked whether Selector could detect provider outages before AWS acknowledges them, he said the platform ingests cloud provider health dashboards but doesn’t correlate data across customers, though a delegate’s suggestion to run Selector-owned probes across regions to create a shared signal was welcomed as a good idea. For on-premises deployments, Rosetta can use a customer’s approved LLM instead of the default Gemini by plugging in its endpoint and key, with per-customer prompt templates to handle model quirks, and it works across languages. Heintz noted that Rosetta has been available for only about six months, and the platform functions fully without it. He closed by describing how Rosetta can triage on-premises networks, cloud networks, and cloud applications in a single investigation, and how carrier data can even connect a root cause like a fiber cut to the construction crew that caused it.

Personnel: John Heintz