Snowflake の使いすぎを月の上限で止める｜リソースモニターと予算の置き方、止まった朝の戻し方

月のクレジットに上限を決めておけば、そこで Snowflake が止めてくれる。リソースモニターを設定するときは、そう考えて数字を入れると思います。ところが試してみると、使用量の数字は遅れて追いつき、そのあいだも実行中のクエリは動き続けました。モニターが数えないサーバーレスの機能もあります。

そこで上限は、アカウント全体のモニター・ウェアハウスごとのモニター・予算の3つで役割を分けて置きます。止めるしきい値は100%より手前に置き、止まった朝に誰が上限を上げるかを先に決めておきます。本番で使う SQL は、後半にまとめています。

画面は、Snowflake の導入を支援している当社のトライアルのアカウントで撮りました。上限を1クレジットにしたモニターを付け、重いクエリを実行したときのものです。

使用量の表示は数分遅れて追いつき、そのあいだに上限を越えて使えた

リソースモニターは、ウェアハウスが使ったクレジットを数え、決めた割合に達したら通知したり止めたりする仕組みです。月の上限は CREDIT_QUOTA で、割合は TRIGGERS で決めます。この割合を、しきい値と呼びます。しきい値に達したときの動作は NOTIFY・SUSPEND・SUSPEND_IMMEDIATE の3つで、違いは料金とコストの記事に書きました。

上限を1クレジットにしたモニターを、新しく作った Medium のウェアハウスに付けました。そのウェアハウスで、4分で打ち切る重いクエリを3回実行し、合間に使用量を見ています。Medium は1時間に4クレジット使う大きさなので、15分ほど動けば上限に届く計算です。

1回目を18時50分、2回目を18時55分に始めました。2回目を始めた時点でも、18時58分になっても、使用量は 0.00 のままです。19時を過ぎて見ると、使用量は一度に 0.83 になっていました。

その表示を見てから、19時に3回目を始めました。3回目は打ち切りの4分まで動き、19時5分の表示も 0.83 のままでした。19時7分ごろに見ると、使用量は1.28、残りは-0.28です。

100%で SUSPEND するしきい値を置いていても、実行中のクエリは止まりませんでした。計算上は上限を越えていたあいだも、表示は 0.83 のままで、3回目は最後まで動いています。公式も、SUSPEND は実行中のクエリが終わるのを待つので、上限を越えて使うことがあると書いています。

19時7分にはウェアハウスも一時停止の表示でしたが、モニターが止めたものとは言い切れません。このウェアハウスは、使われないと60秒で自動で一時停止する設定だったからです。モニターが新しいクエリを断るようになったことは、次の節のエラーで確かめました。

19時7分の表示で上限を越えていた分は 0.28 クレジットで、Medium が4分あまり動く量です。上限に対する28%という割合は、上限1・Medium・4分のクエリという、この試し方での値です。越える量はクレジットで決まるので、上限が大きければ割合は小さくなります。表示の遅れは、このときは5〜10分ほどでした。1回見ただけなので、いつも同じとは限りません。

アカウント全体のモニターの数字も、遅れていたように見えました。朝10時7分に4.25だった使用量が、夕方には4.58になっていました。その間、ウェアハウスで計算はほとんどしていません。

ウェアハウスの1時間ごとの使用量を見ると、9時台に 0.639、10時台に 0.105 の計算のクレジットを使っていました。10時7分の4.25は、9時台からの分をまだ数え終えていなかった、と当社は見ています。確かめてはいません。

トライアルは、申込ページの表示では、30日間・400米ドル分の無料クレジットで始まります（2026年10月21日に表示を確認）。Snowsight に出るトライアルの残りの表示も、試した直後には変わりませんでした。止める判断は、その場の数字には任せられません。しきい値を100%より手前に置く理由の1つは、ここにあります。

