Snowflake의 데이터 기반 알림 설정하기

이 주제는 Snowflake 내 데이터에 기반해 특정 조건에서 주기적으로 작업을 수행하는 알림을 설정하는 방법을 설명해요.

출처: Snowflake 문서

본문

소개

어떤 경우에는 Snowflake의 데이터가 특정 조건을 충족할 때 알림을 받거나 작업을 하고 싶을 수 있어요. 예를 들어 다음 때 알림을 받고 싶을 수 있어요.

웨어하우스 크레딧 사용량이 현재 할당량의 지정된 백분율만큼 증가할 때
파이프라인, 태스크, 구체화된 뷰 등의 리소스 소비가 지정된 양을 초과할 때
데이터가 설정한 특정 비즈니스 규칙을 준수하지 못할 때

이렇게 하려면 Snowflake 알림을 설정할 수 있어요. Snowflake 알림은 다음을 지정하는 스키마 수준 객체예요.

알림을 트리거하는 조건(예: 완료에 1초 이상 걸리는 쿼리의 존재)
조건이 충족될 때 수행할 작업(예: 이메일 알림 보내기, 일부 데이터를 테이블에 캡처 등)
조건을 언제, 얼마나 자주 평가할지(예: 24시간마다 또는 매주 일요일 자정)

예를 들어 웨어하우스의 크레딧 소비가 특정 한도를 초과할 때 이메일 알림을 보내고 싶다고 가정해 봐요. 이것을 30분마다 확인하고 싶다고 가정해 봐요. 다음 속성으로 알림을 만들 수 있어요.

조건: 웨어하우스의 크레딧 소비(ACCOUNT_USAGE 스키마의 WAREHOUSE_METERING_HISTORY 뷰의 credits_used 열의 합)가 지정된 한도를 초과
작업: 관리자에게 이메일 전송
빈도/일정: 30분마다 이 조건 확인

알림 유형 선택

다음 유형의 알림을 만들 수 있어요.

일정 기반 알림: Snowflake가 기존 데이터에 대해 예약된 기준으로 조건을 평가해요.
- 예를 들어 테이블의 기존 행 중 어느 것이 열 값이 지정된 양을 초과하는지 확인하는 일정 기반 알림을 설정할 수 있어요.
새 데이터 기반 알림: Snowflake가 지정된 테이블이나 뷰의 새 행에 대해 조건을 평가해요.
- 예를 들어 계정의 이벤트 테이블에 오류 메시지에 대한 새 행이 삽입될 때 알려주는 새 데이터 기반 알림을 설정할 수 있어요. 동적 테이블 새로고침과 태스크 실행이 이벤트 테이블에 이벤트를 로그하므로, 새 데이터 기반 알림을 설정해 다음을 할 수 있어요.
  - 동적 테이블 새로고침 모니터링
  - 태스크 실행 모니터링

일정 기반 알림

일정 기반 알림을 사용하면 n분마다 또는 cron 식으로 지정된 일정으로 실행되도록 알림을 설정할 수 있어요.

알림 조건은 모든 데이터에 대해 평가돼요(새 데이터 기반 알림처럼 삽입된 새 행에 대해서만 조건이 평가되는 것과 반대).

새 데이터 기반 알림

새 데이터 기반 알림을 사용하면 테이블에 새 행이 삽입되거나 뷰에서 사용 가능할 때만 실행되도록 알림을 설정할 수 있어요.

새 행이 삽입될 때마다 알림이 실행되어 새 행에 대해서만 조건을 평가하고, 조건이 TRUE로 평가되면 작업을 수행해요.

새로 삽입된 행에 대한 조건을 평가하려면 일정 기반 알림(데이터가 추가되었는지 여부와 무관하게 고정 일정으로 실행되는)을 설정하는 대신 새 데이터 기반 알림을 사용해요.

알림이 테이블이나 뷰의 새로 삽입된 행에서만 작동하므로 지정할 수 있는 조건에는 제한이 있어요.

SELECT 문에서 FROM 절은 일반 테이블, 뷰, 이벤트 테이블 하나만 지정할 수 있어요.
그 테이블이나 뷰에서 변경 추적(change tracking)을 활성화해야 해요.
다음은 사용할 수 없어요.
- 공통 테이블 식(CTE)
- DML(Data Manipulation Language) 명령
- 저장 프로시저 호출
- 조인

참고(Note): EXECUTE ALERT 명령으로 새 데이터 기반 알림을 실행할 수 없어요.

알림용 웨어하우스 선택

알림은 실행을 위해 웨어하우스가 필요해요. 서버리스 컴퓨팅 모델 또는 지정하는 가상 웨어하우스 중 하나를 사용할 수 있어요.

서버리스 컴퓨팅 모델 사용(서버리스 알림)

서버리스 컴퓨팅 모델을 사용하는 알림을 *서버리스 알림(serverless alerts)*이라고 해요. 서버리스 컴퓨팅 모델을 사용하면 Snowflake가 알림에 필요한 컴퓨팅 리소스를 자동으로 크기 조정·확장해요. Snowflake는 같은 알림의 가장 최근 이전 실행에 대한 통계의 동적 분석에 기반해 주어진 실행에 대한 컴퓨팅 리소스의 이상적인 크기를 결정해요. 서버리스 알림 실행의 최대 크기는 XXLARGE 웨어하우스와 동등해요. 계정의 여러 워크로드가 공통 컴퓨팅 리소스 집합을 공유해요.

