Event table overview¶
As your Snowflake objects — including procedures and UDFs — emit telemetry data, Snowflake collects the data in an event table whose data is available for queries. Snowflake includes an event table by default, but you can also create a new one.
To collect telemetry data, you must have an active event table and have set telemetry levels to allow data collection. If you don’t already have an active event table, Snowflake makes the default event table the active event table.
When collecting telemetry data, you incur costs. To understand these costs — or to reduce or avoid these costs — see Costs of telemetry data collection.
What is an event table?¶
An event table is a special kind of database table with a predefined set of columns. The table’s structure supports the data model for OpenTelemetry (https://opentelemetry.io/), a framework for handling telemetry data. When an event table is active, Snowflake collects telemetry data in the table — including data that Snowflake itself generates and data that you emit by instrumenting your handler code using certain APIs. You can view the collected data by executing SQL queries.
After installation, Snowflake includes a default event table called SNOWFLAKE.TELEMETRY.EVENTS. This event table is active and collects data until you deactivate it. You can also create your own.
To collect telemetry data, you must have an active event table. For more information, see Make an event table active.
Default event table¶
By default, Snowflake includes a default event table named SNOWFLAKE.TELEMETRY.EVENTS. You can use this event table instead of creating your own. If you do not already have an active event table, Snowflake makes the default table the active event table.
By default, Snowflake also includes a predefined view called SNOWFLAKE.TELEMETRY.EVENTS_VIEW view, with which you more securely make event table data available to a range of users. You can manage access to the view with a row access policy.
Note
The default event table supports only a subset of DDL commands supported for event tables you create or for regular tables. For more information, see Working with event tables.
Roles for access to the default event table and EVENTS_VIEW¶
Snowflake includes the following predefined application roles you can use to manage access to the default event table and EVENTS_VIEW view.
- EVENTS_VIEWER:
Role with privileges to execute a SELECT statement on the EVENTS_VIEW view.
- EVENTS_ADMIN:
Role with the following privileges:
SELECT, TRUNCATE, DELETE on the default event table.
SELECT on the EVENTS_VIEW view of the default event table.
USAGE on the following stored procedures:
This role also has privileges to execute a stored procedure to apply a row access policy (RAP) on the EVENTS_VIEW view whose data is based on the default event table.
Managing access to EVENTS_VIEW¶
You can manage access to data in the EVENTS_VIEW view with row access policies. Snowflake provides stored procedures you can use to add and remove a row access policy to the EVENT_VIEW view.
ADD_ROW_ACCESS_POLICY_ON_EVENTS_VIEW(VARCHAR, ARRAY) — Binds a row access policy to the specified columns in the EVENTS_VIEW.
DROP_ROW_ACCESS_POLICY_ON_EVENTS_VIEW(VARCHAR) — Deletes the specified row access policy bound to the EVENTS_VIEW.
Note
You must have the EVENTS_ADMIN role to execute these procedures.
Using row access policies on the EVENT_VIEW view is an Enterprise Edition feature.
Create an event table¶
To create a new event table, execute the CREATE EVENT TABLE command and specify a name for the event table.
Note that when you create an event table, you do not specify the columns in the table. An event table already has a set of predefined columns, as described in Event table columns.
You must use a role that is granted CREATE EVENT TABLE privilege.
Note
Replication of event tables is not currently supported. Any event tables that are contained in primary databases are skipped during replication.
For example, to create an event table with the name my_events, execute the following statement:
CREATE EVENT TABLE my_database.my_schema.my_events;
Make an event table active¶
To enable storage of telemetry data, you must specify that an event table is an active event table.
To specify the active event table for your account, execute the ALTER ACCOUNT command, and set the EVENT_TABLE parameter to the name of your event table.
Note
In order to execute this command, you must use the ACCOUNTADMIN role.
In addition, you must have both of the following privileges:
OWNERSHIP privilege for the account.
See the documentation on the ALTER ACCOUNT command for more information on the privileges needed to execute ALTER ACCOUNT.
For example, to set up the event table named my_events in the schema my_schema in the database my_database as
the active event table for your account, execute the following statement:
ALTER ACCOUNT SET EVENT_TABLE = my_database.my_schema.my_events;
As shown above, you must specify the fully qualified name of the event table.
To disassociate an event table from an account, execute the ALTER ACCOUNT command and unset the EVENT_TABLE parameter. For example:
ALTER ACCOUNT UNSET EVENT_TABLE;
You can confirm the EVENT_TABLE value with the SHOW PARAMETERS command:
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;