試したのは、Enterprise Edition・AWS の東京リージョンのトライアルのアカウントで、ロールは ACCOUNTADMIN です。リソースモニターを作れるのは ACCOUNTADMIN だけです。

自分のアカウントで試す前に、SHOW RESOURCE MONITORS で level が ACCOUNT の行を見ます。suspend_at か suspend_immediately_at に割合があれば、止まるまでの残りは、その割合までで数えます。式にすると、上限×止めるしきい値の割合−使用量です。

その残りを、試しに使う見込みと比べます。このトライアルでは、試したウェアハウスの分が表示で1.28、確かめのクエリなども足すと、アカウント全体で1.72増えました。表示は遅れて追いつくので、使用量は表示より多いと見ます。止まるまでの残りが2クレジットより少なければ、本番のアカウントでは試しません。

たとえば上限20で、90%で SUSPEND するなら、止まるのは18です。使用量が16を越えていれば、試しません。当社のトライアルは上限5に対して使用量が4.58だったので、上限を10に上げてから試しました。

上限に小数は通らず、0.05 も 0.5 もエラーになったので、1にしました。載せた SQL は当社が実行した文と同じで、名前だけを TEST_SPEND_LIMIT_ で始まる検証用の名前に置き換えています。CREATE に OR REPLACE を付けていないので、同じ名前のものがあれば、作らずにエラーで止まります。

CREATE RESOURCE MONITOR TEST_SPEND_LIMIT_RM WITH CREDIT_QUOTA = 1 TRIGGERS ON 50 PERCENT DO NOTIFY ON 100 PERCENT DO SUSPEND;
CREATE WAREHOUSE TEST_SPEND_LIMIT_WH WITH WAREHOUSE_SIZE='MEDIUM' AUTO_SUSPEND=60 AUTO_RESUME=TRUE INITIALLY_SUSPENDED=TRUE RESOURCE_MONITOR=TEST_SPEND_LIMIT_RM STATEMENT_TIMEOUT_IN_SECONDS=1500;
SHOW RESOURCE MONITORS LIKE 'TEST_SPEND_LIMIT_RM';

CREATE WAREHOUSE を実行すると、ワークシートで使うウェアハウスが新しいほうに切り替わりました。ワークシートは、Snowsight で SQL を書いて実行する画面です。このあと実行するクエリは、すべて新しいウェアハウスの分として数えられます。

重いクエリは、行を作る関数 GENERATOR で1000億行を作り、乱数の種類を数えるものです。そのままでは終わらない重さなので、セッションに240秒の打ち切りを決めました。

USE WAREHOUSE TEST_SPEND_LIMIT_WH;
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 240;
SELECT COUNT(DISTINCT RANDOM()) FROM TABLE(GENERATOR(ROWCOUNT => 100000000000));
-- 上のクエリを3回実行し、合間に次の2つで使用量と状態を見た
SHOW RESOURCE MONITORS LIKE 'TEST_SPEND_LIMIT_RM';
SHOW WAREHOUSES LIKE 'TEST_SPEND_LIMIT_WH';

上限に達したウェアハウスは、手で再開することもできなかった

表示が1.28になったあと、1000行を数えるだけの小さいクエリを実行しました。結果は、次のエラーです。

名前の所を … にすると、エラーの文は次のとおりです。

Warehouse '…' cannot be resumed because resource monitor '…' has exceeded its quota.

引用符の中に、止まったウェアハウスと、上限に達したモニターの名前が入ります。クエリ履歴では、エラーコード 90073 の失敗として残っていました。ALTER WAREHOUSE … RESUME で手で再開しようとしても、同じ文で失敗しました。

公式によると、再開できるようになるのは、次のどれかが起きたときです。次の区切りが始まる、上限を上げる、止めるしきい値を上げる、ウェアハウスをモニターから外す、モニターを DROP する、の5つです。外すのと DROP は、上限そのものが無くなります。DROP したモニターは元に戻せない、と公式にあります。