청구는 다른 서버리스 기능(예: 서버리스 태스크)과 유사해요. 알림 비용 이해를 참고해요.

참고(Note): 드물게 추가되는 새 데이터 기반 알림을 만들고 있다면 이를 서버리스 알림으로 구성하는 것을 고려해요. 웨어하우스를 사용하도록 알림을 구성하면 이메일 알림을 보내는 단순한 작업도 최소 1분의 웨어하우스 비용이 발생해요.

지정하는 가상 웨어하우스 사용

가상 웨어하우스를 지정하려면 알림이 실행하는 SQL 작업에 적절한 크기의 웨어하우스를 선택해야 해요. 웨어하우스 선택 지침은 웨어하우스 고려사항을 참고해요.

알림 비용 이해

알림을 실행해 SQL 코드를 실행하는 것과 관련된 비용은 알림에 사용되는 컴퓨팅 리소스에 따라 달라져요.

서버리스 알림의 경우 Snowflake가 컴퓨팅 리소스 사용량에 따라 계정에 청구해요. 요금은 컴퓨팅 시간(compute-hours) 크레딧 사용량으로 측정되는 클라우드 서비스 사용량을 포함한 리소스의 총 사용량을 기반으로 계산돼요. 컴퓨팅 시간 비용은 웨어하우스 크기와 쿼리 런타임에 따라 변경돼요. 자세한 내용은 서버리스 크레딧 사용량을 참고해요.
- 알림이 소비하는 크레딧 수를 알아보려면 Snowflake Service Consumption Table의 "Serverless Feature Credit Table"을 참고해요.
- 서버리스 알림의 사용량 이력을 보려면:
  - SERVERLESS_ALERT_HISTORY 함수 호출
  - SERVERLESS_ALERT_HISTORY 뷰 쿼리
지정하는 가상 웨어하우스를 사용하는 알림의 경우 Snowflake가 알림 실행 중 웨어하우스 사용량에 기반해 크레딧 사용량을 계정에 청구해요. 이는 클라이언트 또는 Snowsight에서 같은 SQL 문을 실행하는 웨어하우스 사용량과 유사해요. 초 단위 크레딧 청구와 웨어하우스 자동 일시 중단 덕분에 더 큰 웨어하우스 크기로 시작한 다음 알림 워크로드에 맞게 크기를 조정할 수 있는 유연성을 갖게 돼요.

팁(Tip): 테이블이나 뷰에 추가된 새 행을 평가하는 알림을 설정하려면 일정 기반 알림이 아니라 새 데이터 기반 알림을 사용해요. 일정 기반 알림은 새 행이 삽입되었는지 여부와 무관하게 예정된 시간에 실행돼요.

알림 생성 권한 부여

알림을 만들려면 다음 권한을 가진 역할을 사용해야 해요.

계정에 대한 EXECUTE ALERT 권한

참고(Note): 이 권한은 ACCOUNTADMIN 역할을 가진 사용자만 부여할 수 있어요.

다음 권한 중 하나:
- 서버리스 알림을 만드는 경우 계정에 대한 EXECUTE MANAGED ALERT 권한
- 알림에 가상 웨어하우스를 지정하는 경우 알림을 실행하는 데 사용되는 웨어하우스에 대한 USAGE 권한
알림을 만들려는 스키마에 대한 USAGE 및 CREATE ALERT 권한
스키마를 포함하는 데이터베이스에 대한 USAGE 권한
알림 조건에서 쿼리하려는 테이블이나 뷰에 대한 SELECT 권한(새 데이터 기반 알림을 만드는 경우)

이 권한을 역할에 부여하려면 GRANT <privileges> … TO ROLE 명령을 사용해요.

예를 들어 my_schema라는 스키마에 알림을 만들 권한이 있는 my_alert_role이라는 커스텀 역할을 만들고 싶다고 가정해 봐요. 알림이 웨어하우스 my_warehouse를 사용하길 원해요.

이렇게 하려면:

ACCOUNTADMIN 역할을 가진 사용자가 다음을 하게 해요.
- 커스텀 역할 생성. 예를 들어:

USE ROLE ACCOUNTADMIN;

CREATE ROLE my_alert_role;

그 커스텀 역할에 EXECUTE ALERT 전역 권한을 부여해요. 예를 들어:

GRANT EXECUTE ALERT ON ACCOUNT TO ROLE my_alert_role;

서버리스 알림을 만들고 싶다면 그 커스텀 역할에 EXECUTE MANAGED ALERT 전역 권한을 부여해요. 예를 들어:

GRANT EXECUTE MANAGED ALERT ON ACCOUNT TO ROLE my_alert_role;

커스텀 역할을 사용자에게 부여해요. 예를 들어:

GRANT ROLE my_alert_role TO USER my_user;

데이터베이스, 스키마, 웨어하우스의 소유자가 알림 생성에 필요한 권한을 커스텀 역할에 부여하게 해요.
- 스키마 소유자가 스키마에 CREATE ALERT 및 USAGE 권한을 부여해야 해요.

