Available Metrics

The RAI Native App exposes observability views across two schemas, each with different stability expectations:

Schema	Purpose and Expectations
<rai_app_database>.OBSERVABILITY	Stable views intended for production use. These views follow strict schema contracts. Columns will not be removed or renamed without advance notice.
<rai_app_database>.OBSERVABILITY_PREVIEW	Experimental views for new or evolving metrics. These views may change at any time without notice. Columns can be added, removed, renamed, or have their semantics altered.

Important

Only views in the OBSERVABILITY schema carry stability guarantees. Views in OBSERVABILITY_PREVIEW are provided for early access and evaluation only.

To discover all available views in each schema:

-- Stable views
SHOW VIEWS IN SCHEMA RELATIONALAI.OBSERVABILITY;

-- Preview views
SHOW VIEWS IN SCHEMA RELATIONALAI.OBSERVABILITY_PREVIEW;

The following sections describe the currently available preview views for the Logic Reasoner Utilization.

3.1 Reasoner Memory Utilization

Reports the memory utilization for each reasoner instance.

SELECT * FROM relationalai.observability_preview.logic_reasoner__memory_utilization
WHERE timestamp >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

Schema:

Column	Type	Description
TIMESTAMP	TIMESTAMP_NTZ	When the measurement was taken (UTC)
REASONER_ID	VARCHAR	Unique reasoner identifier
REASONER_NAME	VARCHAR	Name of the reasoner
MEMORY_UTILIZATION	FLOAT	Memory utilization as a ratio (0.0–1.0)
ATTRIBUTES	OBJECT	Additional reasoner attributes

3.2 Reasoner CPU Utilization

Reports the CPU utilization for each reasoner instance.

SELECT * FROM relationalai.observability_preview.logic_reasoner__cpu_utilization
WHERE timestamp >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

Schema:

Column	Type	Description
TIMESTAMP	TIMESTAMP_NTZ	When the measurement was taken (UTC)
REASONER_ID	VARCHAR	Unique reasoner identifier
REASONER_NAME	VARCHAR	Name of the reasoner
CPU_UTILIZATION	FLOAT	CPU utilization as a ratio (0.0–1.0)
ATTRIBUTES	OBJECT	Additional reasoner attributes

3.3 Reasoner Demand

Reports the job demand for each reasoner instance.

SELECT * FROM relationalai.observability_preview.logic_reasoner__demand
WHERE timestamp >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

Schema:

Column	Type	Description
TIMESTAMP	TIMESTAMP_NTZ	When the measurement was taken (UTC)
REASONER_ID	VARCHAR	Unique reasoner identifier
REASONER_NAME	VARCHAR	Name of the reasoner
DEMAND	FLOAT	Job demand as a ratio (0.0+); values above 1.0 indicate queuing
REASONER_CAPACITY	VARCHAR	Capacity tier of the reasoner
ATTRIBUTES	OBJECT	Additional reasoner attributes

Note

The ATTRIBUTES column across all views is an evolving OBJECT that may contain additional metadata about the reasoner. Its contents may change across releases with several months notice for the stable views.

3.4 Recommended Actions

Utilization can be somewhat spiky, so focus on the pattern across your workload runs rather than individual data points. The key question is: does almost every run of your workload exceed the threshold?

Single-Metric Recommendations

Observation	Threshold	Action	Reasoning
High memory utilization runs	MEMORY_UTILIZATION > 0.8 on most workload runs	Consider upgrading to a larger reasoner	Consistently high memory usage limits performance; a larger reasoner provides more headroom
High CPU utilization	CPU_UTILIZATION consistently > 0.95	Consider upgrading to a larger reasoner	CPU-bound workload; a larger reasoner improves performance
Sustained high CPU utilization	CPU_UTILIZATION consistently 0.85–0.95	Plan to resize before next traffic spike	Limited headroom for growth or traffic bursts
No demand	DEMAND = 0 for extended periods	Consider shutting down or reducing auto_suspend threshold	Running unused capacity
Queuing	DEMAND consistently > 1.0	Review job volume; if higher concurrency is needed, consider sending different jobs to different reasoners	More jobs than available slots in the queue. Evaluate why job volume is high.

Combined-Metric Recommendations

Observation	Thresholds	Action	Reasoning
Underutilization	CPU_UTILIZATION < 0.30 AND MEMORY_UTILIZATION never exceeds 0.30 across workload runs	Consider downgrading to a smaller reasoner	You are paying for capacity you are not using; a smaller reasoner may be more cost-effective
Reaching hard limits	CPU_UTILIZATION = 1.0 AND MEMORY_UTILIZATION = 1.0 AND DEMAND > 1.0	Upgrade to a larger reasoner immediately	Reasoner is approaching hard limits across all dimensions