試しに、上限を2クレジットに上げました。直後の SHOW WAREHOUSES では、まだ一時停止のままです。そこで同じ小さいクエリを実行すると、エラーにならず、1000 が返りました。

このウェアハウスは AUTO_RESUME を TRUE にしていたので、クエリが来たところで自動で再開したと考えられます。公式に書かれているのは「再開できる」までで、自動で再開するとは書かれていません。AUTO_RESUME が FALSE のウェアハウスなら、上げたあとに手で RESUME するはずです。こちらは試していません。

上の手順の SQL は次のとおりです。最初の2行はエラーになるので、1行ずつ実行します。

SELECT COUNT(*) FROM TABLE(GENERATOR(ROWCOUNT => 1000));  -- エラーになる（90073）
ALTER WAREHOUSE TEST_SPEND_LIMIT_WH RESUME;  -- エラーになる（90073）
ALTER RESOURCE MONITOR TEST_SPEND_LIMIT_RM SET CREDIT_QUOTA = 2;
SELECT COUNT(*) FROM TABLE(GENERATOR(ROWCOUNT => 1000));
ALTER WAREHOUSE TEST_SPEND_LIMIT_WH SUSPEND;

試したウェアハウスとモニターは、ここで片付けます。消すのは、作った TEST_SPEND_LIMIT_ で始まる2つだけです。LIKE のような名前の型で、まとめて消すことはしません。

DROP WAREHOUSE TEST_SPEND_LIMIT_WH;
DROP RESOURCE MONITOR TEST_SPEND_LIMIT_RM;
-- このあと、ワークシートのウェアハウスを、いつも使うものに USE WAREHOUSE で戻す

このウェアハウスの分は19時7分の表示で1.28クレジットで、そのあと再開した分が加わります。有料のアカウントで試すなら、その分は請求されます。

モニターが数えないサーバーレスの分は、予算の履歴に出ていた

リソースモニターが数えるのは、ウェアハウスと、それを支えるクラウドサービスのクレジットです。Snowpipe・自動クラスタリング・マテリアライズドビューのようなサーバーレスの機能と、AI のサービスは数えません。公式は、それらを見るには予算を使うよう案内しています。

予算は、月の計算の費用にクレジットで上限を決め、超えそうなときに知らせる機能です。アカウント全体を見るアカウント予算は、有効にしてから使います。公式のトラブル対応には、新しいアカウントではまだ使えないことがある、とあります。このトライアルでは、有効にする文がそのまま通りました。

CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!ACTIVATE();
CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!GET_SPENDING_HISTORY();

使用量の履歴は14行で、有効にしたのは10月21日なのに、10月13日からの日ごとの値が出ました。公式も、月の途中で有効にすると、月初からの分をさかのぼって埋めると説明しています。

枠を付けた8行目は、データ品質の監視のサーバーレスの分を表す DATA_QUALITY_MONITORING の行です。予算の日付は UTC で数えていると見られます。当社は日本時間の10月21日未明に、データメトリック関数の記事で関数を試しており、その分だと見ていますが、突き合わせてはいません。この分がモニターの数字に入っていなかったかも、同じ時間で並べては確かめていません。

予算は通知だけで、上限に達しても止めません。通知は予測で動き、月末に上限を超えそうだと判断した日に、1日1回送られます。既定では、予測が上限を10%超えたときからです。止めたいなら、予算が呼ぶストアドプロシージャに、止める処理を書く必要があります。これはカスタムアクションと呼ばれ、実績で動くものは月に1回までです。カスタムアクションは試していません。

予算の数字は、既定で最大6.5時間遅れて反映されます。1時間ごとにもできますが、そうすると予算そのものの費用が12倍になります。予算は、裏で動くサーバーレスのタスクとストレージの分だけ、それ自体にも費用がかかります。

