Surveillance des tâches de transformation de données - Simple Log Service

Données de métriques

Pour collecter les métriques d'exécution des tâches Data Transformation (New Version), activez SLS Job Operational Logs. Pour plus d'informations, consultez Gérer les journaux de service.

Tableau de bord

Simple Log Service crée automatiquement un tableau de bord sur la page de détails de chaque tâche de transformation de données, affichant ses métriques opérationnelles.

Procédure

Connectez-vous à la console Simple Log Service.
Dans la section Projects, cliquez sur le projet souhaité.
Dans le volet de navigation de gauche, choisissez Job Management > Data Transformation.
Cliquez sur la tâche de transformation de données cible et consultez le tableau de bord dans la section Execution Status.

Métriques globales

Le tableau de bord inclut les métriques clés suivantes :

Processing Rate : événements traités par seconde, calculés par défaut sur une fenêtre d'une minute au cours d'une période d'une heure.
- ingest : nombre d'événements lus depuis tous les shards du logstore source.
- deliver : nombre d'événements écrits avec succès dans le logstore de destination.
- failed : nombre d'événements lus depuis le logstore source ayant échoué lors de la transformation.
Total Events Read : nombre total d'événements lus depuis tous les shards du logstore source. La période statistique par défaut est d'un jour.
Total Events Delivered : nombre total d'événements écrits avec succès dans tous les logstores de destination. La période statistique par défaut est d'un jour.
Total Events Failed : nombre total d'événements lus depuis le logstore source ayant échoué lors de la transformation. La période statistique par défaut est d'un jour.
Event Delivery Ratio : rapport entre les événements livrés avec succès au logstore de destination et le total des événements lus depuis le logstore source. La période statistique par défaut est d'un jour.

Détails des shards

Les métriques au niveau des shards sont collectées à intervalles d'une minute lorsque la tâche lit les données depuis le Logstore source.

Shard Consumption Latency (s) : différence de temps (en secondes) entre l'heure d'ingestion de l'événement le plus récent et l'heure d'ingestion de l'événement actuellement traité, indiquant le délai de traitement par shard.
Active Shard Statistics : la période statistique par défaut est d'une heure.
- shard : ID du shard.
- ingest : nombre d'événements bruts lus depuis le shard.
- failed : nombre d'événements bruts lus depuis le shard ayant échoué lors de la transformation.

Exceptions d'exécution

Les détails des erreurs sont disponibles dans le champ message.

Par exemple, le tableau des journaux sur la page des détails des erreurs contient quatre colonnes : time, level, action et message. Lorsque le level est ERROR et que l'action est deliver, le champ message peut afficher une erreur telle que {"Code":"InvalidArgs","Message":"failed to get sts token: ...The role not exists: acs:ram::*:role/test-role."}. Ce message indique que le système n'a pas pu obtenir de jeton STS car le rôle RAM spécifié n'existe pas.

Règles d'alerte

Créez des règles d'alerte basées sur Données de métriques pour surveiller la latence de traitement, les exceptions et les variations de trafic. Pour les concepts généraux relatifs aux alertes, consultez Alertes. Pour des instructions étape par étape, consultez Créer une règle d'alerte basée sur les journaux.

Important

Lors de la création d'une règle d'alerte pour une tâche de transformation de données, assurez-vous que la requête cible le même projet et le même logstore où les journaux opérationnels de la tâche sont stockés. Pour plus d'informations, consultez Gérer les journaux de service.

Dans la boîte de dialogue Query and Analyze, cliquez sur l'onglet Advanced Settings. Définissez Type sur Logstore et Authorization Method sur Default. Sélectionnez la Region cible et saisissez les noms du project et du logstore. Si nécessaire, configurez dedicated SQL (vous pouvez sélectionner Auto, Enable ou Disable) ainsi que la time range. Ensuite, cliquez sur Confirm.

Surveillance de la latence de traitement

