为应用程序使用日志记录和事件跟踪

This topic describes how providers can configure a Snowflake Native App to record log messages and trace events.

This guide covers both provider and consumer responsibilities. Provider topics cover how to emit, share, and centrally monitor telemetry from apps installed in consumer accounts. Consumer topics cover how to set up an event table, control what is shared back to the provider, and understand the cost model. Section headings are labeled accordingly.

关于应用程序中的日志消息和跟踪事件

The Snowflake Native App Framework supports using the Snowflake logging and tracing functionality to gather information about an app. Providers can configure an app to record and analyze the following:

• Log messages: independent, detailed messages with information about the state of a specific piece of app code.
• Trace events: structured data that providers can use to get information spanning and grouping multiple parts of your code. Trace events allow an app to emit information related to its performance and behavior.
• Metrics: information about stored procedure and UDF resource consumption based on the CPU and memory metrics that Snowflake generates.

App telemetry is written to the active event table in the consumer account. The default SNOWFLAKE.TELEMETRY.EVENTS table is active in every account out of the box. Customers can also create a custom event table and set it as the active table to isolate app telemetry from other account events. Snowflake ships two default database roles for access control: EVENTS_ADMIN (manage row-access policies and delete data) and EVENTS_VIEWER (read-only access to the masked SNOWFLAKE.TELEMETRY.EVENTS_VIEW). For containerized apps, container telemetry types are listed in Snowpark Container Services: Monitoring Services.

To configure an app to emit log messages and trace events, providers set the log and trace levels in the manifest file. See Set the log and trace levels for an app.

Providers can also configure an app to use event sharing to allow the consumer to share the log messages and trace events with the provider. See About event sharing for more information.

关于事件共享

事件共享允许提供商收集有关应用程序性能和行为的信息。提供商可以配置应用程序，要求使用者与提供商共享日志消息和跟踪事件。事件共享要求提供商和使用者在其账户中配置一个事件表，以存储应用程序发出的日志消息和跟踪事件。

When event sharing is enabled, the log messages and trace events that are inserted into the event table in the consumer account are also inserted into the event table in the provider account.

Providers can also use centralized event sharing to route telemetry from multiple regions to a central location.

使用事件共享时的注意事项

在为应用程序配置日志记录和事件共享之前，提供商必须考虑以下几点：

• Providers are responsible for all costs associated with event sharing on the provider side, including data ingestion and storage.
• Providers must have an account to store shared events in each region where you want to support event sharing.
• 提供商必须在清单文件中定义应用程序的默认日志级别和跟踪级别。

从之前的事件共享功能迁移时的注意事项

在从现有的事件共享功能迁移到使用事件定义的过程中，提供商应注意以下几点。

• 之前的事件共享功能相当于 OPTIONAL ALL 事件定义。
• Published versions and patches of an app that used the previous functionality will have the OPTIONAL ALL event definition by default. Providers do not need to add this event definition to the manifest file.

要开始使用事件定义，提供商可以将支持的事件定义添加到清单文件中。这适用于新应用程序以及现有应用程序的新版本和补丁。

工作流程 – 为应用程序设置事件共享

事件共享允许使用者与提供商共享日志消息和跟踪事件。

以下工作流程展示了如何为应用程序设置和启用事件共享：

1. The provider sets the log and trace levels for the app.
2. The provider adds event definitions to the manifest file.

事件定义充当应用程序发出的日志消息和跟踪事件的筛选器。提供商可将事件定义配置为必需或可选。

3. The provider sets up an event table in their organization.
4. 提供商发布应用程序。

When a consumer installs an app, they can set up an event table and enable event sharing. See Enable logging and event sharing for an app for more information on the consumer requirements for event sharing.

监控使用者应用程序运行状况

For centralized health monitoring across all consumer accounts, see Monitor a native app.