試し終えたあと、当社は予算を DEACTIVATE して、有効にする前の状態に戻しました。DEACTIVATE すると、履歴と設定が消えます。自分のアカウントで試すなら、そのまま本番で使うつもりで有効にし、DEACTIVATE はしないでください。

アカウント全体・ウェアハウスごと・予算で、上限の役割を分ける

3つは、数えるものも、止めるかどうかも違います。並べると次のとおりです。

日本時間の9時は、公式の「UTC の0時」を当社が換算したものです。毎月1日の0時から9時までに使った分は、前の月の区切りに入ります。10月21日に作ったモニターでも、区切りの始まりの start_time は、10月1日の UTC の0時と表示されていました。

アカウント全体のモニターには、50%と75%で通知、90%で SUSPEND、100%で SUSPEND_IMMEDIATE を置きます。止めるしきい値を100%より手前に置く理由は2つです。公式が90%などの余裕を勧めていることと、最初の節で見たように、表示が遅れて追いつき、SUSPEND が実行中のクエリを止めないことです。

100%の SUSPEND_IMMEDIATE は、実行中のクエリも取り消します。ただ、取り消すところは試していません。表示が追いつく前に終わるクエリは、SUSPEND_IMMEDIATE でも、取り消される前に使い終わるはずです。通知を2回にしたのは、上げるか待つかを決める時間を作るためです。

90%までの10%の余裕で足りるかは、上限の大きさで変わります。目安は、表示が追いつくまでに動きうるウェアハウスの1時間のクレジットに、台数と遅れの時間を掛けた量です。それが上限の10%より大きければ、止めるしきい値をもっと手前に置きます。

ウェアハウスには、STATEMENT_TIMEOUT_IN_SECONDS で打ち切りの秒数を決められます。決めておくと、1回のクエリが動き続ける時間にも上限ができます。ただし、そのウェアハウスでいちばん長くかかる正規の処理より短くすると、その処理が取り消されます。最長の時間は、週ごとのクエリ点検の記事の集計で先に見ておきます。

ウェアハウスごとのモニターは、使い方の分かれるウェアハウスに1つずつ付けます。公式も、1つのモニターに1つのウェアハウスを勧めています。両方のモニターが当てはまるときは、先に上限に達したほうが止めます。

ウェアハウスごとの上限の合計を、アカウント全体の上限の9割より小さくしておくと、1つのウェアハウスの使いすぎで、アカウント全体が止まりにくくなります。すべてのウェアハウスにモニターを付けた場合の話で、越えて使う分と、止められないクラウドサービスの分は残ります。上限は整数で決めるので、割り振った数は切り捨てて整数にします。

通知は既定で無効です。アカウント全体のモニターには NOTIFY_USERS を付けられず、通知は管理者にだけ届きます。届くのは、メールアドレスを確認済みにし、Snowsight のプロフィールで通知をオンにした管理者です。項目の名前は「Enable notifications from resource monitors」です。

当社のトライアルのアカウント全体のモニターにも、50%の通知を置いていました。ただ、管理者の通知の設定は見ておらず、通知が届いたかは確かめていません。ウェアハウスごとのモニターは、NOTIFY_USERS で管理者以外も5人まで加えられ、メールで届きます。通知のメールは試していません。

予算の上限は、アカウント全体のモニターの上限に、サーバーレスの機能で使う見込みを足した数にします。予算はモニターが数えない分も数えるので、同じ数にすると早く通知が来すぎます。

上限はクレジットで決めますが、1クレジットの金額は、エディション・クラウド・リージョンで違います。Snowflake の料金ページで自社の条件の単価を確かめ、月に使ってよい金額からクレジットの数に直します。

止まった朝は、どのモニターかを確かめてから、上げるか待つかを決める

止まった朝に手が止まらないよう、誰が上限を上げてよいかを先に決めておきます。上限を上げるのは費用の判断なので、決めるのは月の上限を決めた人、つまり費用の責任者です。手を動かすのはデータの担当です。

