❄️
Data Flakes

Back

In this article, we will be talking about observability, its importance and how Event tables can be used to improve observability and debugging.

In modern data engineering, observability is key to maintaining robust data platforms. Snowflake, a leading cloud data platform, introduced Event Tables to give developers and administrators deeper insight into application behaviour. These specialized tables provide automatic logging and tracing of activities within Snowflake stored procedures, UDFs, and Snowpark applications. This article explores the functionality of Snowflake Event Tables, their configuration, and how they enhance system observability and debugging efforts.

Features change from time to time with new features being added regularly, it is recommended that you review the documentation for the latest on what specific features are included with any of the Editions.

What Are Snowflake Event Tables?#

Snowflake Event Tables are special-purpose database tables designed to automatically collect and store telemetry data (logs and traces) from within your Snowflake environment.

Key characteristics include:#

  • Predefined schema following the OpenTelemetry format.

  • Automatic log collection from stored procedures, UDFs, and Snowpark apps.

  • Centralized logging and tracing for better observability.

  • Queryable via SQL like standard tables.

By default, Snowflake provides SNOWFLAKE.TELEMETRY.EVENTS, a built-in event table. However, users can also create custom event tables for more granular control.

How Event Tables Work#

Event Emission#

Snowflake emits events from procedures and functions when logging and tracing APIs (like SYSTEM$LOG) are used. The telemetry emitted includes:

  • Log messages (INFO, WARN, ERROR, etc.)

  • Stack traces for errors

  • Custom span information for tracing

These are automatically inserted into the associated event table.

Predefined Schema#

Event tables have a fixed schema that supports logs, spans, and resource metadata. Key columns include:

  • EVENT_TYPE: Type of event (LOG, SPAN, etc.)

  • BODY: Message body or stack trace

  • TIMESTAMP: UTC timestamp of the event

  • SEVERITY: Log severity (e.g., INFO, WARN)

  • RESOURCE_ATTRIBUTES: Metadata like user, session, function name

This structure aligns with OpenTelemetry for easy integration with external tools.

Scoping and Association#

Event tables can be associated with:

The account level using:

ALTER ACCOUNT SET EVENT_TABLE = <DATABASE>.<SCHEMA>.<EVENT_TABLE>
sql

A specific database, schema, or procedure

This flexibility allows selective logging depending on your observability needs.

Setting Up Logging & Event Tables#

Features change from time to time with new features being added regularly, it is recommended that you review the documentation for the latest on what specific features are included with any of the Editions.

Enabling Logging with Default Table#

To use the default Snowflake event table:

  1. Set your telemetry level:
ALTER ACCOUNT SET LOG_LEVEL = 'INFO';
sql
  1. Use logging functions in your procedure:
CALL SYSTEM$LOG('INFO', 'Starting ETL step');
sql
  1. Query log entries:
SELECT * FROM SNOWFLAKE.TELEMETRY.EVENTS
WHERE RESOURCE_ATTRIBUTES:procedure_name = 'my_proc';
sql

Creating a Custom Event Table#

CREATE EVENT TABLE my_database.my_schema.custom_events;
sql

Associating the Table#

ALTER DATABASE my_database SET EVENT_TABLE = my_database.my_schema.custom_events;
sql

Or at the account level:

ALTER ACCOUNT SET EVENT_TABLE = my_database.my_schema.custom_events;
sql

Access Control#

Use these predefined roles to manage permissions:

SNOWFLAKE.EVENTS_ADMIN – full control

SNOWFLAKE.EVENTS_VIEWER – read-only access to EVENTS_VIEW

GRANT APPLICATION ROLE SNOWFLAKE.EVENTS_VIEWER TO ROLE analyst_role;
sql

Best Practices and Optimization Tips#

  • Use custom event tables per environment (e.g., dev, prod) for isolation.

  • Filter logs by severity and context to avoid noisy data.

  • Leverage EVENTS_VIEW to apply row access policies.

Conclusion#

As you can see, the options are limitless, using event tables to log and provide observability in stored procedures, debugging errors, providing users with audit trails and performance monitoring.

Snowflake Event Tables provide a powerful, native approach to logging and observability within your Snowflake workloads. Whether you’re debugging stored procedures, auditing application activity, or building real-time monitoring dashboards, event tables give you structured, queryable access to what’s happening under the hood. With careful setup and role-based controls, you can maintain system transparency while controlling costs and access.

Features change from time to time with new features being added regularly, it is recommended that you review the documentation for the latest on what specific features are included with any of the Editions.

Disclaimer

The information provided on this website is for general informational purposes only. While we strive to keep the information up to date and correct, there may be instances where information is outdated or links are no longer valid. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.