Élément	Description
Objectif	Surveille la latence de consommation des shards dans une tâche de transformation de données. Une alerte est déclenchée si la latence de traitement dépasse le seuil spécifié.
Voir Shard Consumption Latency (s).	Métrique associée du tableau de bord
Exemple de requête d'analyse	Remplacez `{job_name}` dans la requête suivante par le nom de votre tâche de transformation de données. `__topic__: etl_metrics and job_name: {job_name} and "_etl_:connector_meta.action": ingest \| select split_part( "_etl_:connector_meta.task_name", '#', 2 ) as shard, max_by("_etl_:connector_metrics.lags", __time__) as lags group by shard having shard is not null limit all`
Paramètres de la règle d'alerte	Définissez Trigger Condition sur Data Matches Expression. Définissez l'expression d'évaluation sur `lags > 120`. Cela définit le seuil de latence à 120 secondes. Définissez la time range sur 5 minutes. Définissez la Check Frequency sur 5 minutes. Remarque Pour éviter les fausses alarmes causées par les mises à jour périodiques des métriques (toutes les minutes) ou par la latence due à des pics soudains de données, nous recommandons d'utiliser ces paramètres.
Résolution des alertes	Pour résoudre ces alertes : Si la tâche a été créée récemment et traite des données historiques, le traitement du retard accumulé peut prendre du temps. Surveillez la latence pendant une heure. Si elle ne descend pas en dessous du seuil d'alerte, passez à l'étape suivante. Si le volume de données dans le logstore source augmente considérablement : Si le Processing Rate (events/s) augmente tandis que la Shard Consumption Latency (s) diminue, cela indique que la tâche de transformation de données met automatiquement à l'échelle ses ressources en raison d'une augmentation des données dans le Logstore source. Surveillez la latence pendant 5 minutes pour voir si elle revient à une plage normale. Sinon, passez à l'étape suivante. Si le Processing rate (events/s) n'augmente pas ou si la Shard consumption latency (s) continue d'augmenter, le nombre de shards dans le Logstore source peut être insuffisant, ce qui limite la mise à l'échelle des ressources de transformation de données. Vous devez fractionner manuellement les shards du Logstore source. Pour les étapes spécifiques, consultez Gérer les shards. Une fois le fractionnement terminé, observez pendant 5 minutes pour vérifier si la latence rentre dans la plage d'alerte. Sinon, passez à l'étape suivante. Si vous avez une alerte active pour des exceptions de traitement, résolvez d'abord cette alerte. Après avoir résolu le problème, observez pendant 5 minutes pour voir si la latence descend en dessous du seuil d'alerte.

Surveillance des exceptions de traitement

Élément	Description
Objectif	Déclenche une alerte lorsqu'une exception se produit lors d'une tâche de transformation de données.
Métrique associée du tableau de bord	Voir Exceptions d'exécution.
Exemple de requête d'analyse	Remplacez `{job_name}` dans la requête suivante par le nom de votre tâche de transformation de données. `__topic__: etl_metrics and job_name: {job_name} and "_etl_:connector_metrics.error": * \| select distinct "_etl_:connector_metrics.error" as errors`
Paramètres de la règle d'alerte	Définissez Trigger Condition sur Data Is Returned. Définissez la time range sur 10 minutes. Définissez la Check Frequency sur 10 minutes.
Résolution des alertes	Effectuez le dépannage en fonction du message d'erreur : Si le message d'erreur contient `Invalid SPL query`, la requête SPL de la tâche contient une erreur de syntaxe. Corrigez la requête en vous basant sur les détails du message d'erreur. Pour plus d'informations, consultez Syntaxe SPL. Si le message d'erreur contient `Unauthorized`, `InvalidAccessKeyId` ou `SignatureNotMatch`, la tâche ne dispose pas des autorisations requises pour lire les données depuis le logstore source ou écrire des données dans le logstore de destination. Pour plus d'informations, consultez Autorisation. Si le message d'erreur contient `ProjectNotExist` ou `LogStoreNotExist`, le projet ou le logstore spécifié n'existe pas. Connectez-vous à la console Simple Log Service pour vérifier et résoudre le problème.

Surveillance du ratio de volume de données écrites (période sur période)

Élément	Description
Objectif	Déclenche une alerte basée sur les variations période sur période du ratio de livraison des données (volume écrit par rapport au volume lu). La règle compare le ratio actuel à celui de la même période de la veille et de la semaine précédente, et déclenche une alerte si la variation dépasse les seuils de croissance ou de baisse que vous avez configurés.
Métrique associée du tableau de bord	Event Delivery Ratio : rapport entre les événements livrés avec succès au logstore de destination et le total des événements lus depuis le logstore source. La période statistique par défaut est d'un jour.
Exemple de requête d'analyse	Saisissez la requête suivante dans la boîte de dialogue Query and Analyze lors de la création de la règle d'alerte. Remplacez `{job_name}` dans la requête suivante par le nom de votre tâche de transformation de données. __topic__: etl_metrics and job_name: {job_name} \| select round(diff [1], 1) as percent, round(coalesce(diff [4], 0), 1) as ratio_1d, round(coalesce(diff [5], 0), 1) as ratio_1w from( select compare(percent, 86400, 604800) as diff FROM ( select deliver /(ingest + 0,0001) as percent from( select sum( if( "_etl_:connector_meta.action" = 'ingest', "_etl_:connector_metrics.native_bytes", 0 ) ) as ingest, sum( if( "_etl_:connector_meta.action" = 'deliver', "_etl_:connector_metrics.native_bytes", 0 ) ) as deliver FROM log ) ) )
Paramètres de la règle d'alerte	Définissez Trigger Condition sur Data Matches Expression. Définissez l'expression d'évaluation sur `(ratio_1d > 1,2 \|\| ratio_1d < 0,8) && (ratio_1w > 1,2 \|\| ratio_1w < 0,8)`. Cela définit le seuil de croissance et de baisse quotidien/hebdomadaire à 20 %. Définissez la time range sur 1 heure. Définissez la Check Frequency sur 1 heure. Remarque Pour éviter les fausses alarmes dues aux fluctuations périodiques du trafic de données brutes, nous recommandons de définir les seuils de croissance et de baisse quotidiens/hebdomadaires à au moins 20 %, ou d'ajuster la période de comparaison pour qu'elle corresponde au cycle de votre trafic de données brutes.
Résolution des alertes	Pour résoudre ces alertes : Si le volume de données dans le logstore source a changé, vérifiez s'il existe de nouveaux modèles de données ingérés ou des interruptions dans les flux de données existants. Si c'est le cas et que la variation de données résultante correspond à la métrique, l'alerte est causée par le changement du modèle de données source. Sinon, passez à l'étape suivante. Si vous avez des alertes actives pour la latence de traitement ou les exceptions, résolvez-les d'abord.

