Historique d’activité de la base de données Vertica
Vertica sert souvent de noyau analytique pour les plateformes de reporting, les tableaux de bord BI et les pipelines de données à haut volume. Lorsqu’un problème survient dans cet environnement, les équipes ont besoin de plus qu’un simple enregistrement d’audit. Elles doivent reconstruire l’historique complet d’activité de la base de données Vertica autour d’un problème : quelles requêtes ont été exécutées, comment elles se sont comportées, et quels utilisateurs ou applications les ont déclenchées. Cet article explique comment Vertica expose l’historique d’activité natif, et comment DataSunrise enrichit ce signal pour créer une vue opérationnelle unifiée.
DataSunrise complète la surveillance intégrée de Vertica en capturant le trafic SQL, en normalisant les événements et en les stockant dans un référentiel central. Associé à des fonctionnalités telles que la surveillance de l’activité de la base de données, l’historique d’activité de la base de données et l’historique d’activité des données, il transforme des journaux de bas niveau en une chronologie cohérente du comportement de la base de données. Pour plus de détails sur les métriques natives et les tables système, la documentation officielle de Vertica reste un compagnon utile.
Pourquoi l’historique d’activité est important pour Vertica
L’historique d’activité de la base de données se concentre sur les détails d’exécution plutôt que seulement sur l’identité de l’utilisateur ayant lancé une instruction spécifique. Les ingénieurs et analystes peuvent l’utiliser pour répondre à des questions telles que :
- Quelles requêtes ont dominé l’utilisation du CPU, des entrées/sorties ou de la mémoire durant un incident de performance ?
- Un nouveau travail ETL a-t-il modifié la charge de travail au cours d’une semaine donnée ?
- Quels comptes applicatifs produisent le plus grand nombre d’instructions échouées ou longues à s’exécuter ?
- Comment les modèles d’activité diffèrent-ils entre les heures de pointe et les heures creuses ?
Cette vue opérationnelle complète les audits traditionnels de données et l’audit des journaux. Les pistes d’audit se concentrent sur la responsabilité et la conformité, tandis que l’historique d’activité révèle comment Vertica se comporte en tant que système sous des charges de travail changeantes.
Composants natifs de Vertica pour l’historique d’activité
Vertica enregistre déjà un ensemble riche de détails sur l’exécution des requêtes. Les administrateurs peuvent interroger les vues système et les journaux de diagnostic pour reconstruire ce qui s’est passé à l’intérieur d’un cluster.
v_monitor.query_requests– liste les requêtes récentes avec le nom d’utilisateur, le type de requête, un extrait du texte SQL, les horodatages, le statut et les compteurs d’erreurs.- Vues de session – telles que
v_monitor.sessionset les tables associées, qui montrent les sessions actives et historiques, les adresses clients et les noms d’application. - Vues d’exécution et de ressources – incluant
v_monitor.execution_engine_profilespour des statistiques détaillées par étape ainsi que des vues pour l’utilisation CPU, mémoire et disque. - Journaux de diagnostic – fichiers journaux du moteur capturant les événements de bas niveau, les changements de configuration et les messages d’erreur.
Requête sur v_monitor.query_requests retournant l’historique d’exécution des demandes récentes, incluant l’utilisateur, le type de requête, un extrait SQL, les horodatages et un indicateur de succès.
Ces composants fournissent ensemble un historique fiable et de bas niveau de l’activité de la base de données. Toutefois, ils restent locaux à chaque cluster et nécessitent des requêtes ou scripts personnalisés pour analyser les tendances, corréler l’activité entre systèmes, ou alimenter les outils SIEM et d’observabilité. Pour simplifier ce travail, de nombreuses équipes ajoutent une couche dédiée à la surveillance d’activité autour de Vertica.
Extension de l’historique avec DataSunrise en mode sniffer
DataSunrise peut observer le trafic Vertica soit comme proxy, soit en utilisant le mode sniffer. En mode sniffer, la plateforme écoute le trafic réseau entre les applications et Vertica sans modifier les chaînes de connexion. Elle analyse ensuite le SQL, applique des règles et enregistre les événements dans son propre stockage d’historique.
Historique d’activité de la base de données Vertica en mode sniffer : DataSunrise écoute le trafic SQL, analyse les instructions, applique des règles, les transmet à Vertica, et sauvegarde les événements normalisés dans le référentiel d’historique d’activité.
Cette approche combine la télémétrie native de Vertica avec un historique d’activité externe couvrant plusieurs clusters et autres plateformes. Elle permet également des analyses plus avancées telles que l’analyse du comportement des utilisateurs et la sécurité inspirée des données, qui s’appuient sur des données d’événements cohérentes et inter-systèmes.
Configuration de Vertica en tant que source monitorée
Pour commencer à collecter l’activité, les administrateurs enregistrent Vertica comme base de données dans la console DataSunrise. Ils spécifient les paramètres de connexion, le login par défaut et la méthode d’authentification. Même en mode sniffer, cette configuration fournit les métadonnées nécessaires à DataSunrise pour interpréter correctement le trafic capturé.
Après que les administrateurs ont sauvegardé la configuration et complété la configuration réseau décrite dans les guides Modes de déploiement et Reverse Proxy, DataSunrise commence à observer le trafic Vertica et à construire un historique centralisé de l’activité de la base de données.
Création de règles pour l’historique de l’activité de la base de données
Ensuite, les équipes décident quels événements doivent intégrer le stockage de l’historique. Dans DataSunrise, cela se fait via des règles d’audit et de surveillance spécifiant la base de données, les objets et les types de requêtes à suivre.
Les règles peuvent distinguer les opérations de lecture et d’écriture, se concentrer sur certains schémas, ou mettre en évidence des tables sensibles nécessitant une surveillance renforcée. Le même jeu de règles supporte ultérieurement la surveillance de l’activité de la base de données, les pistes d’audit classiques ainsi que les vues d’historique d’activité de Vertica. Cette réutilisation réduit la dérive de configuration et maintient la cohérence des politiques de surveillance.
Analyse des événements dans les pistes transactionnelles
Une fois les règles de journalisation activées, chaque opération capturée fait partie de l’historique partagé. DataSunrise expose cet historique via la vue Audit → Pistes transactionnelles, qui affiche l’activité Vertica aux côtés des événements provenant d’autres bases de données.
Les analystes peuvent filtrer les événements par règle, type de base, utilisateur, type de requête ou statut d’erreur. Ils peuvent également exporter les résultats pour une analyse hors ligne ou les diffuser vers des plateformes SIEM. Cette interface unifiée accélère les enquêtes qui nécessiteraient autrement plusieurs requêtes dans Vertica et des inspections de fichiers journaux.
Historique natif et DataSunrise : côte à côte
Les fonctions natives de Vertica et DataSunrise fournissent des vues différentes mais complémentaires de l’activité de la base de données. Le tableau ci-dessous résume leurs rôles.
| Capacité | Vertica natif | Couche DataSunrise |
|---|---|---|
| Détails d’exécution des requêtes | Les vues v_monitor et les journaux moteur affichent les métriques par requête |
Normalise les événements de Vertica et d’autres plateformes dans un schéma commun |
| Rétention et stockage | Historique local au cluster avec rétention limitée | Stockage à long terme configurable adapté aux audits et analyses de tendances |
| Corrélation inter-systèmes | Nécessite des outils personnalisés pour plusieurs clusters | Console centrale corrélant l’activité de nombreuses bases et magasins de données |
| Analyse de sécurité et de risque | Requêtes manuelles sur les vues système | Analyses intégrées, évaluation des vulnérabilités et modèles comportementaux |
En s’appuyant sur les deux côtés de ce tableau, les organisations conservent la précision des métriques natales de Vertica au niveau moteur tout en bénéficiant de la commodité d’une visibilité et d’un reporting centralisés.
Cas d’utilisation avancés pour l’historique d’activité de la base de données
Avec un historique complet en place, les équipes peuvent aller au-delà du simple dépannage :
- Analyse des régressions de performance : comparer l’activité avant et après une mise à jour ou un changement de schéma.
- Validation des charges de travail ETL : vérifier que les nouveaux pipelines de données respectent les calendriers attendus et n’engorgent pas les clusters Vertica.
- Détection d’anomalies de sécurité : identifier des motifs de requêtes inhabituels ou des accès depuis des lieux inattendus en utilisant le contexte de contrôle d’accès basé sur les rôles et des lignes de base comportementales.
- Préparation à la conformité et aux audits : fournir aux auditeurs un historique d’événements cohérent et interrogeable plutôt qu’une collection de fichiers journaux déconnectés.
Ces scénarios montrent comment l’historique d’activité de la base de données soutient tant les opérations quotidiennes que les initiatives de gouvernance à long terme, particulièrement lorsqu’il est combiné avec des contrôles de sécurité des bases de données.
Conclusion
Un historique détaillé d’activité de la base de données Vertica donne aux équipes le contexte nécessaire pour comprendre le comportement des requêtes, l’évolution des charges de travail et la manière dont les utilisateurs interagissent avec les données critiques. Les vues système natives de Vertica et ses journaux de diagnostic fournissent déjà une base solide, mais ils fonctionnent mieux avec une plateforme centralisée capable de stocker, corréler et analyser les événements dans le temps. DataSunrise remplit ce rôle en capturant le trafic Vertica en mode sniffer ou proxy, en appliquant des règles flexibles, et en présentant un historique d’activité unifié à travers de nombreux systèmes.
En combinant ces deux perspectives, les organisations passent d’une gestion réactive des incidents à une vision proactive. Elles peuvent enquêter plus rapidement, optimiser les charges de travail plus efficacement, et démontrer que leurs clusters Vertica fonctionnent conformément aux politiques internes et réglementations externes telles que décrites dans les réglementations sur la conformité des données. En pratique, cela se traduit par moins de surprises, une performance plus prévisible, et une compréhension claire de la manière dont les données analytiques précieuses circulent dans l’environnement.
