Gestion des coûts des fonctions CortexAI avec Utilisation du compte¶
Les fonctions Snowflake Cortex AI (AI_COMPLETE, AI_SUMMARIZE, AI_TRANSLATE, AI_SENTIMENT et autres) consomment des crédits en fonction de l’utilisation des jetons ou des pages. Sans surveillance et sans contrôle, les coûts d’utilisation de ces fonctions peuvent augmenter rapidement en raison des éléments suivants :
Invites non optimisées générant des jetons excessifs
Requêtes de longue durée ou qui s’arrêtent
Absence de limites de dépenses par utilisateur
Mauvaise visibilité des modèles d’utilisation
Cette rubrique propose des stratégies pour surveiller, gérer et contrôler les coûts associés aux fonctions Snowflake CortexAI. À l’aide de la vue CORTEX_AI_FUNCTIONS_USAGE_HISTORY, vous pouvez suivre les modèles d’utilisation et mettre en œuvre des contrôles des coûts automatisés. Ces techniques peuvent vous aider à surveiller l’utilisation, à envoyer des alertes en cas de dépassement des limites de dépenses, à contrôler l’accès aux fonctions en fonction de limites mensuelles et à interrompre les requêtes qui s’emballent.
Vue de l’historique d’utilisation¶
La vue SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY fournit une télémétrie détaillée pour toutes les fonctions Cortex AI invoquées via SQL. La vue a un temps de latence maximum de 60 minutes, bien que les données puissent être disponibles en seulement 10 minutes après le début de l’exécution de la fonction. Pour plus d’informations sur cette vue, voir Vue CORTEX_AI_FUNCTIONS_USAGE_HISTORY.
Surveillance de base de l’utilisation¶
Les requêtes suivantes vous aident à comprendre vos modèles d’utilisation des fonctions AI. Exécutez-les vous-même régulièrement, ou intégrez-les dans des tableaux de bord pour une visibilité continue.
Consommation de crédit quotidienne par fonction et modèle¶
Suivez les tendances des dépenses quotidiennes pour identifier les pics d’utilisation et comprendre quelles fonctions et quels modèles consomment le plus de crédits.
SELECT
DATE_TRUNC('day', START_TIME) AS usage_date,
FUNCTION_NAME,
MODEL_NAME,
SUM(CREDITS) AS total_credits,
COUNT(DISTINCT QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
ORDER BY usage_date DESC, total_credits DESC;
Consommation mensuelle de crédit par utilisateur¶
Identifiez les principaux consommateurs et suivez les dépenses par utilisateur au fil du temps. Cette requête s’appuie sur la vue USERS pour fournir les informations relatives à l’utilisateur, notamment son adresse e-mail et son rôle par défaut, afin de faciliter l’identification et le suivi.
SELECT
DATE_TRUNC('month', h.START_TIME) AS usage_month,
u.NAME AS user_name,
u.EMAIL,
u.DEFAULT_ROLE,
SUM(h.CREDITS) AS total_credits,
COUNT(DISTINCT h.QUERY_ID) AS query_count
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('month', -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3, 4
ORDER BY usage_month DESC, total_credits DESC;
Contrôle des coûts¶
Définissez des mécanismes automatisés pour détecter les dépenses excessives et prendre des mesures correctives. Ces requêtes peuvent être utilisées indépendamment les unes des autres ou combinées pour une gouvernance complète des coûts.
Alerte de dépenses mensuelles au niveau du compte¶
Configurez une alerte automatique qui surveille la consommation mensuelle totale de crédits pour les fonctions AI sur l’ensemble de votre compte. Lorsque les dépenses dépassent un seuil défini, l’alerte envoie une notification par e-mail aux administrateurs désignés. La configuration de l’alerte nécessite les conditions préalables suivantes :
Le rôle ACCOUNTADMIN ou les privilèges appropriés pour créer des intégrations de notification et des alertes
Un entrepôt pour exécuter la vérification de la condition d’alerte
Les adresses e-mail vérifiées des destinataires de l’alerte
Tout d’abord, créez une intégration de notification si celle-ci n’existe pas déjà. Cet exemple remplace toute intégration existante nommée ai_cost_alerts.
CREATE OR REPLACE NOTIFICATION INTEGRATION ai_cost_alerts
TYPE = EMAIL
ENABLED = TRUE
ALLOWED_RECIPIENTS = ('admin@company.com', 'finops@company.com')
Ensuite, créez un tableau permettant de consigner la date d’envoi des alertes pour chaque mois. Ceci est utilisé pour éviter les alertes en double au sein d’un mois.
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ALERT_STATE (
ALERT_NAME VARCHAR NOT NULL,
ALERT_MONTH DATE NOT NULL,
SENT_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
CREDITS_AT_ALERT NUMBER(38,6),
PRIMARY KEY (ALERT_NAME, ALERT_MONTH)
);
Créez maintenant une procédure stockée pour vérifier si une alerte a déjà été envoyée durant le mois en cours, enregistrez l’état de l’alerte et envoyez la notification par e-mail.
CREATE OR REPLACE PROCEDURE SEND_MONTHLY_SPEND_ALERT(P_THRESHOLD FLOAT)
RETURNS VARCHAR
LANGUAGE JAVASCRIPT
EXECUTE AS CALLER
AS
$$
// Check if alert already sent this month
var check_sent = snowflake.execute({
sqlText: `SELECT COUNT(*) AS cnt FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE())`
});
check_sent.next();
var already_sent = check_sent.getColumnValue(1);
if (already_sent > 0) {
return 'Alert already sent for this month';
}
// Get current spend
var spend_result = snowflake.execute({
sqlText: `SELECT COALESCE(SUM(CREDITS), 0) AS total
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())`
});
spend_result.next();
var v_credits = spend_result.getColumnValue(1);
// Check threshold
if (v_credits <= P_THRESHOLD) {
return 'Threshold not exceeded. Current: ' + v_credits + ' / ' + P_THRESHOLD;
}
// Record alert
snowflake.execute({
sqlText: `INSERT INTO AI_FUNCTIONS_ALERT_STATE (ALERT_NAME, ALERT_MONTH, CREDITS_AT_ALERT)
VALUES ('monthly_spend', DATE_TRUNC('month', CURRENT_DATE()), ?)`,
binds: [v_credits]
});
// Send email - update the recipient email address
snowflake.execute({
sqlText: `CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'AI Functions Monthly Spend Alert',
'Monthly AI Function credit consumption has exceeded the threshold.\\n\\n' ||
'Current spend: ' || ${v_credits}::VARCHAR || ' credits\\n' ||
'Threshold: ' || ${P_THRESHOLD}::VARCHAR || ' credits\\n\\n' ||
'Please review usage accordingly.'
)`
});
return 'Alert sent. Credits: ' + v_credits;
$$;
Enfin, créez une alerte qui vérifie toutes les heures si l’utilisation dépasse le seuil de dépenses et qui appelle la procédure pour envoyer une notification si nécessaire. Vous devez ajuster la limite de 1 000 crédits, qui apparaît à deux endroits dans l’exemple ci-dessous, au seuil souhaité.
CREATE OR REPLACE ALERT ai_functions_monthly_spend_alert
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Runs every hour
IF (EXISTS (
SELECT 1
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATE_TRUNC('month', CURRENT_TIMESTAMP())
HAVING SUM(CREDITS) > 1000 -- adjust the limit accordingly
))
THEN
CALL SEND_MONTHLY_SPEND_ALERT(1000); -- please adjust the limit accordingly
-- enable the alert
ALTER ALERT ai_functions_monthly_spend_alert RESUME;
Astuce
À des fins de test, définissez d’abord la limite sur 0 pour déclencher l’alerte immédiatement. Recréez l’alerte avec le seuil souhaité après avoir confirmé qu’elle fonctionne comme prévu.
Après avoir testé avec un seuil de 0, exécutez la requête SQL suivante pour permettre à l’alerte de se déclencher à nouveau au cours du mois en cours.
DELETE FROM AI_FUNCTIONS_ALERT_STATE
WHERE ALERT_NAME = 'monthly_spend'
AND ALERT_MONTH = DATE_TRUNC('month', CURRENT_DATE());
Vous pouvez vous assurer que l’alerte fonctionne en interrogeant l’historique de l’alerte et la table d’état de l’alerte comme suit :
-- Make sure alert exists
SHOW ALERTS LIKE 'ai_functions_monthly_spend_alert';
-- Check alert history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
ALERT_NAME => 'ai_functions_monthly_spend_alert'
))
ORDER BY SCHEDULED_TIME DESC;
-- Check which months have had alerts sent
SELECT * FROM AI_FUNCTIONS_ALERT_STATE ORDER BY ALERT_MONTH DESC;
Limites de dépenses mensuelles par utilisateur¶
Cet exemple met en œuvre des limites de dépenses mensuelles par utilisateur. Un AI_FUNCTIONS_USER_ROLE personnalisé est attribué aux utilisateurs, qui leur donne accès aux fonctions Cortex AI. Une table stocke le budget mensuel de jetons des utilisateurs individuels. Lorsqu’un utilisateur dépasse son budget pour le mois, une tâche horaire révoque son accès aux fonctions AI en supprimant AI_FUNCTIONS_USER_ROLE. Une tâche mensuelle rétablit le rôle au début du mois suivant.
Important
Par défaut, tous les utilisateurs ont accès aux fonctions AI (et à d’autres fonctionnalités de Snowflake Cortex), car le rôle de base de données SNOWFLAKE.CORTEX_USER est attribué au rôlePUBLIC. Pour appliquer des limites par utilisateur, vous devez révoquer SNOWFLAKE.CORTEX_USER du rôle PUBLIC et ne l’attribuer que via AI_FUNCTIONS_USER_ROLE. Utilisez la requête SQL suivante pour révoquer le rôle de PUBLIC :
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;
Assurez-vous que tous les utilisateurs qui ont besoin d’accéder aux fonctionnalités Cortex ne disposent que du AI_FUNCTIONS_USER_ROLE. L’utilisation de tout autre rôle qui inclut SNOWFLAKE.CORTEX_USER permet aux utilisateurs de contourner les contrôles de limite de dépenses mis en œuvre dans cet exemple. Dans certains cas, vous pouvez utiliser un rôle plus spécifique ; par exemple, les utilisateurs qui n’ont besoin que d’accéder à Cortex Analyst peuvent se voir accorder le rôle SNOWFLAKE.CORTEX_ANALYST_USER au lieu de SNOWFLAKE.CORTEX_USER.
Pour configurer des limites de dépenses par utilisateur, créez d’abord un rôle qui contrôle l’accès aux fonctions AI, permettant de gérer cet accès séparément des autres privilèges.
-- Create a role specifically for AI Function access
CREATE ROLE IF NOT EXISTS AI_FUNCTIONS_USER_ROLE;
-- Grant necessary privileges to the role
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE AI_FUNCTIONS_USER_ROLE;
-- Grant usage on warehouse
GRANT USAGE ON WAREHOUSE AI_FUNCTIONS_WAREHOUSE TO ROLE AI_FUNCTIONS_USER_ROLE;
Maintenant, configurez la table de contrôle d’accès, qui permet de savoir quels utilisateurs ont accès aux fonctions AI, de connaître leurs limites de dépenses individuelles et de consulter l’historique des révocations. Elle sert de source de vérité pour les processus de surveillance automatisés et de restauration d’accès.
CREATE TABLE IF NOT EXISTS AI_FUNCTIONS_ACCESS_CONTROL (
USER_NAME VARCHAR NOT NULL,
USER_ID NUMBER,
GRANTED_AT TIMESTAMP_LTZ DEFAULT CURRENT_TIMESTAMP(),
MONTHLY_CREDIT_LIMIT NUMBER(38,6) DEFAULT 100, -- adjust the limit accordingly
IS_ACTIVE BOOLEAN DEFAULT TRUE,
REVOKED_AT TIMESTAMP_LTZ,
REVOCATION_REASON VARCHAR,
PRIMARY KEY (USER_NAME)
);
Ensuite, créez une procédure stockée pour accorder à un utilisateur l’accès aux fonctions AI et l’enregistrer dans la table de contrôle d’accès avec sa limite de dépenses. Le code recherche l’ID de l’utilisateur depuis la vue Utilisation du compte pour activer les jointures efficaces dans les requêtes de surveillance.
CREATE OR REPLACE PROCEDURE GRANT_AI_FUNCTIONS_ACCESS(
P_USER_NAME VARCHAR,
P_MONTHLY_LIMIT NUMBER(38,6) DEFAULT 100 -- adjust the limit accordingly
)
RETURNS VARCHAR
LANGUAGE SQL
AS
$$
DECLARE
v_user_id NUMBER;
BEGIN
-- Look up USER_ID from account usage
SELECT USER_ID INTO :v_user_id
FROM SNOWFLAKE.ACCOUNT_USAGE.USERS
WHERE NAME = :P_USER_NAME
LIMIT 1;
-- Grant the AI Functions role to the user
EXECUTE IMMEDIATE 'GRANT ROLE AI_FUNCTIONS_USER_ROLE TO USER ' || P_USER_NAME;
-- Register or update the user in the access control table
MERGE INTO AI_FUNCTIONS_ACCESS_CONTROL tgt
USING (SELECT :P_USER_NAME AS USER_NAME) src
ON tgt.USER_NAME = src.USER_NAME
WHEN MATCHED THEN
UPDATE SET
USER_ID = :v_user_id,
IS_ACTIVE = TRUE,
MONTHLY_CREDIT_LIMIT = :P_MONTHLY_LIMIT,
GRANTED_AT = CURRENT_TIMESTAMP(),
REVOKED_AT = NULL,
REVOCATION_REASON = NULL
WHEN NOT MATCHED THEN
INSERT (USER_NAME, USER_ID, MONTHLY_CREDIT_LIMIT, IS_ACTIVE)
VALUES (:P_USER_NAME, :v_user_id, :P_MONTHLY_LIMIT, TRUE);
RETURN 'Access granted to ' || P_USER_NAME || ' with monthly limit of ' || P_MONTHLY_LIMIT || ' credits';
END;
$$;
Utilisez cette procédure stockée pour ajouter des utilisateurs et leurs quotas de crédit à la table de contrôle d’accès.
CALL GRANT_AI_FUNCTIONS_ACCESS('ALICE', 1000); -- grants access to user ALICE with a monthly limit of 100 credits
CALL GRANT_AI_FUNCTIONS_ACCESS('BOB', 2000); -- grants access to user BOB with a monthly limit of 200 credits
Créez ensuite la tâche d’actualisation mensuelle de l’accès. Cette tâche s’exécute le premier jour de chaque mois pour restaurer l’accès aux fonctions AI pour tous les utilisateurs autorisés. Lorsque l’accès d’un utilisateur a été révoqué pour cause de dépassement de sa limite au cours du mois précédent, cette tâche lui accorde un nouveau budget pour le nouveau mois.
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
Enfin, créez une tâche horaire pour surveiller les dépenses des utilisateurs et révoquer l’accès de tout utilisateur qui dépasse sa limite mensuelle.
-- Create a procedure to re-grant access to all entitled users
CREATE OR REPLACE PROCEDURE GRANT_ALL_ENTITLED_USERS()
RETURNS TABLE (USER_NAME VARCHAR, CREDIT_LIMIT NUMBER, ACTION VARCHAR)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
result := (
SELECT
USER_NAME,
MONTHLY_CREDIT_LIMIT AS CREDIT_LIMIT,
'GRANTED' AS ACTION
FROM AI_FUNCTIONS_ACCESS_CONTROL
);
-- Re-grant access for each entitled user
FOR rec IN result DO
CALL GRANT_AI_FUNCTIONS_ACCESS(rec.USER_NAME, rec.CREDIT_LIMIT);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to run on the 1st of each month at midnight UTC
CREATE OR REPLACE TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 0 1 * * UTC' -- 1st day of each month at 00:00 UTC
AS
CALL GRANT_ALL_ENTITLED_USERS();
-- Enable the task
ALTER TASK MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH RESUME;
-- Run once initially to populate grantees
CALL GRANT_ALL_ENTITLED_USERS();
-- Verify task status
SHOW TASKS LIKE 'MONTHLY_AI_FUNCTIONS_ACCESS_REFRESH';
Détection et annulation des requêtes incontrôlées¶
Les requêtes de fonctions AI qui s’exécutent sur une longue durée peuvent entraîner des coûts importants. Cet exemple met en œuvre un système automatisé pour détecter les requêtes qui dépassent un seuil de crédit et les annuler avant qu’elles ne consomment encore plus de ressources. Une alerte par e-mail est envoyée avec tous les détails de la requête.
Note
Lorsqu’une requête est annulée, le client est toujours facturé pour toutes les ressources consommées jusqu’au moment de l’annulation. L’annulation d’une requête incontrôlée empêche l’accumulation supplémentaire de coûts, mais ne remplace pas les crédits déjà dépensés.
Cette procédure trouve les requêtes de fonctions AI des 48 dernières heures qui ont dépassé le seuil de crédit et qui sont toujours en cours d’exécution, les annule et les signalent à un administrateur.
-- Create a procedure to detect and cancel expensive runaway queries
CREATE OR REPLACE PROCEDURE MONITOR_AND_CANCEL_RUNAWAY_QUERIES(
P_CREDIT_THRESHOLD NUMBER DEFAULT 50 -- adjust the limit accordingly
)
RETURNS TABLE (
QUERY_ID VARCHAR,
USER_NAME VARCHAR,
FUNCTION_NAME VARCHAR,
MODEL_NAME VARCHAR,
CREDITS NUMBER,
START_TIME TIMESTAMP_LTZ,
ACTION VARCHAR
)
LANGUAGE SQL
AS
$$
DECLARE
result RESULTSET;
BEGIN
-- Find queries from the last 48 hours that exceed the threshold and are still running
result := (
SELECT
h.QUERY_ID,
u.NAME AS USER_NAME,
h.FUNCTION_NAME,
h.MODEL_NAME,
h.CREDITS,
h.START_TIME,
h.ROLE_NAMES,
h.QUERY_TAG,
h.WAREHOUSE_ID,
'CANCELLED' AS ACTION
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.USERS u
ON h.USER_ID = u.USER_ID
WHERE h.START_TIME >= DATEADD('hour', -48, CURRENT_TIMESTAMP())
AND h.CREDITS > :P_CREDIT_THRESHOLD
AND h.IS_COMPLETED = FALSE
);
-- Cancel each runaway query and send alert
FOR rec IN result DO
-- Attempt to cancel the query
BEGIN
EXECUTE IMMEDIATE 'SELECT SYSTEM$CANCEL_QUERY(''' || rec.QUERY_ID || ''')';
EXCEPTION
WHEN OTHER THEN
NULL; -- Query may have already completed
END;
-- Send alert with query details
CALL SYSTEM$SEND_EMAIL(
'ai_cost_alerts',
'admin@company.com',
'Runaway AI Query Cancelled - ' || rec.QUERY_ID,
'A runaway AI Function query has been cancelled due to excessive cost.\n\n' ||
'Query Details:\n' ||
'- Query ID: ' || rec.QUERY_ID || '\n' ||
'- User: ' || COALESCE(rec.USER_NAME, 'Unknown') || '\n' ||
'- Function: ' || rec.FUNCTION_NAME || '\n' ||
'- Model: ' || rec.MODEL_NAME || '\n' ||
'- Credits Used: ' || rec.CREDITS::VARCHAR || '\n' ||
'- Threshold: ' || :P_CREDIT_THRESHOLD::VARCHAR || '\n' ||
'- Start Time: ' || rec.START_TIME::VARCHAR || '\n' ||
'- Roles: ' || COALESCE(rec.ROLE_NAMES::VARCHAR, 'N/A') || '\n' ||
'- Query Tag: ' || COALESCE(rec.QUERY_TAG, 'N/A') || '\n' ||
'- Warehouse ID: ' || COALESCE(rec.WAREHOUSE_ID::VARCHAR, 'N/A') || '\n\n' ||
'Please investigate this query and take appropriate action.'
);
END FOR;
RETURN TABLE(result);
END;
$$;
-- Create a task to monitor and cancel runaway queries every hour
CREATE OR REPLACE TASK MONITOR_RUNAWAY_AI_QUERIES
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' -- Every hour
AS
CALL MONITOR_AND_CANCEL_RUNAWAY_QUERIES(50); -- adjust the limit accordingly
-- Enable the task
ALTER TASK MONITOR_RUNAWAY_AI_QUERIES RESUME;
-- Verify task status
SHOW TASKS LIKE 'MONITOR_RUNAWAY_AI_QUERIES';
-- Check task execution history
SELECT *
FROM TABLE(INFORMATION_SCHEMA.TASK_HISTORY(
SCHEDULED_TIME_RANGE_START => DATEADD('day', -1, CURRENT_TIMESTAMP()),
TASK_NAME => 'MONITOR_RUNAWAY_AI_QUERIES'
))
ORDER BY SCHEDULED_TIME DESC;
Astuce
Vous savez peut-être déjà que certaines de vos requêtes peuvent prendre beaucoup de temps à s’exécuter. Vous pouvez définir un rôle spécial pour ces requêtes et exclure ce rôle de la logique d’annulation dans la procédure. Par exemple, pour créer le rôle :
CREATE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_ROLE TO ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
GRANT ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE TO USER LONG_RUNNING_USER;
Ajouter la condition suivante à la clause WHERE de la procédure pour exclure de l’annulation les requêtes exécutées par les utilisateurs disposant de ce rôle.
,, code-block:: sqlexample
AND NOT ARRAY_CONTAINS(h.ROLE_NAMES, “AI_FUNCTIONS_USER_LONG_RUNNING_ROLE”)
L’utilisateur peut désormais assumer le rôle pour exécuter une requête de longue durée sans qu’elle soit annulée :
USE ROLE AI_FUNCTIONS_USER_LONG_RUNNING_ROLE;
-- then start the long-running query
Meilleures pratiques¶
Gardez les meilleures pratiques suivantes à l’esprit lorsque vous développez une stratégie de gestion des coûts pour l’utilisation des fonctions AI :
Commencer par la surveillance : avant de mettre en œuvre des contrôles automatisés, établissez des modèles d’utilisation de base à l’aide des requêtes dans Surveillance de base de l’utilisation.
Définir des limites initiales prudentes : commencez par des seuils inférieurs et ajustez à la hausse en fonction des modèles d’utilisation réels.
Utiliser les balises de requête : invitez les équipes à utiliser les paramètres de session QUERY_TAG pour permettre l’attribution des coûts par projet ou équipe.
Examiner la table régulièrement : examinez régulièrement la table de contrôle d’accès et ajustez les limites par utilisateur en fonction des besoins légitimes.
Tester les alertes : vérifiez que les notifications par e-mail fonctionnent correctement avant de vous y fier pour les alertes critiques.
Prendre en compte la latence : la vue ACCOUNT_USAGE a jusqu’à 60 minutes de latence ; tenez compte de cela dans votre stratégie de surveillance.