上限としきい値の変更は、モニターの MODIFY 権限があれば、ACCOUNTADMIN でなくてもできると公式にあります。データの担当のロールに、MODIFY と、ウェアハウスを再開する OPERATE を付与しておきます。ウェアハウスごとの使用量を出す関数は、ACCOUNTADMIN か MONITOR USAGE を持つロールにしか結果を返しません。そのため、MONITOR USAGE も付与します。そうしておけば、朝に管理者を探さずに済みます。ロールの分け方は、ロールの記事に書きました。

最初に、エラーの文に出るモニターの名前を見ます。試したのはウェアハウスごとのモニターで止まったときで、文にモニターの名前が出ました。アカウント全体のモニターで止まったときの文は、確かめていません。

アカウント全体のモニターなら、すべてのウェアハウスが止まっているはずです。ウェアハウスで動かしているタスクも動かないので、取り込みの記事の記録テーブルも確かめます。

次に、SHOW RESOURCE MONITORS で、そのモニターの使用量と残りを見ます。SHOW RESOURCE MONITORS は、動いているウェアハウスが無くても実行できます。ウェアハウスがどれも動かない朝は、集計のクエリは実行できないはずなので、まず SHOW で見ます。

ウェアハウスごとの使用量は、ウェアハウスが使えるときに WAREHOUSE_METERING_HISTORY で見ます。ACCOUNT_USAGE のビューは最大3時間遅れます。直近の分は、FROM 句でテーブルのように使う関数、テーブル関数で見ます。

試したときは、データベースを付けずに呼ぶと Invalid identifier のエラーになりました。SNOWFLAKE.INFORMATION_SCHEMA と書くと通ります。18時59分に直近2時間を出すと、18時50分からの使用も、まだ0行でした。

使った中身が予定どおりの処理で、月末までに要るなら、上限を上げます。上げる量は、月末までに要る分だけにします。書き間違えたクエリや止め忘れが原因なら、止めたまま原因を直し、そのあと上げるか待つかを決めます。急がないなら、次の区切りを待ちます。上げたあとは、誰が、いつ、何クレジット上げたかを残し、翌月の上限を決め直します。

本番の SQL は、最初の設定・止まった朝・毎週の3つに分けて実行する

SQL は、実行する時期で3つに分けました。最初の設定は一度だけ、止まった朝の分はその朝に、毎週の分は週に1回実行します。山かっこの所を、自社の名前と値に替えて使います。

コメントに「ここは試していない」とある部分と、行末に「試していない」とある行は、当社のトライアルで実行していません。印の無い行は、試した文と同じ形で、名前と数だけが違います。

最初の設定です。アカウント全体のモニターがすでにあるときは、作らずに (3) で直します。ALTER ACCOUNT と ALTER WAREHOUSE は、すでに付いているモニターを付け替えるので、先に (1) で確かめます。

最初の設定は、まず USE ROLE ACCOUNTADMIN で始め、(1) から順に進めます。SHOW RESOURCE MONITORS は、実行したロールが権限を持つモニターしか出しません。ほかのロールでは、アカウント全体のモニターを見落とすおそれがあります。