Surveillance du nombre d'événements source (période sur période)

Élément	Description
Objectif	Déclenche une alerte si le nombre d'événements lus par la tâche de transformation de données change considérablement par rapport à la veille et à la semaine précédente. La règle se déclenche si le nombre d'événements dépasse un seuil de croissance ou tombe en dessous d'un seuil de baisse.
Métrique associée du tableau de bord	Total Events Read : nombre total d'événements lus depuis tous les shards du logstore source. La période statistique par défaut est d'un jour.
Exemple de requête d'analyse	Saisissez la requête suivante dans la boîte de dialogue Query and Analyze lors de la création de la règle d'alerte. Remplacez `{job_name}` dans la requête suivante par le nom de votre tâche de transformation de données. `__topic__: etl_metrics and job_name: {job_name} and "_etl_:connector_meta.action": ingest \| select diff [1] as events, round(coalesce(diff [4], 0), 1) as ratio_1d, round(coalesce(diff [5], 0), 1) as ratio_1w from( select compare(events, 86400, 604800) as diff FROM ( select sum("_etl_:connector_metrics.events") as events FROM log ) )`
Paramètres de la règle d'alerte	Définissez Trigger Condition sur Data Matches Expression. Définissez l'expression d'évaluation sur `(ratio_1d > 1,2 \|\| ratio_1d < 0,8) && (ratio_1w > 1,2 \|\| ratio_1w < 0,8)`. Cela définit le seuil de croissance et de baisse quotidien/hebdomadaire à 20 %. Définissez la time range sur 1 heure. Définissez la Check Frequency sur 1 heure. Remarque Pour éviter les fausses alarmes dues aux fluctuations périodiques du trafic de données brutes, nous recommandons de définir les seuils de croissance et de baisse quotidiens/hebdomadaires à au moins 20 %, ou d'ajuster la période de comparaison pour qu'elle corresponde au cycle de votre trafic de données brutes.
Résolution des alertes	Pour résoudre ces alertes : Si la tendance de cette métrique correspond à la croissance ou à la baisse du nombre d'événements du logstore source, la variation est causée par le volume de données source. Sinon, passez à l'étape suivante. Si vous avez des alertes actives pour la latence de traitement ou les exceptions, résolvez-les d'abord.

Surveillance du nombre d'événements livrés (période sur période)

Élément	Description
Objectif	Déclenche une alerte si le nombre d'événements écrits par la tâche de transformation de données change considérablement par rapport à la veille et à la semaine précédente. La règle se déclenche si le nombre d'événements dépasse un seuil de croissance ou tombe en dessous d'un seuil de baisse.
Métrique associée du tableau de bord	Total Events Delivered
Exemple de requête d'analyse	Saisissez la requête suivante dans la boîte de dialogue Query and Analyze lors de la création de la règle d'alerte. Remplacez `{job_name}` dans la requête suivante par le nom de votre tâche de transformation de données. `__topic__: etl_metrics and job_name: {job_name} and "_etl_:connector_meta.action": deliver \| select diff [1] as events, round(coalesce(diff [4], 0), 1) as ratio_1d, round(coalesce(diff [5], 0), 1) as ratio_1w from( select compare(events, 86400, 604800) as diff FROM ( select sum("_etl_:connector_metrics.events") as events FROM log ) )`
Paramètres de la règle d'alerte	Définissez Trigger Condition sur Data Matches Expression. Définissez l'expression d'évaluation sur `(ratio_1d > 1,2 \|\| ratio_1d < 0,8) && (ratio_1w > 1,2 \|\| ratio_1w < 0,8)`. Cela définit le seuil de croissance et de baisse quotidien/hebdomadaire à 20 %. Définissez la time range sur 1 heure. Définissez la Check Frequency sur 1 heure. Remarque Pour éviter les fausses alarmes dues aux fluctuations périodiques du trafic de données brutes, nous recommandons de définir les seuils de croissance et de baisse quotidiens/hebdomadaires à au moins 20 %, ou d'ajuster la période de comparaison pour qu'elle corresponde au cycle de votre trafic de données brutes.
Résolution des alertes	Pour résoudre ces alertes : Si la tendance de cette métrique correspond à la croissance ou à la baisse du volume de données du logstore source, la variation est causée par le volume de données source. Sinon, passez à l'étape suivante. Si vous avez des alertes actives pour la latence de traitement ou les exceptions, résolvez-les d'abord.