GRANT CREATE ALERT ON SCHEMA my_schema TO ROLE my_alert_role;
GRANT USAGE ON SCHEMA my_schema TO ROLE my_alert_role;

데이터베이스 소유자가 데이터베이스에 USAGE 권한을 부여해야 해요.

GRANT USAGE ON DATABASE my_database TO ROLE my_alert_role;

알림에 웨어하우스를 지정하려면 해당 웨어하우스의 소유자가 웨어하우스에 USAGE 권한을 부여해야 해요.

GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE my_alert_role;

알림 생성

빠르게 시작할 수 있도록 일반적인 알림 사용 사례에 대한 사전 정의된 템플릿에서 조건과 작업을 직접 작성하는 대신 알림을 만들 수 있어요. 이 작업은 Snowsight 또는 SQL로 템플릿에서 알림 생성으로 할 수 있어요.

다음 섹션은 다양한 유형의 알림을 만드는 기본 단계와 예시를 제공해요.

일정 기반 알림 생성
새 데이터 기반 알림 생성

일정 기반 알림 생성

gauge라는 테이블의 하나 이상의 행에서 gauge_value 열의 값이 200을 초과할 때마다 gauge_value_exceeded_history라는 테이블에 현재 타임스탬프를 삽입하고 싶다고 가정해 봐요.

다음을 수행하는 알림을 만들 수 있어요.

gauge_value가 200을 초과하는 조건을 평가
이 조건이 true로 평가되면 타임스탬프를 gauge_value_exceeded_history에 삽입

my_alert이라는 알림을 만들려면:

알림을 만들 권한이 있는 역할을 사용 중인지 확인해요. 그 역할을 사용하지 않으면 USE ROLE 명령으로 그 역할을 사용해요.
알림을 만들 계획인 데이터베이스와 스키마를 사용 중인지 확인해요. 그 데이터베이스와 스키마를 사용하지 않으면 USE DATABASE 및 USE SCHEMA 명령으로 그 데이터베이스와 스키마를 사용해요.
CREATE ALERT 명령을 실행해 알림을 만들어요.

CREATE OR REPLACE ALERT my_alert
  WAREHOUSE = mywarehouse
  SCHEDULE = '1 minute'
  IF( EXISTS(
 SELECT gauge_value FROM gauge WHERE gauge_value>200))
  THEN
 INSERT INTO gauge_value_exceeded_history VALUES (current_timestamp());

서버리스 알림을 만들려면 WAREHOUSE 파라미터를 생략해요.

CREATE OR REPLACE ALERT my_alert
  SCHEDULE = '1 minute'
  IF( EXISTS(
 SELECT gauge_value FROM gauge WHERE gauge_value>200))
  THEN
 INSERT INTO gauge_value_exceeded_history VALUES (current_timestamp());

CREATE ALERT 명령의 전체 설명은 CREATE ALERT을 참고해요.

참고(Note): 알림을 만들면 기본적으로 알림이 일시 중단돼요. 알림이 실행되도록 하려면 새로 생성된 알림을 다시 시작해야 해요.

ALTER ALERT … RESUME 명령을 실행해 알림을 재개해요. 예를 들어:

ALTER ALERT my_alert RESUME;

새 데이터 기반 알림 생성

my_db.my_schema라는 데이터베이스와 스키마의 my_stored_proc이라는 저장 프로시저가 계정의 활성 이벤트 테이블에 FATAL 메시지를 로그할 때 이메일 알림을 받고 싶다고 가정해 봐요.

my_alert이라는 알림을 만들려면:

계정의 활성 이벤트 테이블의 이름을 찾아요.

SHOW PARAMETERS LIKE 'EVENT_TABLE' IN ACCOUNT;

+-------------+---------------------------+----------------------------+---------+-----------------------------------------+--------+
| key         | value                     | default                    | level   | description                             | type   |
|-------------+---------------------------+----------------------------+---------+-----------------------------------------+--------|
| EVENT_TABLE | my_db.my_schema.my_events | snowflake.telemetry.events | ACCOUNT | Event destination for the given target. | STRING |
+-------------+---------------------------+----------------------------+---------+-----------------------------------------+--------+

알림 조건에서 쿼리할 테이블이나 뷰에서 변경 추적을 활성화해요.

ALTER TABLE my_db.my_schema.my_events SET CHANGE_TRACKING = TRUE;

이메일 전송용 알림 통합을 설정해요.
알림을 만들 권한이 있는 역할을 사용 중인지 확인해요. 그 역할을 사용하지 않으면 USE ROLE 명령으로 그 역할을 사용해요.
알림을 만들 계획인 데이터베이스와 스키마를 사용 중인지 확인해요. 그 데이터베이스와 스키마를 사용하지 않으면 USE DATABASE 및 USE SCHEMA 명령으로 그 데이터베이스와 스키마를 사용해요.
CREATE ALERT 명령을 실행해 알림을 만들되 SCHEDULE 파라미터는 생략해요.
- 예를 들어 다음 예시는 동적 테이블 새로고침의 오류에 대해 이벤트 테이블을 모니터링하고 Slack 채널에 알림을 보내는 새 데이터 기반 알림을 만들어요. 예시는 다음을 가정해요.
  - 활성 이벤트 테이블이 기본 이벤트 테이블(SNOWFLAKE.TELEMETRY.EVENTS)임.
  - 동적 테이블에 대한 이벤트를 캡처하도록 심각도 수준을 설정했음.
  - 그 Slack 채널용 웹훅 알림 통합을 설정했음.

