Getting Started

Setting up observability views involves five steps: identifying your active event table, creating a dedicated schema, creating a filtered events view, registering it with the app, and validating the configuration.

2.1 Identify the Active Event Table

Before creating the RAI events view, you need to determine which event table is currently active in your Snowflake account. Each account can have one active event table at a time, and your view must reference it.

Run the following command to check your active event table:

SHOW PARAMETERS LIKE 'EVENT_TABLE' IN ACCOUNT;

This returns the fully qualified name of the active event table (e.g., my_db.my_schema.my_event_table) under the value column. If the default Snowflake-managed event table is active, the value will be SNOWFLAKE.TELEMETRY.EVENTS.

If no event table is set, you may need to configure one. To set the default Snowflake event table:

ALTER ACCOUNT SET EVENT_TABLE = 'SNOWFLAKE.TELEMETRY.EVENTS';

Important

You must have ACCOUNTADMIN privileges or equivalent to view or modify the account level event table setting. If you do not have access, contact your Snowflake account administrator.

Tip

Make note of the event table name returned. You will use it in Step 2.3 when creating the RAI events view. The SQL templates in this guide use SNOWFLAKE.TELEMETRY.EVENTS as the default.

Verify that change tracking is enabled:

Change tracking must be enabled on the event table for the observability views to support streams and incremental processing. Check the current setting:

SHOW TABLES LIKE '<event_table_name>' IN SCHEMA <database>.<schema>;

Look for the change_tracking column in the output. If it is set to OFF, enable it:

ALTER TABLE <database>.<schema>.<event_table_name>
 SET CHANGE_TRACKING = TRUE;

Important

Enabling change tracking on the event table requires ownership or appropriate privileges on the table. If you are using the default SNOWFLAKE.TELEMETRY.EVENTS table, change tracking may already be enabled. Verify before proceeding.

2.2 Create a Dedicated Schema

We recommend creating a dedicated schema to hold the RAI observability events view. This keeps your observability configuration organized and makes it easier to manage permissions separately from other database objects.

CREATE DATABASE IF NOT EXISTS <your_database>;
CREATE SCHEMA IF NOT EXISTS <your_database>.rai_observability;

Replace <your_database> with the database of your choice. You can use an existing database or create a new one. The schema name rai_observability is a recommendation, you may use any name that fits your organization’s conventions.

2.3 Create the RAI Events View

Create a view in the dedicated schema that filters the Snowflake Event Table to include only RAI related metrics. This view is entirely under your control and determines what telemetry the app can access.

Use the event table identified in Step 2.1 and the schema created in Step 2.2.

Run the following SQL to create your RAI events view:

CREATE OR REPLACE SECURE VIEW <your_database>.rai_observability.rai_obs
COMMENT = 'RelationalAI Native App Observability: This view
 provides filtered event data for RelationalAI observability
 and is registered within the Native App.
 Please refrain from changing or deleting.'
CHANGE_TRACKING = TRUE
AS
SELECT
 timestamp,
 value,
 record,
 record_attributes
FROM <event_table>
WHERE record_type = 'METRIC'
 AND resource_attributes['snow.database.name']::STRING = '<rai_app_name>'
 AND record_attributes['snow.application.shared']::BOOLEAN = TRUE
 AND timestamp >= '<start_date>';

Replace the following placeholders with your actual values:

• <your_database> — the database where you created the rai_observability schema in Step 2.2
• <event_table> — the fully qualified event table name identified in Step 2.1 (e.g., SNOWFLAKE.TELEMETRY.EVENTS)
• <rai_app_database> — the database name of your RAI Native App installation (e.g., RELATIONALAI)
• <start_date> — use your current date (e.g., 2026-02-01)

If you used a different schema name in Step 2.2, replace rai_observability accordingly.

Key elements of this view definition:

• SECURE VIEW: Hides the view definition from non-owners, recommended for production
• CHANGE_TRACKING = TRUE: Enables stream-based incremental processing on the view, which is required for the observability views to function correctly
• record_attributes[‘snow.application.shared’]::BOOLEAN = TRUE: Filters to only include metrics that are explicitly shared with the provider
• Explicit column selection: Only the columns required by the observability views are selected. This ensures the app does not gain access to any event table data that is not shared with the provider, keeping your telemetry exposure minimal and governed

Required columns in the view:

The view must include at minimum the following columns:

Column	Type	Description
timestamp	TIMESTAMP_NTZ	When the event occurred (UTC)
value	VARIANT	Primary measurement value
record	VARIANT	Telemetry record data (includes metric name)
record_attributes	OBJECT	Event-specific attributes and measurements

2.4 Register the View

After creating the view, register it with the RAI Native App using the registration procedure. This binds your view as the telemetry source and validates its structure.

CALL <rai_app_>.app.REGISTER_EVENTS_VIEW(
 SYSTEM$REFERENCE('view', '<your_database>.rai_observability.rai_obs',
 'PERSISTENT', 'SELECT')
);

Replace <rai_app> with the name of your RAI Native App installation, and <your_database> with the database where you created the view in Step 2.3.

On success, you will receive a message confirming that the view was registered successfully.

Registration Errors

If registration fails, you will receive a descriptive error. The following table describes common errors and their resolutions:

Error	Cause	Resolution
Failed to bind view reference	Null or invalid reference object	Provide a valid object_reference()
A view is already registered	View is already registered	Call UNREGISTER_EVENTS_VIEW() first
Your view is missing a required column	Missing required columns	Ensure view includes the required column mentioned in the error message
Registration failed - Failed to enable CHANGE_TRACKING	Failed to enable change tracking on the view	Ensure CHANGE_TRACKING is enabled on your view and its underlying view(s) or table(s)

2.5 Unregister the View

If you need to replace the registered view or remove the observability configuration, use the unregister procedure:

CALL <rai_app>.app.UNREGISTER_EVENTS_VIEW();

This removes the current view binding and clears the stored configuration. You will need to call REGISTER_EVENTS_VIEW() again to re-enable observability views.

Common reasons to unregister:

• You need to replace the registered view with a new or updated one
• The database or schema was renamed, breaking the reference

2.6 Validate Configuration

After registration, or at any time, you can validate your observability configuration using the health check API:

CALL <rai_app>.app.CHECK_EVENTS_VIEW_STATUS();

This procedure checks your configuration, validates the view, and returns diagnostics including event statistics and the time since the last event.

Status values:

Status	Meaning	Action Required
Events view active	Configuration valid, events flowing	None – system is healthy
No events view registered	No view has been registered	Run REGISTER_EVENTS_VIEW()
ERROR	Configuration is broken	Fix based on reported error type

Tip

Run CHECK_EVENTS_VIEW_STATUS() whenever you encounter unexpected results from observability views. It will diagnose most common configuration issues.