Snowflake Event Tables and Telemetry Levels

1.What an event table is and where telemetry lands

Procedures, UDFs and other Snowflake objects emit telemetry: log messages, trace data, metrics and log events. Snowflake writes all of it to an event table. An event table is a special kind of database table with a predefined set of columns. Its structure follows the OpenTelemetry data model, and you read it with ordinary SQL queries. It holds data you emit by instrumenting handler code with logging and tracing APIs, and it also holds data that Snowflake generates itself.

Every account comes with the default event table SNOWFLAKE.TELEMETRY.EVENTS. If you never set an active event table yourself, Snowflake uses this one. The table alone is not enough, though. Collection also depends on telemetry levels, which the last section of this page covers. Collection is not free either: the documentation warns that collecting telemetry data incurs costs. So capture what you need and leave the rest switched off.

Snowflake also provides a predefined view, SNOWFLAKE.TELEMETRY.EVENTS_VIEW. Use it to share event data with a wider group of users more securely than granting access to the table itself. You can manage access to the view with a row access policy.

Sources1

2.Default versus custom event tables, and how to manage each

The default table is easy to use but you have less control over it. It supports only some of the DDL commands available for an event table you create. You can query it, truncate it and delete from it, but you cannot drop it or undrop it. Neither kind of event table can be renamed. A custom event table also supports DROP, UNDROP and CREATE TABLE.

Event table data grows continuously, so you need a way to keep it in check. TRUNCATE TABLE removes all rows. DELETE removes selected rows, which lets you build retention rules. For example, you could keep one function's logs longer than another's. You can also create a stream on an event table to capture new rows as they are inserted.

Access control also differs between the two. For the default table, Snowflake provides two application roles. ACCOUNTADMIN can grant them, and they must be granted to roles, not directly to users:

- EVENTS_VIEWER can SELECT from EVENTS_VIEW. - EVENTS_ADMIN has SELECT, TRUNCATE and DELETE on the default table and SELECT on EVENTS_VIEW. It can also run the procedures ADD_ROW_ACCESS_POLICY_ON_EVENTS_VIEW and DROP_ROW_ACCESS_POLICY_ON_EVENTS_VIEW. Row access policies on this view require Enterprise Edition.

For a custom table, you control access through privileges such as SELECT. You can also create views on the event table that each expose part of the data, and grant each view to a different role.

GRANT APPLICATION ROLE SNOWFLAKE. ?  TO ROLE my_analysis_role;

Sources21

3.Configuring a custom event table and its scope

Setting up a custom event table takes two steps. First, with a role that has the CREATE EVENT TABLE privilege, create the table. You give it only a name, because the columns are predefined. Second, set the EVENT_TABLE parameter on an object to associate the table with it. That object becomes the scope whose telemetry goes into the table.

CREATE EVENT TABLE my_database.my_schema.my_events;

You can associate an event table with the account or with a database.

- Account: gives the broadest scope. It requires the ACCOUNTADMIN role, OWNERSHIP on the account, and OWNERSHIP or INSERT on the event table. Use ALTER ACCOUNT SET EVENT_TABLE = ... with the fully qualified table name. - Database: requires Enterprise Edition. Use ALTER DATABASE ... SET EVENT_TABLE.

To remove an association, use UNSET EVENT_TABLE. To check which table is set, use SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT, or IN DATABASE for a database.

When both levels have a table, the database's table wins. Objects in that database write to the database's table, and every other database falls back to the account's table. One more limit to keep in mind: event tables are not replicated. Event tables inside primary databases are skipped during replication.

ALTER DATABASE my_database SET  ?  = my_database.my_schema.my_events;

Sources1

4.Setting levels for logs, log events, metrics and traces

The event table decides where telemetry goes. Levels decide how much of it is captured. Each kind of telemetry has its own parameter. You can set a parameter for the account, override it on an object, or set it for the current session. Objects you can set levels on include a database, a schema, a procedure, a UDF or UDTF, and an externally managed Iceberg table with automated refresh. You cannot set levels on Streamlit objects. Instead, set the level on the database or schema that contains them.

To set a level at the account scope, you need MODIFY LOG LEVEL (or MODIFY TRACE LEVEL, and so on) on the account. Setting it on an object also requires MODIFY on that object and USAGE on its database or schema.

To set account-level telemetry in Snowsight, go to Monitoring » Traces & logs and choose Set Event Level. The Snowsight toggles simplify the underlying parameters. Logs On sets LOG_LEVEL to INFO. Traces On sets TRACE_LEVEL to ALWAYS. Metrics On sets METRIC_LEVEL to ALL.

Levels follow two hierarchies. Object parameters run Account » Database » Schema » Object, and the setting closest to the object wins. Session parameters run Account » User » Session. If a level is set in both the session and the object hierarchy, Snowflake uses the most verbose of the two.

ALTER ACCOUNT SET LOG_LEVEL = FATAL;

ALTER FUNCTION MyJavaUDF SET LOG_LEVEL = INFO;

-- The INFO log level is used because the FUNCTION MYJAVAUDF
-- is lower than the ACCOUNT in the hierarchy.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Setting LOG_LEVEL = WARN captures only WARN messages.Why is that wrong?

   A log level is a threshold. Snowflake captures messages at that level and every more severe level, so WARN also captures ERROR and FATAL.

   Covered in Setting levels for logs, log events, metrics and traces

2. 2.An event table set on the account overrides any table set on a database, because the account is the broadest scope.Why is that wrong?

   It works the other way round. The database's event table takes precedence, and the account's table only catches databases that have no table of their own.

   Covered in Configuring a custom event table and its scope

3. 3.The default event table works like any table you own, so you can drop it or rename it.Why is that wrong?

   The default table supports only some event table operations. DROP and UNDROP are custom-table only, and rename is not supported for either kind.

   Covered in Default versus custom event tables, and how to manage each