CREATE OR REPLACE ALERT my_alert
  WAREHOUSE = mywarehouse
  IF( EXISTS(
 SELECT * FROM SNOWFLAKE.TELEMETRY.EVENTS
   WHERE
     resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' AND
     record_type='EVENT' AND
     value:"state"='ERROR'
  ))
  THEN
 BEGIN
   LET result_str VARCHAR;
   (SELECT ARRAY_TO_STRING(ARRAY_AGG(name)::ARRAY, ',') INTO :result_str
     FROM (
       SELECT resource_attributes:"snow.executable.name"::VARCHAR name
         FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID()))
         LIMIT 10
     )
   );
   CALL SYSTEM$SEND_SNOWFLAKE_NOTIFICATION(
     SNOWFLAKE.NOTIFICATION.TEXT_PLAIN(:result_str),
     '{"my_slack_integration": {}}'
   );
 END;

서버리스 알림을 만들려면 WAREHOUSE 파라미터를 생략해요.

CREATE OR REPLACE ALERT my_alert
  IF( EXISTS(
 SELECT * FROM SNOWFLAKE.TELEMETRY.EVENTS
   WHERE
     resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' AND
     record_type='EVENT' AND
     value:"state"='ERROR'
  ))
  THEN
 BEGIN
   LET result_str VARCHAR;
   (SELECT ARRAY_TO_STRING(ARRAY_AGG(name)::ARRAY, ',') INTO :result_str
     FROM (
       SELECT resource_attributes:"snow.executable.name"::VARCHAR name
         FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID()))
         LIMIT 10
     )
   );
   CALL SYSTEM$SEND_SNOWFLAKE_NOTIFICATION(
     SNOWFLAKE.NOTIFICATION.TEXT_PLAIN(:result_str),
     '{"my_slack_integration": {}}'
   );
 END;

CREATE ALERT 명령의 전체 설명은 CREATE ALERT을 참고해요.

참고(Note): 알림을 만들면 기본적으로 알림이 일시 중단돼요. 알림이 실행되도록 하려면 새로 생성된 알림을 다시 시작해야 해요.

ALTER ALERT … RESUME 명령을 실행해 알림을 재개해요. 예를 들어:

ALTER ALERT my_alert RESUME;

알림에 런북(Runbook) 추가

알림에 런북 참조를 연결해 알림이 트리거될 때 대응자가 문서나 문제 해결 지침을 어디에서 찾을 수 있는지 알 수 있게 해요.

런북은 자유 텍스트 문자열(최대 2048자)이며, 일반적으로 내부 문서를 가리키는 URL이에요.

런북 설정

CREATE ALERT 또는 ALTER ALERT에서 RUNBOOK 파라미터를 사용해 런북을 설정해요.

CREATE OR REPLACE ALERT my_alert
  WAREHOUSE = my_alert_wh
  SCHEDULE = '5 MINUTE'
  RUNBOOK = 'https://www.snowflake.com/alerts/my-alert-runbook'
  IF( EXISTS(
    SELECT 1 FROM my_table WHERE error_count > 100
  ))
  THEN
    CALL SYSTEM$SEND_EMAIL(...);

나중에 런북을 업데이트하려면:

ALTER ALERT my_alert SET
  RUNBOOK = 'https://www.snowflake.com/alerts/my-alert-runbook-v2';

런북 보기

런북 값은 SHOW ALERTS, DESCRIBE ALERT, ALERT_HISTORY의 출력에 나타나요.

알림에 구성(Configuration) 전달

알림에 JSON 구성을 저장하고 조건(IF) 및 작업(THEN) SQL 모두에서 런타임에 읽을 수 있어요. 이를 통해 알림 SQL 문을 직접 수정하지 않고 알림 로직(예: 임계값, 알림 대상, 기능 플래그)을 매개변수화할 수 있어요.

구성 설정

CREATE ALERT 또는 ALTER ALERT에서 CONFIG 파라미터를 사용해 구성을 JSON 문자열로 설정해요.

구성은 알림의 SQL이 런타임에 참조하는 비즈니스 로직 파라미터(예: 임계값, 활성화/비활성화 스위치, 알림 대상)를 포함할 수 있어요.

다음 예시는 조건과 작업이 모두 구성 값으로 구동되는 알림을 만들어요.

CREATE OR REPLACE ALERT my_metric_threshold_alert
  WAREHOUSE = my_alert_wh
  SCHEDULE = '5 MINUTE'
  CONFIG = $${
    "enabled": true,
    "threshold": 10,
    "notify": "ops"
  }$$
  IF( EXISTS(
    SELECT 1
      FROM my_db.my_schema.my_source_table
      WHERE COALESCE(TRY_TO_BOOLEAN(SYSTEM$GET_ALERT_CONFIG('enabled')), FALSE)
        AND metric_value > COALESCE(
          TRY_TO_NUMBER(SYSTEM$GET_ALERT_CONFIG('threshold')), 0)
  ))
  THEN
    INSERT INTO my_db.my_schema.my_output_table
      SELECT CURRENT_TIMESTAMP(), SYSTEM$GET_ALERT_CONFIG('notify');