-- 最初の設定は、すべて ACCOUNTADMIN で実行する
USE ROLE ACCOUNTADMIN;  -- 試していない
-- (1) 今あるモニターと、ウェアハウスに付いているモニターを確かめる
SHOW RESOURCE MONITORS;
SHOW WAREHOUSES;  -- 試していない
-- (2) level が ACCOUNT の行が無いときだけ作る。上限は整数（ここは試していない）
CREATE RESOURCE MONITOR <アカウントのモニター> WITH CREDIT_QUOTA = <月の上限（整数）>
  TRIGGERS ON 50 PERCENT DO NOTIFY
           ON 75 PERCENT DO NOTIFY
           ON 90 PERCENT DO SUSPEND
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER ACCOUNT SET RESOURCE_MONITOR = <アカウントのモニター>;
-- (3) level が ACCOUNT の行があるときは、そのモニターを直す。TRIGGERS は全部の置き換えなので4つとも書く（ここは試していない）
ALTER RESOURCE MONITOR <今のアカウントのモニター> SET CREDIT_QUOTA = <月の上限（整数）>
  TRIGGERS ON 50 PERCENT DO NOTIFY
           ON 75 PERCENT DO NOTIFY
           ON 90 PERCENT DO SUSPEND
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;
-- (4) ウェアハウスごとのモニター。(1) の resource_monitor の列が空のウェアハウスに付ける。付いていれば付け替わる（ここは試していない）
CREATE RESOURCE MONITOR <ウェアハウスのモニター> WITH CREDIT_QUOTA = <そのウェアハウスの月の上限（整数）>
  NOTIFY_USERS = (<通知を受け取るユーザー>)
  TRIGGERS ON 50 PERCENT DO NOTIFY
           ON 75 PERCENT DO NOTIFY
           ON 90 PERCENT DO SUSPEND
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE <ウェアハウス> SET RESOURCE_MONITOR = <ウェアハウスのモニター>;
-- 打ち切りの秒数は、そのウェアハウスでいちばん長くかかる正規の処理より長くする
ALTER WAREHOUSE <ウェアハウス> SET STATEMENT_TIMEOUT_IN_SECONDS = <秒>;
-- (5) 止まった朝に上限を上げ、ウェアハウスを再開するデータの担当のロールへ（ここは試していない）
GRANT MODIFY, MONITOR ON RESOURCE MONITOR <アカウントのモニター> TO ROLE <データの担当のロール>;
GRANT MODIFY, MONITOR ON RESOURCE MONITOR <ウェアハウスのモニター> TO ROLE <データの担当のロール>;
GRANT OPERATE ON WAREHOUSE <ウェアハウス> TO ROLE <データの担当のロール>;
-- 止まった朝の (2) の使用量の関数と、毎週の (2)(3) の結果を見るための権限
GRANT MONITOR USAGE ON ACCOUNT TO ROLE <データの担当のロール>;
GRANT DATABASE ROLE SNOWFLAKE.USAGE_VIEWER TO ROLE <データの担当のロール>;
GRANT APPLICATION ROLE SNOWFLAKE.BUDGET_VIEWER TO ROLE <データの担当のロール>;
-- (6) アカウント予算。ACCOUNTADMIN か、SNOWFLAKE.BUDGET_ADMIN を付与したロールで実行する。メールは確認済みのアドレスだけ
CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!ACTIVATE();
CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!SET_SPENDING_LIMIT(<予算の上限（整数）>);
CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!SET_EMAIL_NOTIFICATIONS('<確認済みのメールアドレス>');  -- 試していない

(4) の NOTIFY_USERS に入れるユーザーは、メールアドレスを確認済みにしておきます。未確認の人が入っていると、SQL が失敗します。ウェアハウスにモニターを付ける ALTER WAREHOUSE は、ACCOUNTADMIN でないと実行できません。(5) の権限で、データの担当は上限としきい値を変えられますが、付け替えはできません。毎週の分では、ACCOUNT_USAGE のビューに USAGE_VIEWER、予算の履歴に BUDGET_VIEWER が要ります。これも (5) で付与します。

(3) の ALTER RESOURCE MONITOR では、TRIGGERS は全部の置き換えになり、足したものだけが加わるわけではありません。変えないしきい値も、もう一度書きます。

止まった朝の分です。(1) の SHOW の出力は、列の名前が小文字なので、RESULT_SCAN で選ぶときは二重引用符で囲みます。

