Snowflake ML alerts, inference auditing, lineage and serving metrics

1.Alerts for model degradation and governance-rule violations

Model monitor dashboards and metric functions only show a problem when someone looks. A Snowflake alert checks for you. It is a schema-level object with three parts: a condition (a SQL query), an action to take when the condition is met (such as sending an email or writing rows to a table), and a schedule for how often to evaluate the condition.

An automated degradation alert combines the two pieces. The condition queries a model monitor metric function and compares the result with your threshold. The action sends a notification. The sources document both pieces separately, not one combined example, so treat the pattern as an assembly of documented parts. The alerts guide covers governance cases with the same tool and gives "your data fails to comply with a particular business rule" as a standard use. The sources do not describe a dedicated ML governance-violation feed. You express the rule as a query condition yourself.

CREATE OR REPLACE ALERT alert_new_rows
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
      SELECT *
      FROM my_table
      WHERE row_timestamp BETWEEN SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
       AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
  ))
  THEN CALL SYSTEM$SEND_EMAIL(...);

There are two kinds of alert.

- An alert on a schedule runs every *n* minutes or on a cron expression, and evaluates its condition against all the data. The example above is a scheduled alert: it narrows its own window to rows added since the last successful run. - An alert on new data runs only when rows are inserted into its table or view, and evaluates only those rows. Its condition is restricted. The FROM clause can name only one table, view or event table. That object must have change tracking enabled. The condition cannot use CTEs, DML, stored procedure calls or joins. You also cannot trigger it with EXECUTE ALERT.

A metric-threshold check calls a table function, so a scheduled alert is the natural fit.

For compute, an alert can be serverless, which scales automatically up to the equivalent of an XXLARGE warehouse, or it can use a warehouse you specify. For alerts on data that arrives rarely, serverless is the better fit. On a warehouse, even a single email incurs at least one minute of warehouse cost. To create an alert, a role needs EXECUTE ALERT on the account, which only ACCOUNTADMIN can grant. It also needs EXECUTE MANAGED ALERT for a serverless alert, or USAGE on the warehouse otherwise, plus CREATE ALERT and USAGE on the schema.

Sources12

2.Auditing inference and tracing ML lineage

Regulated industries ask two questions: *who accessed which data*, and *where did this model come from*. Snowflake answers them with two different features.

Access History records reads, and writes such as INSERT, UPDATE, DELETE and COPY, from source objects to target objects. Each SQL statement gets one row in the ACCESS_HISTORY view, in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas. The row covers the source columns accessed directly and indirectly, the columns projected in the result, and the columns used only for filtering. A batch inference statement that reads input features and inserts predictions is a read-and-write statement of this kind. The sources do not describe a separate record type for model method calls, so the audit rests on these data-access records. They also describe a second record of inference: the monitor's own logs, which keep inference inputs and predictions with timestamps.

ML Lineage (snowflake-ml-python 1.6.0+) traces dependencies between source tables, views and stages, feature views, datasets, registered models and deployed model services. A model's lineage is captured when it is logged to the Model Registry. If the model was trained outside Snowpark, pass a Snowpark DataFrame backed by the source table as the sample input to log_model to record the link. You can explore lineage on each artifact's Lineage tab in Snowsight, with the lineage() method, or with the SQL function SNOWFLAKE.CORE.GET_LINEAGE. Exploring it from the Python APIs requires the VIEW LINEAGE privilege.

The documented limits matter for compliance. Tables and views created from model predictions do not link back to the model. Lineage is not replicated. Objects created before the feature was enabled have no lineage.

USE ROLE ACCOUNTADMIN;
GRANT VIEW LINEAGE ON ACCOUNT TO ROLE test_role;

Sources345

3.Latency, throughput and availability for served models

Model monitors measure prediction quality. A model served on Snowpark Container Services also needs operational monitoring. Model serving services write performance and health metrics to the event table, covering resource utilization, request rates and latency. In Snowsight, open Monitoring » Services & jobs and select the service. The Logs, Metrics and Events tabs show logs, performance metrics and events such as instances being provisioned or shut down, and you can filter them by instance and container. The inference container is named model-inference. Each service also has helper functions, SPCS_GET_LOGS and SPCS_GET_METRICS, which read from the event table even when the service is suspended. Reading logs this way requires at least the MONITOR privilege on the service.

SELECT *
FROM TABLE(mydb.myschema.my_model_service! ? ())
WHERE
timestamp > dateadd(hour, -1, current_timestamp())
AND instance_id = 0  -- choose all instances or one particular
AND container_name = 'model-inference';

Availability depends on configuration as well as monitoring. With the default min_instances=0, a service suspends itself after 30 minutes of inactivity. The next request resumes it, but has to wait for compute pool capacity and for the model to load. For production, set min_instances to 1 or more to avoid that cold start, and set max_instances high enough for peak demand. The event table also connects serving health back to alerting: an alert on new data can watch the event table and notify you when error records arrive.

Sources61

Exam traps

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

1. 1.ML Lineage will trace a predictions table back to the model that wrote it.Why is that wrong?

   Tables and views created from model predictions do not currently link back to the model, so the audit trail has to come from Access History or the monitor logs.

   Covered in Auditing inference and tracing ML lineage

2. 2.Any alert can be run on demand with EXECUTE ALERT to test it.Why is that wrong?

   EXECUTE ALERT works for scheduled alerts but cannot run an alert on new data.

   Covered in Alerts for model degradation and governance-rule violations

3. 3.A model monitor's dashboard covers serving latency and availability.Why is that wrong?

   Model monitors measure quality from stored inference data. Latency, request rates and health are SPCS service metrics in the event table.

   Covered in Latency, throughput and availability for served models