나중에 구성을 업데이트하려면 ALTER ALERT … SET CONFIG를 사용해요. CONFIG를 설정하면 전체 JSON 객체가 대체되며, 개별 키-값 쌍을 업데이트할 수 없어요.

ALTER ALERT my_metric_threshold_alert SET
  CONFIG = $${
    "enabled": true,
    "threshold": 25,
    "notify": "oncall"
  }$$;

런타임에 구성 값 읽기

SYSTEM$GET_ALERT_CONFIG을 호출해 구성 값을 검색해요. 전체 JSON 객체 또는 특정 필드를 검색할 수 있어요.

SYSTEM$GET_ALERT_CONFIG()는 전체 구성을 JSON 문자열로 반환해요.
SYSTEM$GET_ALERT_CONFIG('threshold')는 threshold 필드의 값을 반환해요.

구성이 설정되지 않으면 함수는 NULL을 반환해요.

참고(Note): SYSTEM$GET_ALERT_CONFIG은 알림 실행 중에만 호출할 수 있어요. 알림 런타임 밖에서 호출하면 오류가 발생해요.

구성 값 사용 모범 사례

구성 값은 JSON으로 저장되고 문자열로 읽히므로 런타임 오류를 피하려면 방어적으로 캐스팅해요.

직접 캐스팅 대신 TRY_TO_NUMBER 또는 TRY_TO_BOOLEAN을 사용해요.
구성을 설정하지 않을 수 있을 때 폴백 기본값을 제공하려면 COALESCE를 사용해요.
CTE를 사용해 구성 값을 한 번 추출·캐스팅한 다음 쿼리 나머지에서 참조해요.

예시: CTE 기반 구성 추출이 있는 고급 알림

다음 예시는 CTE로 구성 값을 추출하고, 구성 가능한 범위와 이름 패턴으로 태스크 이력을 필터링하고, 전체 구성을 핸들러 프로시저에 전달하는 더 복잡한 알림을 보여줘요.

CREATE OR REPLACE ALERT my_tasks_error_rate_alert
  WAREHOUSE = my_alert_wh
  SCHEDULE = '1 MINUTE'
  CONFIG = $${
    "ERROR_RATE_THRESHOLD": 0.05,
    "TASK_SCOPE": "ETL_",
    "SCOPE": "DATABASE",
    "DATABASE": "my_db"
  }$$
  IF( EXISTS(
    WITH cfg AS (
      SELECT
        COALESCE(TRY_TO_NUMBER(
          SYSTEM$GET_ALERT_CONFIG('ERROR_RATE_THRESHOLD')), 0.05)
          AS error_rate_threshold,
        COALESCE(SYSTEM$GET_ALERT_CONFIG('TASK_SCOPE')::STRING, '')
          AS task_scope,
        COALESCE(SYSTEM$GET_ALERT_CONFIG('DATABASE')::STRING, '')
          AS scope_database
    ),
    task_window AS (
      SELECT *
        FROM TABLE(
          INFORMATION_SCHEMA.TASK_HISTORY(
            SCHEDULED_TIME_RANGE_START =>
              SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
          )
        )
        WHERE DATABASE_NAME = (SELECT scope_database FROM cfg)
          AND NAME ILIKE (SELECT task_scope FROM cfg) || '%'
    ),
    agg AS (
      SELECT
        COUNT(*) AS total_runs,
        COUNT_IF(STATE = 'FAILED') AS failed_runs
        FROM task_window
    )
    SELECT 1
      FROM agg, cfg
      WHERE total_runs > 0
        AND failed_runs / total_runs::FLOAT > error_rate_threshold
  ))
  THEN
    CALL my_db.my_schema.handle_task_alert(
      PARSE_JSON(SYSTEM$GET_ALERT_CONFIG())
    );

이 예시에서:

CTE cfg는 각 구성 값을 안전한 기본값과 함께 한 번 추출·캐스팅해요.
task_window CTE는 구성 가능한 데이터베이스와 태스크 이름 패턴으로 태스크 이력을 필터링해요.
작업은 전체 구성을 파싱된 JSON 객체로 핸들러 프로시저에 전달하며, 핸들러 프로시저는 구성을 기반으로 알림을 라우팅하거나 다른 작업을 수행할 수 있어요.

알림 템플릿이 사용하는 풍부한 구성

Snowsight에서 템플릿으로 알림을 만들면 템플릿은 각 필드가 설명과 사용 가능한 옵션 같은 메타데이터를 포함하는 더 풍부한 구성 구조를 설정해요. 예를 들어 태스크 오류율 템플릿은 다음 같은 구성을 설정할 수 있어요.

