Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Règles de surveillance de requête WLM
Dans la gestion des charges de travail (WLM) d’Amazon Redshift, les règles de surveillance des requêtes définissent des limites de performance basées sur des mesures pour les files d’attente WLM et spécifient les mesures à prendre lorsqu’une requête dépasse ces limites. Par exemple, pour une file d’attente dédiée aux requêtes de courte durée, vous pouvez créer une règle qui annule les requêtes qui s’exécutent pendant plus de 60 secondes. Si vous souhaitez effectuer un suivi des requêtes mal conçues, vous pouvez configurer une autre règle qui consigne les requêtes contenant des boucles imbriquées.
Vous définissez les règles de surveillance de requête dans le cadre de la configuration de la gestion de la charge de travail (WLM). Vous pouvez définir jusqu’à 25 règles par file d’attente, et jusqu’à 25 règles au total pour toutes les files d’attente. Chaque règle est composée au maximum de trois conditions (prédicats) et d’une action. Un *prédicat* est composé d’une métrique, d’une condition de comparaison (=, < ou > ) et d’une valeur. Si les conditions de l’ensemble des prédicats d’une règle sont respectées, l’action associée à cette règle est déclenchée. Les règles peuvent être associées aux actions log, hop et abort, comme discuté ci-après.
Les règles dans une file d’attente donnée s’appliquent uniquement aux requêtes en cours d’exécution dans cette file d’attente. Une règle est indépendante des autres règles.
WLM évalue les métriques toutes les 10 secondes. Amazon Redshift applique des règles de surveillance des requêtes au niveau de la requête enfant lorsque les requêtes sont automatiquement réécrites. Si plusieurs règles sont déclenchées sur la même période, WLM choisit celle dont l’action est la plus grave. Si l’action pour deux règles a la même sévérité, WLM exécute les règles par ordre alphabétique, en fonction du nom de la règle. Si l’action est hop ou abort, elle est consignée et la requête est expulsée de la file d’attente. Si l’action est log, la requête continue à s’exécuter dans la file d’attente. WLM déclenche une seule action log par requête et par règle. Si la file d’attente contient d’autres règles, celles-ci restent en vigueur. Si l’action est hop et que la requête est acheminée vers une autre file d’attente, les règles relatives à la nouvelle file d’attente s’appliquent. Pour plus d’informations sur la surveillance des requêtes et le suivi des actions entreprises sur des requêtes spécifiques, consultez la collection d’exemples sur [Accélération des requêtes courtes](wlm-short-query-acceleration.md).
Lorsque l’ensemble des prédicats d’une règle sont respectés, WLM écrit une ligne dans la table système [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md). En outre, Amazon Redshift enregistre les métriques des requêtes en cours d’exécution dans [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md). Les métriques des requêtes terminées sont stockées dans [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md).
**Note**
Pour Amazon Redshift Serverless, vous pouvez configurer les files d'attente de requêtes et les règles de surveillance à l'aide du paramètre. `wlm_json_configuration` Cela vous permet de créer plusieurs files d'attente avec différents rôles d'utilisateur, groupes de requêtes et règles de surveillance. Pour plus d'informations sur la configuration des files d'attente de requêtes sans serveur, consultez la section [Configuration des files d'attente de requêtes](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html) dans le guide de gestion *Amazon* Redshift.
## Définition d’une règle de surveillance de requête
Vous créez des règles de surveillance de requête dans le cadre de la configuration WLM, que vous définissez lors de la définition du groupe de paramètres de votre cluster.
Vous pouvez créer des règles à l'aide du AWS Management Console JSON ou par programmation.
**Note**
Si vous créez des règles par programmation, il est recommandé d’utiliser la console afin de générer les données JSON à inclure dans la définition du groupe de paramètres. Pour plus d’informations, consultez [Création d’une règle de surveillance de requête](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) et [Configuration des valeurs des paramètres à l’aide de la AWS CLI](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli) dans le *Guide de gestion Amazon Redshift*.
Pour définir une règle de surveillance de requête, spécifiez les éléments suivants :
+ Un nom de règle – Les noms des règles doivent être uniques au sein de la configuration WLM. Les noms de règles peut comporter jusqu’à 32 caractères alphanumériques ou traits de soulignement et ne doivent pas contenir d’espaces ni de guillemets. Vous pouvez disposer de jusqu’à 25 règles par file d’attente et la limite totale pour toutes les files d’attente est de 25 règles.
+ Un ou plusieurs prédicats – Chaque règle peut comporter jusqu’à trois prédicats. Si l’ensemble des prédicats d’une règle sont respectés, l’action associée est déclenchée. Un prédicat se définit par un nom de métrique, un opérateur (=, < ou >) et une valeur. Par exemple : `query_cpu_time > 100000`. Pour obtenir une liste des métriques, ainsi que des exemples de valeurs pour différentes métriques, voir [Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné](#cm-c-wlm-query-monitoring-metrics) plus loin dans cette section.
+ Une action – Si plusieurs règles sont déclenchées, WLM choisit celle dont l’action est la plus grave. Les actions possibles sont les suivantes, par ordre croissant de gravité :
+ Log – Cette action enregistre des informations sur la requête dans la table système STL\$1WLM\$1RULE\$1ACTION. Utilisez cette action si vous souhaitez uniquement écrire un enregistrement de journal. WLM crée au maximum un journal par requête et par règle. Suite à une action log, les autres règles restent en vigueur et WLM continue à surveiller la requête.
+ Hop (uniquement disponible avec la gestion manuelle de la charge de travail) – Consigne l’action et fait sauter la requête vers la file d’attente correspondante suivante. S’il n’existe aucune autre file d’attente correspondante, la requête est annulée. QMR replace uniquement les instructions [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) (CTAS) et les requêtes en lecture seule, telles que les instructions SELECT. Pour plus d’informations, consultez [Saut de file d’attente des requêtes WLM](wlm-queue-hopping.md).
+ Abort – Journalise l’action et annule la requête. QMR n’arrête pas les instructions COPY et les opérations de maintenance, comme ALTER, ANALYZE et VACUUM.
+ Change priority (Modifier la priorité) (uniquement disponible avec la gestion automatique de la charge de travail) – Pour modifier la priorité d’une requête.
Pour limiter la durée d’exécution des requêtes, nous vous recommandons de créer une règle de surveillance de requête au lieu d’utiliser le délai WLM. Par exemple, vous pouvez définir `max_execution_time` sur 50 000 millisecondes, comme illustré dans cet extrait JSON.
```
"max_execution_time": 50000
```
Mais nous vous recommandons plutôt de définir une règle de surveillance des requêtes équivalente. L’exemple suivant illustre une règle de surveillance des requêtes qui définit `query_execution_time` à 50 secondes :
```
"rules":
[
{
"rule_name": "rule_query_execution",
"predicate": [
{
"metric_name": "query_execution_time",
"operator": ">",
"value": 50
}
],
"action": "abort"
}
]
```
Pour les étapes de création ou de modification d’une règle de surveillance des requêtes, consultez [Création d’une règle de surveillance des requêtes](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) et [Propriétés du paramètre wlm\$1json\$1configuration](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties) dans le *Guide de gestion Amazon Redshift*.
Vous trouverez plus d’informations sur les règles de surveillance de requête dans les rubriques suivantes :
+ [Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné](#cm-c-wlm-query-monitoring-metrics)
+ [Modèles de règles de surveillance de requête](#cm-c-wlm-query-monitoring-templates)
+ [Création d’une règle de surveillance de requête](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)
+ [Configuration de la gestion de la charge de travail](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)
+ [Tables et vues système pour les règles de surveillance de requête](#cm-c-wlm-qmr-tables-and-views)
## Métriques de surveillance des requêtes pour cluster Amazon Redshift provisionné
Le tableau suivant décrit les métriques utilisées dans les règles de surveillance de requête. (Ces métriques diffèrent des métriques stockées dans les tables système [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) et [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md).)
Pour une métrique donnée, le seuil de performance fait l’objet d’un suivi au niveau de la requête ou du segment. Pour plus d’informations sur les segments et les étapes, consultez[Workflow d’exécution et de planification de requête](c-query-planning.md).
**Note**
Le paramètre [Délai WLM](cm-c-defining-query-queues.md#wlm-timeout) diffère des règles de surveillance de requête.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**Note**
L’action de saut n’est pas prise en charge avec le prédicat `query_queue_time`. Autrement dit, les règles définies pour le saut lorsqu’un prédicat `query_queue_time` est atteint sont ignorées.
La courte durée d’exécution de segment peut entraîner des erreurs d’échantillonnage avec certaines métriques, notamment `io_skew` et `query_cpu_usage_percent`. Pour éviter ou réduire les risques d’erreurs d’échantillonnage, incluez une durée d’exécution de segment à vos règles. `segment_execution_time > 10` vous donne un bon point de départ.
La vue [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) affiche les métriques des requêtes terminées. La vue [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) affiche les valeurs maximales des métriques des requêtes terminées. Utilisez les valeurs de ces vues afin de vous aider à déterminer les seuils permettant de définir les règles de surveillance des requêtes.
## Métriques de surveillance des requêtes pour Amazon Redshift sans serveur
La table suivante décrit les métriques utilisées dans les règles de surveillance de requête pour Amazon Redshift sans serveur.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
**Note**
L’action de saut n’est pas prise en charge avec le prédicat `max_query_queue_time`. Autrement dit, les règles définies pour le saut lorsqu’un prédicat `max_query_queue_time` est atteint sont ignorées.
La courte durée d’exécution de segment peut entraîner des erreurs d’échantillonnage avec certaines métriques, notamment `max_io_skew` et `max_query_cpu_usage_percent`.
Pour Amazon Redshift Serverless, vous pouvez configurer les files d'attente de requêtes et les règles de surveillance à l'aide du paramètre. `wlm_json_configuration` Cela vous permet de créer plusieurs files d'attente avec différents rôles d'utilisateur, groupes de requêtes et règles de surveillance à l'aide des métriques répertoriées ci-dessus. Pour plus d'informations sur la configuration des files d'attente de requêtes sans serveur, consultez la [structure de configuration WLM JSON](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration) dans le guide de gestion *Amazon* Redshift.
## Modèles de règles de surveillance de requête
Lorsque vous ajoutez une règle à l’aide de la console Amazon Redshift, vous pouvez choisir de créer une règle à partir d’un modèle prédéfini. Amazon Redshift crée une règle avec un ensemble de prédicats auxquels sont attribuées les valeurs par défaut. L’action par défaut est log. Vous pouvez modifier les prédicats et l’action en fonction de votre cas d’utilisation.
Le tableau suivant répertorie les modèles disponibles.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html)
## Tables et vues système pour les règles de surveillance de requête
Lorsque l’ensemble des prédicats d’une règle sont respectés, WLM écrit une ligne dans la table système [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md). Cette ligne contient les informations relatives à la requête qui a déclenché la règle et l’action qui en résulte.
En outre, Amazon Redshift enregistre les métriques des requêtes dans les tables système et les vues suivantes.
+ Le tableau [STV\$1QUERY\$1METRICS](r_STV_QUERY_METRICS.md) affiche les métriques des requêtes en cours d’exécution.
+ Le tableau [STL\$1QUERY\$1METRICS](r_STL_QUERY_METRICS.md) enregistre les métriques des requêtes terminées.
+ La vue [SVL\$1QUERY\$1METRICS](r_SVL_QUERY_METRICS.md) affiche les métriques des requêtes terminées.
+ La vue [SVL\$1QUERY\$1METRICS\$1SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) affiche les valeurs maximales des métriques des requêtes terminées.