Comment utiliser les vues STL de Redshift pour la journalisation et la surveillance

Introduction
Si vous travaillez avec Amazon Redshift, il est important de surveiller l’exécution des requêtes et l’activité système. Cela vous aidera à améliorer les performances, à résoudre les problèmes et à assurer le bon déroulement des opérations. Cela vous aidera à optimiser les performances, à résoudre les problèmes et à garantir le bon fonctionnement des opérations. Heureusement, Redshift fournit un ensemble puissant de tables système et de vues (STL) qui vous permettent d’accéder à des informations détaillées sur les requêtes, les connexions et diverses métriques système.
Dans cet article, nous aborderons les bases des vues STL de Redshift, en nous concentrant sur stl_query, stl_connection_log et d’autres vues essentielles pour la journalisation et la surveillance.
Qu’est-ce que les vues STL de Redshift ?
Les tables système et vues de Redshift (STL) constituent un ensemble de vues intégrées qui stockent des informations sur le fonctionnement interne du cluster Redshift. Ces vues fournissent des informations précieuses sur l’exécution des requêtes, les performances du système, l’utilisation des ressources et bien plus encore. En interrogeant les vues STL, vous pouvez obtenir une compréhension approfondie du déroulement de vos requêtes, identifier les goulots d’étranglement et prendre des décisions éclairées pour optimiser vos charges de travail sur Redshift. Redshift génère les vues système STL à partir des fichiers journaux.
Exploration de la vue stl_query
L’une des vues STL les plus fréquemment utilisées est stl_query. Cette vue contient un enregistrement de chaque requête exécutée sur le cluster Redshift, accompagné d’informations détaillées sur chaque requête. Examinons de plus près comment utiliser stl_query pour la journalisation et l’analyse.
Interroger stl_query
Pour accéder aux informations stockées dans stl_query, vous pouvez exécuter une simple instruction SELECT. Voici un exemple :
SELECT query, starttime, endtime, elapsed, aborted FROM stl_query ORDER BY starttime DESC LIMIT 10;
Cette requête récupère les 10 dernières requêtes exécutées sur le cluster Redshift, ainsi que leur heure de début, heure de fin, durée et si elles ont été annulées. Le résultat vous donnera un aperçu rapide de l’activité récente des requêtes.
Analyse des performances des requêtes
En approfondissant l’analyse de la vue stl_query, vous pouvez obtenir des informations précieuses sur les performances des requêtes. Par exemple, vous pouvez identifier les requêtes longues en filtrant sur la colonne elapsed :
SELECT query, elapsed, substring(querytxt, 1, 50) as query_snippet FROM stl_query WHERE elapsed > 60000 -- Durée de la requête en millisecondes ORDER BY elapsed DESC;
Cette requête récupère les requêtes qui ont pris plus de 60 secondes à s’exécuter, ainsi qu’un extrait du texte de la requête. En analysant ces requêtes lentes, vous pouvez identifier les goulots d’étranglement en matière de performance et optimiser vos instructions SQL en conséquence.
Surveillance des connexions avec la vue stl_connection_log
Une autre vue STL importante pour la journalisation est stl_connection_log. Cette vue enregistre des informations sur les connexions des clients au cluster Redshift, y compris les heures de début et de fin de connexion, les noms d’utilisateur et les adresses IP des clients. Explorons comment utiliser stl_connection_log pour surveiller les connexions.
Interroger stl_connection_log
Pour visualiser le journal des connexions, vous pouvez exécuter une simple requête SELECT sur stl_connection_log :
SELECT username, starttime, endtime, duration, remotehost, remoteport FROM stl_connection_log ORDER BY starttime DESC LIMIT 10;
Cette requête récupère les 10 dernières connexions au cluster Redshift, incluant le nom d’utilisateur, l’heure de début, l’heure de fin, la durée, l’hôte distant et le port distant. En surveillant le journal des connexions, vous pouvez suivre l’activité des utilisateurs et identifier toute connexion suspecte ou non autorisée.
Analyse des schémas de connexion
Vous pouvez également utiliser stl_connection_log pour analyser les motifs de connexion et identifier d’éventuels problèmes. Par exemple, vous pouvez compter le nombre de connexions par utilisateur :
SELECT username, COUNT(*) as connection_count FROM stl_connection_log GROUP BY username ORDER BY connection_count DESC;
Cette requête vous donne un aperçu du nombre de connexions effectuées par chaque utilisateur. Si vous remarquez un nombre anormalement élevé de connexions pour un utilisateur particulier, cela pourrait indiquer un problème ou une conception d’application inefficace nécessitant une attention particulière.
Vues supplémentaires de journalisation et de surveillance de Redshift
En plus de stl_query et stl_connection_log, Redshift fournit plusieurs autres vues système qui aident à surveiller l’activité du cluster, à résoudre les problèmes de performance et à suivre le comportement des utilisateurs.
Suivi des erreurs de requête : stl_error
Enregistre toutes les erreurs liées aux requêtes. Utile pour déboguer les requêtes ayant échoué.
SELECT username, query, substring(error, 1, 50) AS error_snippet, starttime FROM stl_error ORDER BY starttime DESC LIMIT 10;
Surveillance des files d’attente de charge de travail : stl_wlm_query
Montre comment la gestion de charge de travail (WLM) de Redshift gère les requêtes en file d’attente et en cours d’exécution.
SELECT queue_start_time, total_queue_time, total_exec_time, slot_count FROM stl_wlm_query ORDER BY queue_start_time DESC LIMIT 10;
Audit des chargements de données : stl_load_commits
Suit l’utilisation de la commande COPY, vous aidant à surveiller les durées et l’efficacité des chargements.
SELECT query, table_name, lines_scanned, num_files, start_time, end_time, DATEDIFF(seconds, start_time, end_time) AS duration FROM stl_load_commits ORDER BY start_time DESC LIMIT 10;
Surveillance en temps réel : vues STV
stv_recents– Requêtes récemment terminées.stv_inflight– Requêtes en cours d’exécution et durée.stv_wlm_service_class_config– Configuration et limites actuelles du WLM.stv_blocklist– Utilisation des blocs disque et allocation d’espace.
Améliorer la journalisation de Redshift avec DataSunrise
Alors que les vues STL de Redshift fournissent des journaux détaillés et des métriques en temps réel, elles n’incluent pas de contrôles d’accès granulaires, de masquage ou d’intégration d’audit externe. C’est là que DataSunrise apporte de la valeur.
- Audit des requêtes en temps réel sur toutes les sessions Redshift
- Masquage dynamique des données basé sur les rôles des utilisateurs, les adresses IP ou le contenu des requêtes
- Journalisation centralisée avec conservation à long terme et recherche
- Bloquer les opérations risquées comme les scans complets de tables ou les exportations
- Conformité avec le RGPD, HIPAA, PCI DSS, et plus encore
DataSunrise se positionne entre les clients et votre cluster Redshift, analysant, enregistrant et contrôlant le trafic sans modifier la structure de vos données.
Conclusion
Les vues STL et STV de Redshift offrent de puissants outils pour la journalisation du comportement des requêtes, le suivi de l’accès et l’optimisation des performances du système. Mais pour les environnements nécessitant des traces d’audit, un contrôle d’accès aux données au niveau granulaire et l’application de la conformité, la simple journalisation native ne suffit pas.
DataSunrise améliore la visibilité et le contrôle de Redshift grâce à un masquage intelligent, des alertes et des capacités d’audit. Demandez une démo pour voir comment vous pouvez porter la surveillance de Redshift à un niveau supérieur tout en respectant les normes de protection des données d’entreprise.