CONFIG = $${
  "ERROR_RATE_THRESHOLD": {
    "description": "Trigger alert when cumulative task error rate exceeds this threshold (0.0 - 1.0).",
    "value": 0.1
  },
  "NOTIFICATION": {
    "EMAIL": {
      "recipients": ["[email protected]"],
      "value": "my_email_int"
    },
    "WEBHOOK": {
      "value": ""
    },
    "notification_value": {
      "active": "EMAIL",
      "options": ["EMAIL", "WEBHOOK"]
    }
  },
  "SCOPE": {
    "DATABASE": { "value": "my_db" },
    "SCHEMA": { "value": "" },
    "scope_value": {
      "active": "DATABASE",
      "options": ["ACCOUNT", "DATABASE", "SCHEMA"]
    }
  },
  "TASK_NAME_FILTER": {
    "description": "Optional filter pattern to scope alert to specific tasks. Leave empty for all tasks.",
    "value": "ETL_"
  }
}$$

Snowsight가 풍부한 편집 양식을 렌더링할 수 있게 하는 이 구조의 핵심 구성 요소는 다음과 같아요.

description: Snowsight가 각 입력 필드 아래에 표시하는 사람이 읽을 수 있는 도움말 텍스트. 원시 JSON 키를 자기 설명형 양식 필드로 바꿔요.
value: 알림의 SQL이 SYSTEM$GET_ALERT_CONFIG을 통해 읽는 실제 런타임 값. 값과 메타데이터를 분리하면 UI가 풍부한 컨트롤을 렌더링하는 동안 SQL은 value 리프만 읽으면 돼요.
options 배열과 active 선택기: 고정된 유효 선택 집합(예: 알림 채널 또는 모니터링 범위)이 있는 필드의 경우 options 배열이 선택지를 나열하고 active가 현재 선택을 추적해요. Snowsight는 이를 자유 텍스트 입력 대신 드롭다운으로 렌더링해요.
중첩 채널 객체: 각 알림 채널(예: EMAIL 또는 WEBHOOK)은 자체 하위 필드(통합 이름, 수신자)를 가져요. Snowsight는 active인 채널에 따라 관련 하위 필드를 표시하거나 숨겨요.
계층적 범위 객체: 범위 수준이 어떤 하위 필드가 관련 있는지 제어해요. 예를 들어 DATABASE를 선택하면 데이터베이스 선택기가 표시되고, SCHEMA를 선택하면 데이터베이스와 스키마 선택기가 둘 다 표시돼요.

템플릿의 SQL은 SYSTEM$GET_ALERT_CONFIG을 사용해 런타임에 value 필드만 읽어요. SQL로 구성 구조를 수정하면(예: JSON을 펼치거나 메타데이터 키를 제거) Snowsight는 플랫 키-값 편집기로 폴백해요.

SQL로 템플릿에서 알림 생성

Snowsight에 더해 SQL에서 직접 템플릿으로 알림을 만들 수 있어요. 이는 스크립팅, Terraform 및 Snowsight 외부의 다른 호출자에 유용해요.

SYSTEM$LIST_ALERT_TEMPLATES으로 사용 가능한 템플릿을 나열해요.
SYSTEM$GET_ALERT_TEMPLATE으로 템플릿의 변수, 데이터 타입, 기본값, 허용 값을 검사해요.
TEMPLATE_PARAMS 절에 템플릿의 변수를 전달해 CREATE ALERT … FROM TEMPLATE으로 알림을 만들어요. 나중에 변수를 변경하려면 ALTER ALERT … FROM TEMPLATE을 사용해요.

예를 들어:

CREATE OR REPLACE ALERT my_db.my_schema.task_error_rate_alert
  FROM TEMPLATE TASKS_ERROR_RATE
  WAREHOUSE = my_wh
  SCHEDULE = '30 MINUTE'
  TEMPLATE_PARAMS = '{
    "template_variables": { "ERROR_RATE_THRESHOLD": 0.4 },
    "notification_config": {
      "notification_integration": "my_email_int",
      "email_config": { "toAddress": ["[email protected]"] }
    }
  }';

Snowflake는 서버에서 템플릿을 렌더링하므로 전체 구성 JSON을 직접 구성하지 않아요. Snowflake는 문이 컴파일될 때 변수 바인딩을 검증하므로 범위를 벗어난 임계값이나 알 수 없는 알림 통합 같은 잘못된 값은 알림이 생성되기 전에 보고돼요.

알림 일정 기반 타임스탬프 지정

어떤 경우에는 알림 일정에 기반한 조건이나 작업을 정의해야 할 수 있어요.

예를 들어 테이블에 행이 추가된 시점을 나타내는 타임스탬프 열이 있고, 마지막으로 성공적으로 평가된 알림과 현재 예정된 알림 사이에 새 행이 추가되었는지 알림을 보내고 싶다고 가정해 봐요. 즉, 다음을 평가하고 싶어요.

<now> - <last_execution_of_the_alert>

CURRENT_TIMESTAMP와 알림의 예정 시간을 사용해 이 시간 범위를 계산하면, 계산된 범위는 알림이 예정된 시간과 조건이 실제로 평가되는 시간 사이의 지연 시간을 고려하지 않아요.

대신 현재 예정 알림과 마지막으로 성공적으로 평가된 알림의 타임스탬프가 필요할 때는 다음 함수를 사용해요.

