Facing a data-related challenge? Explore some of the most common issues and discover how we can help you tackle them, gain deeper insights from your data, and find practical solutions.
Edge fleet observability and operations
Edge environments span devices, infrastructure, applications, and workloads across multiple locations. Q-Sensei connects their operational data to help you monitor fleet health, investigate issues, optimize resources, and coordinate edge operations.Learn more
How can we understand the operational state of the entire edge fleet?
The challenge
When I manage devices across many locations, I need to understand the condition of the entire fleet as well as individual devices. I want to identify offline devices, degraded performance, and unusual workload behavior, and determine whether an issue is isolated or part of a wider operational pattern.
How Q-Sensei helps
Q-Sensei helps you examine your edge fleet through device inventory, topology information, and multi-dimensional operational analysis. You can explore individual devices, compare behavior across device groups, and investigate events in the context of their infrastructure, applications, and workloads. Entity and relationship discovery can help reveal connections across operational data.
You can move from a fleet-level view to the operational details of a specific device, workload, or location. This gives you a clearer picture of fleet status and helps you identify where further investigation or intervention may be needed.
Find the exception within its fleet context
Fleet · 8 devices in 2 groups · Snapshot at 10:00
North · Sensor group
N01Reporting
N02Review alert
N03Reporting
N04Stale · 09:20
South · Gateway group
S01Reporting
S02Reporting
S03No report
S04Reporting
6 of 8 devices reported within the last 5 minutes, including N02 with an alert. N04 is stale; S03 has no report in this snapshot.
A stale or missing report leaves the device’s current state unknown. Sample data.
Data typically used in this investigation
Device inventory and identifiers
Identify devices, gateways, hardware types, and their attributes. They provide the basis for understanding fleet composition and comparing device groups.
Device and infrastructure telemetry
Records device health, resource utilization, and infrastructure performance. It helps you assess the operational condition of individual devices and locations.
Application and workload status
Describes the applications and workloads running across the fleet. It helps you understand which services are operating and where issues may affect local operations.
Network and connectivity data
Records connection status, communication activity, and network performance. It helps you identify connectivity differences and their impact across locations.
Device locations, groups, and topology information
Describes where devices operate and how components are connected. It helps you compare sites and understand dependencies across the fleet.
Logs, events, and historical operational records
Document device activity, alerts, and previous operational conditions. They help you identify recurring patterns and changes over time.
Which edge devices need maintenance attention?
The challenge
Devices operating at different locations experience different workloads, environmental conditions, and levels of physical wear. I need to recognize gradual deterioration, intermittent errors, and unusual behavior early, compare current conditions with historical performance and maintenance records, and prioritize attention across the distributed fleet.
How Q-Sensei helps
Q-Sensei helps you analyze current and historical operational data to identify changes in device and infrastructure conditions. You can compare performance trends, resource utilization, application behavior, events, and maintenance histories across devices and locations. Anomaly detection and AI-assisted contextual analysis, where configured, can help highlight unusual behavior and identify devices that may warrant attention.
You can investigate developing patterns and compare devices with similar operating conditions. This gives you a stronger evidence base for prioritizing maintenance activities and deciding where further inspection may be needed.
Compare changing conditions with similar devices
Temperatures · Same hardware group and 0–100 °C scale · 09:00–10:00, every 15 minutes
Dashed band: historical 45–55 °C range for this group, 09:00–10:00 over the previous 7 days
Check workload, ambient conditions and maintenance history for the device running above its peers. Sample data.
Data typically used in this investigation
Device health and performance metrics
Measure device status, uptime, CPU and memory utilization, and storage and network performance. They help you identify changes that may indicate deteriorating device conditions.
Application and workload behavior
Records application status, workload activity, and runtime performance. It helps you assess whether device issues are affecting local applications or services.
Error logs and operational events
Document errors, warnings, restarts, and other unusual activity. They help you identify recurring problems and investigate changes in device behavior.
Temperature and environmental readings
Record operating temperatures and relevant environmental conditions. They help you assess whether external conditions may contribute to device degradation.
Maintenance and repair records
Document previous inspections, repairs, replacements, and maintenance activities. They help you compare current conditions with earlier issues and maintenance history.
Historical performance and utilization trends
Provide records of device behavior over time. They help you distinguish gradual deterioration from isolated operational events.
Where are connectivity problems affecting edge operations?
The challenge
When devices or gateways lose connectivity, I need to understand which locations and workloads are affected and whether the problem is isolated or part of a wider network issue. I want to distinguish network problems from device or application failures and assess how connection quality affects communication, data synchronization, remote monitoring, and local operations.
How Q-Sensei helps
Q-Sensei helps you analyze network and connectivity information alongside device telemetry, infrastructure metrics, application activity, and operational events. You can compare connection status, latency, communication failures, and network behavior across devices and locations, and investigate how connectivity issues relate to affected workloads and services.
By exploring relationships between network components, devices, and applications, you can narrow down the scope of connectivity problems and identify recurring patterns. This makes it easier to understand which locations and operations are affected and where further network investigation is needed.
Compare connection evidence and affected operations across locations
Observations · 10:00–10:10 · 100 network probes per location
North · Gateway G01
Network evidence
12 of 100 probes lost
Remote operation
Synchronization retries recorded at 10:06
Local evidence
Local workload activity recorded at 10:06
South · Gateway G02
Network evidence
0 of 100 probes lost
Remote operation
Synchronization completed at 10:06
Local evidence
Local workload activity recorded at 10:06
Each box represents one probe; heavier outlines mark lost probes. Both locations were probed over the same interval.
Investigate the North communication pathCheck gateway and network records against synchronization logs before attributing the retries.
When a remote report is missing, use local records to check whether the workload kept running. Sample data.
Data typically used in this investigation
Network connectivity and availability records
Document connection status, availability, and communication interruptions. They help you identify affected devices, gateways, and locations.
Latency, bandwidth, and throughput metrics
Measure network response times and data transfer performance. They help you assess whether network conditions may be affecting applications and workloads.
Network topology and configuration
Describe network components, connections, and relevant settings. They help you investigate dependencies and understand how connectivity problems may spread.
Device and gateway telemetry
Records device status, communication activity, and gateway performance. It helps you distinguish device-level issues from broader network problems.
Application and service logs
Document application communication, connection errors, and service availability. They help you assess the impact of network problems on local operations.
Historical alerts and incident records
Document previous connectivity issues and their operational impact. They help you identify recurring problems and compare affected locations over time.
What is causing performance and reliability issues at an edge location?
The challenge
When an edge application becomes slow, a device disconnects, or a workload stops responding, I need to determine whether the issue originates in the device, infrastructure, application, network, or a dependent system. Because operational evidence is distributed across local logs, infrastructure metrics, application traces, and remote management systems, I need to correlate these signals and understand which components and workloads are affected.
How Q-Sensei helps
Q-Sensei helps you investigate operational issues across devices, infrastructure, applications, and workloads. You can examine performance metrics, distributed traces, session activity, logs, and events in their wider operational context. Comparing behavior across devices and locations, and exploring historical data, helps you assess whether an issue is isolated or recurring.
AI-assisted analysis and root-cause investigation, where configured, can help you examine possible contributing factors and prioritize further troubleshooting. You gain a more complete view of how different components relate to an issue, making it easier to move from an alert or device-level symptom to a focused investigation.
Follow the affected path and inspect the evidence
Path · Shared investigation window: 10:00–10:10
Device N02Hosts workload W12
Gateway G01Forwards traffic from N02
Network link L03Connects G01 to service A
Workload W12Depends on service A
Inspect link L0318 of 100 probes lost during 10:00–10:10.
Each box represents one probe; heavier outlines mark lost probes.
Workload evidenceW12 trace records a timeout reaching service A at 10:06.Evidence gapG01’s last telemetry report is 09:40; its current condition is unknown.
Compare the network evidence with device, gateway and workload records before attributing the slowdown. Sample data.
Data typically used in this investigation
Device and gateway telemetry
Records device health, resource utilization, and gateway activity. It helps you investigate whether problems originate in local devices or infrastructure.
Network connectivity and latency
Measures connection status, communication delays, and network performance. It helps you assess whether network conditions contribute to application or workload problems.
Infrastructure performance metrics
Measure compute, memory, storage, and other infrastructure resources. They help you identify resource constraints and potential performance bottlenecks.
Application logs and distributed traces
Document application activity, requests, and interactions between services. They help you investigate where delays, errors, or failures occur.
Workload runtime and error records
Describe workload execution, resource consumption, and runtime failures. They help you understand how individual workloads behave when problems arise.
Configuration, topology, and incident history
Document device settings, component relationships, and previous incidents. They help you investigate dependencies and compare current problems with earlier events.
Are edge devices and workloads secure and compliant?
The challenge
When I operate devices across many locations, I need to know whether they meet our security requirements and whether access to devices, applications, and data is properly controlled. I want to identify security-related deviations, investigate suspicious activity, and understand whether different configurations, software versions, and levels of network exposure create risks for devices, workloads, or business processes.
How Q-Sensei helps
Q-Sensei helps you connect device and workload activity with relevant identity, access, configuration, vulnerability, and security information. You can examine device inventories, access records, software versions, security events, and policy requirements in a shared operational context. Where the relevant information is available, you can compare device configurations and patch status with defined security requirements.
You gain a broader view of security-related activity across the edge fleet and can investigate potential exposure, policy deviations, and recurring exceptions. This supports more informed security assessments and helps you prioritize issues that require further review or action.
Assess a defined requirement against the evidence available
Evidence · Sensor hardware group · Assessment snapshot at 10:00
Defined requirement: patch P4Compare the available patch record for each device with this group's requirement.
N01P4 · reported 09:59Matches the examined patch requirement
N02P3 · reported 09:58Deviation requires review
N03No patch report availableInsufficient evidence to assess
Extend the assessment with relevant recordsIdentity and access · Vulnerability information · Network exposure · Security events
This check covers the patch requirement. Assess access and exposure against their own requirements. Sample data.
Data typically used in this investigation
Device identities and access records
Document device identities, users, roles, permissions, and access activity. They help establish which devices and identities can access specific systems and resources.
Security policies and compliance requirements
Define requirements for device configuration, access, and operational security. They provide criteria for assessing whether devices and workloads meet organizational expectations.
Software versions and vulnerability records
Identify installed software and known security vulnerabilities. They help you investigate potentially exposed devices and prioritize patching or further assessment.
Configuration and patch status
Record device settings, security configurations, and installed updates. They help you identify deviations from intended security baselines.
Security logs and operational events
Document authentication activity, suspicious events, and reported security incidents. They help you investigate unusual behavior and understand its operational context.
Network and device exposure information
Describe network connections, access paths, and device communication. They help you assess how devices are exposed and which connected components may be affected.
Are edge workloads using available resources efficiently?
The challenge
Edge devices often have limited compute, memory, storage, and network capacity, while applications and AI workloads compete for resources across locations. I need to understand how resources are allocated and consumed, identify underused capacity, and find out where contention affects performance by comparing workload behavior with device capabilities and available resources.
How Q-Sensei helps
Q-Sensei helps you analyze resource consumption and workload runtime data across your edge fleet. You can compare CPU, memory, storage, network, and accelerator usage with workload activity, and examine how resource demand varies between devices and locations. Multi-dimensional analysis helps you identify underutilized resources and investigate contention.
By relating workload behavior to device capabilities and available capacity, you can assess resource allocation across the fleet. This makes it easier to identify utilization improvements and evaluate them alongside application and workload performance.
Compare assigned memory with observed demand
Memory comparison · Common 0–8 GiB scale · Mean usage during 10:00–10:10
Outline: allocated · Filled: observed usage · GiB means gibibytes
N01 · Workload A6 GiB allocated · 2 GiB used
N02 · Workload B6 GiB allocated · 5 GiB used
N03 · Workload C4 GiB allocated · 3 GiB used
Review N01’s allocation in contextCompare workload requirements and earlier demand before interpreting the gap as spare capacity.
Use the same resource, units and observation window, then examine workload requirements before changing allocations. Sample data.
Data typically used in this investigation
Device inventory and hardware capabilities
Describe device specifications, compute capacity, and available accelerators. They help you compare workload requirements with the resources available on each device.
CPU, memory, and accelerator metrics
Measure compute utilization and resource consumption. They help you identify workloads that use substantial capacity or compete for limited resources.
Storage capacity and usage
Record available storage, consumption, and performance. They help you identify storage constraints and underutilized capacity.
Network bandwidth and throughput
Measure network resource usage and transfer performance. They help you understand how communication demands affect workload operations.
Workload inventory and runtime metrics
Document running workloads, their resource consumption, and execution behavior. They help you compare resource demand across applications and locations.
Resource allocation and historical utilization records
Describe how resources are assigned and how their usage changes over time. They help you identify imbalances and evaluate opportunities to improve utilization.
Where should workloads run across the edge fleet?
The challenge
Edge workloads have different requirements for compute, accelerators, storage, connectivity, and proximity to local data or devices. I need to compare these requirements with device capabilities and availability across the fleet, while accounting for changing resource conditions, application dependencies, network performance, and operational policies.
How Q-Sensei helps
Q-Sensei helps you analyze workload requirements alongside device capabilities, resource availability, application dependencies, network conditions, and operational policies. You can compare the resource fit of workloads across different device environments and investigate constraints that may affect placement, performance, or utilization.
AI-assisted workload placement recommendations, where configured, can help you evaluate alternatives using the available operational context. You gain a stronger basis for deciding where workloads should run and assessing how placement changes may affect the wider fleet.
Check resource fit and local dependencies together
Workload W12 requirements2 CPU cores · 4 GiB memory · 8 GiB storage · Sensor feed D04 must stay at North · Dependency: service A
Candidate snapshot at 10:00 · Connectivity observations cover 09:50–10:00
North gateway
Available resources
4 CPU cores · 6 GiB memory · 12 GiB storage
Local data
D04 remains local
Dependency connectivity
2 of 100 probes to service A lost
Review intermittent connectivity
South gateway
Available resources
8 CPU cores · 8 GiB memory · 24 GiB storage
Local data
D04 would cross locations
Dependency connectivity
0 of 100 probes to service A lost
Does not meet the local-data requirement
CPU: central processing unit · GiB: gibibytes.
North keeps the sensor feed local but lost two probes to service A. Review that connection before recommending placement under the configured policy. Sample data.
Data typically used in this investigation
Workload requirements and configuration
Describe the compute, memory, storage, accelerator, and runtime requirements of workloads. They help you assess which device environments are suitable for each workload.
Device hardware and accelerator capabilities
Document device specifications and available processing resources. They help you compare workload requirements with the capabilities of potential host devices.
Compute, memory, and storage availability
Record the resources available across devices and locations. They help you identify placement constraints and available capacity.
Network topology and latency
Describe network connections and communication performance between components and locations. They help you assess connectivity requirements and the impact of workload placement on communication.
Application dependencies and local data requirements
Identify the services, systems, and data that workloads depend on. They help you evaluate whether a proposed placement can meet application and data proximity requirements.
Resource utilization, orchestration records, and placement policies
Document current resource consumption, workload assignments, and applicable placement constraints. They help you assess alternative placements in the context of existing operations.
How can we manage software updates and changes across the edge fleet?
The challenge
When I manage software and workloads across a distributed fleet, I need to know which devices are running which versions and whether updates have been applied consistently. I want to track deployment progress, identify devices that have missed or failed updates, and understand whether changes have affected local applications and workloads, particularly when connectivity interruptions and hardware differences complicate rollouts.
How Q-Sensei helps
Q-Sensei helps you analyze software versions, device configurations, deployment records, and update histories across your edge fleet. You can compare devices by location, hardware type, application, or software version, and investigate deployment status and configuration differences alongside operational performance.
You can relate changes to device health, workload behavior, and operational events to identify potential issues following updates. This provides a clearer basis for reviewing deployment consistency, prioritizing devices that need attention, and assessing the impact of software and configuration changes.
Connect version differences with deployment and outcome records
Records from connected systems · Snapshot at 10:10 · Expected configurations are specific to each hardware group
Sensor group · North
Intended: Software 3.2 · Model M4 · Config C7
Observed: software / model / configuration
N013.2 / M4 / C7
Matches · reported 09:59Deployment completed at 09:55Workload completion recorded at 10:04
N023.1 / M4 / C6
Review difference · reported 09:58Deployment failure recorded at 09:54Workload error recorded at 10:04
Gateway group · South
Intended: Software 5.0 · Model M2 · Config G3
Observed: software / model / configuration
S015.0 / M2 / G3
Matches · reported 09:59Deployment completed at 09:57Workload completion recorded at 10:06
S024.9 / M2 / G2
Stale · last report 08:00Deployment awaiting device contactCurrent workload outcome unknown
Compare the reported version with its deployment record. Use the last report time to spot devices that need a fresh reading. Sample data.
Data typically used in this investigation
Device inventory and hardware profiles
Identify device types, hardware capabilities, and locations. They help you group devices and understand which software and configurations apply to each group.
Operating system, firmware, and software versions
Record the versions installed on individual devices. They help you identify outdated, inconsistent, or unexpected software across the fleet.
Application and model versions
Identify the versions of applications, AI models, and workloads running on devices. They help you compare deployment consistency and investigate version-related behavior.
Device and workload configurations
Document settings and parameters applied to devices and workloads. They help you identify configuration differences and deviations from intended settings.
Deployment and update histories
Record rollout activity, deployment status, and update outcomes. They help you investigate incomplete or unsuccessful updates across locations.
Change, performance, and incident records
Document configuration changes alongside operational behavior and reported issues. They help you assess whether changes coincide with performance degradation or other problems.
How can we coordinate operational actions across the edge fleet?
The challenge
When an issue affects devices or workloads across multiple locations, I need to identify affected components, assess the impact, and coordinate an appropriate response. I also need to ensure that actions follow operational policies, account for local conditions, receive human approval where necessary, and achieve their intended results without creating further issues.
How Q-Sensei helps
Q-Sensei helps you use connected operational data to investigate conditions, support decisions, and coordinate responses across distributed edge environments. You can analyze signals from devices, applications, infrastructure, and workloads to understand the situation and identify relevant operational patterns. Where configured integrations are available, automated orchestration and decision workflows can support actions across connected systems.
Configurable autonomy levels, risk-based assessments, human approvals, escalations, and exception handling can help determine when actions may proceed and when oversight is required. Depending on your integrations, permissions, and deployment scope, workflows may support actions such as adjusting workloads, changing configurations, or initiating incident-response processes. Action histories and outcome analysis help you assess the results of those responses.
Keep the evidence and controls with the action
Proposed configuration change for device N02
01
Issue and evidenceReview the affected workload, current device reports and related events.
02
Policy and permission checksCheck scope, risk and configured safeguards before choosing a response.
03
Approval where requiredPause for the configured reviewer; escalate exceptions or deny the action when checks fail.
04
Controlled executionProceed only through configured integrations and within permitted deployment scope; record the step and any exceptions.
05
Outcome reviewCheck action logs for the outcome and any exceptions.
Review the action log to see whether the proposed change was approved, escalated or carried out.
Data typically used in this investigation
Device and workload status
Record the operational condition of devices and running workloads. They help establish which components may require an operational response.
Operational events and alerts
Document detected issues, warnings, and changes in operating conditions. They help identify situations that may require investigation or action.
Infrastructure and application telemetry
Measure infrastructure conditions and application behavior. They help you assess the impact of an issue and determine which components may be affected by a response.
Operational policies and permissions
Define the rules, authorization requirements, and restrictions governing operational actions. They help you assess whether proposed actions are permitted and require approval.
Orchestration and workflow records
Document coordinated processes and actions across connected systems. They help you understand how operational responses are initiated and executed.
Action, approval, and escalation logs
Record actions taken, human decisions, and exceptions. They help you trace operational responses and understand how oversight requirements were handled.
Incident histories and action outcome metrics
Document previous incidents and the results of operational actions. They help you compare responses and assess whether intended outcomes were achieved.
How can we improve operational consistency across edge locations?
The challenge
As our edge fleet grows, devices and workloads at different locations can develop different operating conditions and performance patterns. I need to compare sites, understand why some perform differently, and identify deviations from expected operating conditions by examining device health, resource utilization, incidents, configurations, and local operating practices.
How Q-Sensei helps
Q-Sensei helps you compare operational data across edge locations, device groups, and workload environments. You can analyze differences in device health, resource utilization, application behavior, configurations, and incident patterns, and explore relationships between local infrastructure and operational outcomes.
By identifying recurring patterns and differences between sites, you can investigate where operating conditions or practices may be affecting results. This gives you a stronger basis for prioritizing improvements and supporting more consistent operations across distributed environments.
Compare operational outcomes for equivalent workloads at two sites
Comparison · Same hardware profile and workload · 10:00–11:00 · 100 requests per site
Mean response time · Common 0–100 ms scale · ms means milliseconds
North · Workload W12
Mean response time
20 ms across 100 requests
Requests with recorded errors
2 of 100 requests
South · Workload W12
Mean response time
40 ms across 100 requests
Requests with recorded errors
8 of 100 requests
Investigate the difference in contextCompare resource demand, environmental conditions, maintenance records, configurations and local procedures.
Compare site conditions and operating practices where the same workload shows different response times or error counts. Sample data.
Data typically used in this investigation
Device inventory and location information
Identify device types, hardware profiles, and the sites where they operate. They help you compare similar devices and understand differences between locations.
Infrastructure and environmental metrics
Record resource availability, performance, and local operating conditions. They help you investigate how infrastructure and environmental differences affect operations.
Application and workload performance
Measure application behavior, workload execution, and resource consumption. They help you compare operational outcomes across sites and device groups.
Configuration and software records
Document device settings, software versions, and workload configurations. They help you identify differences that may contribute to inconsistent operations.
Operational events and incident histories
Record alerts, failures, and previous incidents across locations. They help you recognize recurring issues and compare reliability between sites.
Maintenance and operational records
Document maintenance activities, changes, and relevant site procedures. They help you understand how operational practices relate to differences in fleet performance.
Improve visibility and coordination across your edge operations
Q-Sensei connects operational data across devices, infrastructure, applications, workloads, and locations, giving you the context to understand fleet behavior, investigate problems, and identify opportunities to improve distributed operations.