-- (1) モニターの使用量と残り。SHOW は、動いているウェアハウスが無くても実行できる
SHOW RESOURCE MONITORS;
-- 次の SELECT はウェアハウスが要るかもしれない。動かなければ、SHOW の結果を目で見る
SELECT "name", "level", "credit_quota", "used_credits", "remaining_credits" FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));  -- 試していない
SHOW WAREHOUSES LIKE '<ウェアハウス>';
-- (2) ウェアハウスごとの直近24時間の使用量。ウェアハウスが使えるときだけ（ここは試していない）
SELECT WAREHOUSE_NAME, ROUND(SUM(CREDITS_USED), 2) AS CREDITS
FROM TABLE(SNOWFLAKE.INFORMATION_SCHEMA.WAREHOUSE_METERING_HISTORY(DATE_RANGE_START => DATEADD('HOUR', -24, CURRENT_TIMESTAMP())))
GROUP BY 1 ORDER BY 2 DESC;
-- (3) 費用の責任者が上げると決めたら、MODIFY を持つロールで上限を上げる
ALTER RESOURCE MONITOR <止めたモニター> SET CREDIT_QUOTA = <新しい上限（整数）>;
-- AUTO_RESUME が FALSE のウェアハウスは、OPERATE を持つロールで手で再開する
ALTER WAREHOUSE <ウェアハウス> RESUME;  -- 試していない

毎週の分です。(1) は、モニターごとに上限の何%を使ったかと、月の何%が過ぎたかを並べます。USED_PCT が MONTH_PCT より大きいモニターは、月末より前に上限に達する見込みです。

-- (1) モニターごとの使った割合と、月の経過の割合（ここは試していない）
SHOW RESOURCE MONITORS;
SELECT "name", "level", "credit_quota", "used_credits",
       ROUND(TO_NUMBER("used_credits", 18, 2) / NULLIF(TO_NUMBER("credit_quota", 18, 2), 0) * 100, 1) AS USED_PCT,
       ROUND((DAY(SYSDATE()) - 1 + HOUR(SYSDATE()) / 24) / DAY(LAST_DAY(SYSDATE())) * 100, 1) AS MONTH_PCT
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
ORDER BY USED_PCT DESC;
-- (2) ウェアハウスごと・週ごとのクレジット。直近8週（ここは試していない）
SELECT DATE_TRUNC('WEEK', START_TIME) AS WEEK_START, WAREHOUSE_NAME, ROUND(SUM(CREDITS_USED), 2) AS CREDITS
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE START_TIME >= DATEADD('WEEK', -8, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY 1, 3 DESC;
-- (3) 予算の直近7日を、サービスの種類ごとに（ここは試していない）
CALL SNOWFLAKE.LOCAL.ACCOUNT_ROOT_BUDGET!GET_SPENDING_HISTORY(TIME_LOWER_BOUND => DATEADD('DAYS', -7, CURRENT_TIMESTAMP()), TIME_UPPER_BOUND => CURRENT_TIMESTAMP());
SELECT SERVICE_TYPE, ROUND(SUM(CREDITS_SPENT), 3) AS CREDITS FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) GROUP BY 1 ORDER BY 2 DESC;

試した画面では credit_quota と used_credits の列が文字で出ていたので、(1) では数に直してから割っています。MONTH_PCT は既定の暦月の区切りで計算しているので、FREQUENCY を変えたモニターには当てはまりません。(3) の予算の行は、WAREHOUSE_METERING 以外の種類が増えていないかを見ます。

自分のアカウントのモニターの、止めるしきい値と通知の届き先を見る

自分のアカウントで SHOW RESOURCE MONITORS を実行し、level が ACCOUNT の行を探します。あれば、suspend_at と suspend_immediately_at の列で、止めるしきい値が100%より手前にあるかを見ます。通知は、管理者それぞれがプロフィールでオンにしているかを確かめます。

行が無ければ、最初の設定の (2) から始め、止まった朝に上限を上げる人も一緒に決めます。上限をいくつにし、どのウェアハウスに分けて付けるかは、使い方と予算の両方から決めます。当社の Snowflake 導入支援でも、その決め方から手伝っています。