SCHEDULED_TIME은 현재 알림이 예정된 시점을 나타내는 타임스탬프를 반환해요.
LAST_SUCCESSFUL_SCHEDULED_TIME은 마지막으로 성공적으로 평가된 알림이 예정된 시점을 나타내는 타임스탬프를 반환해요.

이 함수는 SNOWFLAKE.ALERT 스키마에 정의돼 있어요. 이 함수를 호출하려면 SNOWFLAKE.ALERT_VIEWER 데이터베이스 역할이 부여된 역할을 사용해야 해요. 이 역할을 다른 역할에 부여하려면 GRANT DATABASE ROLE 명령을 사용해요. 예를 들어 커스텀 역할 alert_role에 이 역할을 부여하려면 다음을 실행해요.

GRANT DATABASE ROLE SNOWFLAKE.ALERT_VIEWER TO ROLE alert_role;

다음 예시는 마지막으로 성공적으로 평가된 알림이 예정된 시점과 현재 알림이 예정된 시점 사이에 my_table에 새 행이 추가되었는지 이메일 메시지를 보내요.

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(...);

알림 작업의 조건 SQL 문 결과 확인

알림의 작업 내에서 조건에 대한 SQL 문의 결과를 확인해야 한다면:

GET_CONDITION_QUERY_UUID 함수를 호출해 조건에 대한 SQL 문의 쿼리 ID를 가져와요.
쿼리 ID를 RESULT_SCAN 함수에 전달해 그 SQL 문 실행의 결과를 가져와요.

예를 들어:

CREATE ALERT my_alert
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
    SELECT * FROM my_source_table))
  THEN
    BEGIN
      LET condition_result_set RESULTSET :=
        (SELECT * FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID())));
      ...
    END;

알림 수동 실행

어떤 경우에는 알림을 수동으로 실행해야 할 수 있어요. 예를 들어:

새 알림을 만들 때 알림이 예상대로 작동하는지 확인하고 싶을 수 있어요.
데이터 파이프라인의 특정 시점에 알림을 실행하고 싶을 수 있어요. 예를 들어 저장 프로시저 호출 끝에 알림을 실행하고 싶을 수 있어요.

알림을 수동으로 실행하려면 EXECUTE ALERT 명령을 실행해요.

EXECUTE ALERT my_alert;

참고(Note): EXECUTE ALERT로 새 데이터 기반 알림을 실행할 수 없어요.

EXECUTE ALERT 명령은 알림에 정의된 일정과 무관하게 알림의 단일 실행을 수동으로 트리거해요.

이 명령을 대화형으로 실행할 수 있어요. 저장 프로시저나 Snowflake Scripting 블록 내부에서도 이 명령을 실행할 수 있어요.

이 명령을 실행하는 데 필요한 권한과 일시 중단·실행·예약된 알림에 대한 이 명령의 효과에 대한 자세한 내용은 EXECUTE ALERT을 참고해요.

알림 일시 중단·재개

알림이 일시적으로 실행되지 않도록 해야 한다면 ALTER ALERT … SUSPEND 명령을 실행해 알림을 일시 중단할 수 있어요. 예를 들어:

ALTER ALERT my_alert SUSPEND;

일시 중단된 알림을 재개하려면 ALTER ALERT … RESUME 명령을 실행해요. 예를 들어:

ALTER ALERT my_alert RESUME;

참고(Note): 알림의 소유자가 아니라면 알림을 일시 중단하거나 재개하려면 알림에 대한 OPERATE 권한이 있어야 해요.

실패 실행 후 알림 자동 일시 중단

지정된 횟수의 연속 실패 실행 후 알림을 자동으로 일시 중단해요.

알림에 SUSPEND_ALERT_AFTER_NUM_FAILURES = *number* 파라미터를 설정해요. 파라미터가 0보다 큰 값으로 설정되면 알림은 실패하거나 타임아웃되는(예: ACTION_FAILED 또는 CONDITION_FAILED 상태로 끝나는 실행) 지정된 횟수의 연속 알림 실행 후 자동으로 일시 중단돼요. 알림 실행이 성공하거나 알림이 수동으로 일시 중단·재개되면 카운터가 0으로 재설정돼요.

파라미터는 CREATE ALERT로 알림을 만들 때 또는 나중에 ALTER ALERT로 설정할 수 있어요.

SUSPEND_ALERT_AFTER_NUM_FAILURES 파라미터는 계정, 데이터베이스 또는 스키마 수준에서도 설정할 수 있어요. 이 설정은 수정된 객체에 포함된 모든 알림에 적용돼요. 더 낮은 수준에서 파라미터를 명시적으로 설정하면 더 높은 수준에서 설정된 파라미터 값을 재정의한다는 점을 주목해요.

알림이 자동으로 일시 중단되면:

알림은 재개할 때까지 일정에서 실행되지 않아요.
SHOW ALERTS는 was_auto_suspended = TRUE로 알림을 SUSPENDED 상태로 보고해요.
ALERT_HISTORY에서 자동 일시 중단을 트리거한 실행은 WAS_AUTO_SUSPENDED = TRUE로 표시돼요.

자동 일시 중단된 알림을 재개하려면 ALTER ALERT … RESUME 명령을 실행해요.

알림 수정

알림의 속성을 수정하려면 ALTER ALERT 명령을 실행해요.

참고(Note):

알림의 속성을 수정하려면 알림의 소유자여야 해요.

새 데이터 기반 알림을 일정 기반 알림으로 변경할 수 없어요. 마찬가지로 일정 기반 알림을 새 데이터 기반 알림으로 변경할 수도 없어요.

예를 들어:

my_alert이라는 알림의 웨어하우스를 my_other_warehouse로 변경하려면 다음을 실행해요.

ALTER ALERT my_alert SET WAREHOUSE = my_other_warehouse;

my_alert이라는 알림의 일정을 2분마다 평가되도록 변경하려면 다음을 실행해요.

ALTER ALERT my_alert SET SCHEDULE = '2 minutes';

my_alert이라는 알림의 조건을 gauge라는 테이블의 행 중 어떤 것이 gauge_value 열에서 300보다 큰 값을 갖는 경우 알림을 받도록 변경하려면 다음을 실행해요.

ALTER ALERT my_alert MODIFY CONDITION EXISTS (SELECT gauge_value FROM gauge WHERE gauge_value>300);

my_alert이라는 알림의 작업을 CALL my_procedure()로 변경하려면 다음을 실행해요.

ALTER ALERT my_alert MODIFY ACTION CALL my_procedure();

알림 삭제

알림을 삭제하려면 DROP ALERT 명령을 실행해요. 예를 들어:

DROP ALERT my_alert;

알림이 존재하지 않아도 오류를 발생시키지 않고 삭제하려면 다음을 실행해요.

DROP ALERT IF EXISTS my_alert;

참고(Note): 알림을 삭제하려면 알림의 소유자여야 해요.

알림에 대한 세부정보 보기

계정, 데이터베이스 또는 스키마에서 생성된 알림을 나열하려면 SHOW ALERTS 명령을 실행해요. 예를 들어 현재 스키마에서 생성된 알림을 나열하려면 다음 명령을 실행해요.

SHOW ALERTS;

이 명령은 소유한 알림과 MONITOR 또는 OPERATE 권한이 있는 알림을 나열해요.

특정 알림에 대한 세부정보를 보려면 DESCRIBE ALERT 명령을 실행해요. 예를 들어:

DESC ALERT my_alert;

참고(Note): 알림의 소유자가 아니라면 알림의 세부정보를 보려면 알림에 대한 MONITOR 또는 OPERATE 권한이 있어야 해요.

알림 복제(클로닝)

알림을 복제할 수 있어요(CREATE ALERT … CLONE을 사용하거나 알림을 포함하는 데이터베이스나 스키마를 복제해서).

서버리스 알림을 복제한다면 전역 EXECUTE MANAGED ALERT 권한이 있는 역할을 사용할 필요가 없어요. 하지만 알림을 소유하는 역할에 EXECUTE MANAGED ALERT 권한이 부여될 때까지 그 알림을 재개할 수 없어요.

알림 실행 모니터링

알림의 실행을 모니터링하려면:

알림에 대해 지정된 작업의 결과를 확인할 수 있어요. 예를 들어 작업이 테이블에 행을 삽입했다면 테이블에서 새 행을 확인할 수 있어요.
다음 중 하나를 사용해 알림 실행 이력을 봐요.
- INFORMATION_SCHEMA 스키마의 ALERT_HISTORY 테이블 함수.
- 예를 들어 지난 1시간 동안의 알림 실행을 보려면 다음 문을 실행해요.

SELECT *
FROM
  TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
    SCHEDULED_TIME_RANGE_START
=>dateadd('hour',-1,current_timestamp())))
ORDER BY SCHEDULED_TIME DESC;

공유 SNOWFLAKE 데이터베이스의 ACCOUNT_USAGE 스키마에 있는 ALERT_HISTORY 뷰.

쿼리 이력에서 쿼리를 실행한 사용자의 이름은 SYSTEM이에요. (알림은 시스템 서비스가 실행해요.)

서버리스 알림의 쿼리 이력 보기

서버리스 알림의 쿼리 이력을 보려면 알림의 소유자이거나, 알림 자체에 MONITOR 또는 OPERATE 권한이 있는 역할을 사용해야 해요. (이는 웨어하우스에 MONITOR 또는 OPERATE 권한이 필요한 웨어하우스를 사용하는 알림과 다르다.)

예를 들어 my_alert 알림의 쿼리 이력을 볼 때 my_alert_role 역할을 사용하려 한다고 가정해 봐요. my_alert_role이 my_alert의 소유자가 아니라면 그 역할에 알림에 대한 MONITOR 또는 OPERATE 권한을 부여해야 해요.

GRANT MONITOR ON ALERT my_alert TO ROLE my_alert_role;

역할에 이 권한이 부여되면 그 역할을 사용해 알림의 쿼리 이력을 볼 수 있어요.

USE ROLE my_alert_role;

SELECT query_text FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
  WHERE query_text LIKE '%Some condition%'
    OR query_text LIKE '%Some action%'
  ORDER BY start_time DESC;

더 알아보기 (Learn more)

Snowsight의 알림 — Snowsight 알림 UI
CREATE ALERT — 알림 생성 명령
이메일 알림 — 이메일 알림 통합