SSIS Job Monitoring and Reporting

Question

Notre boutique dépend fortement de SSIS pour exécuter nos processus back-end et nos tâches de base de données. Dans l'ensemble, nous avons des centaines d'emplois et, pour la plupart, tout fonctionne efficacement et sans heurt.

La plupart du temps, nous avons un échec de travail dû à une défaillance de dépendance externe (données non disponibles, fichiers non livrés, etc.). À l'heure actuelle, notre processus est configuré pour nous envoyer un courriel chaque fois qu'un travail échoue. SSIS génère un e-mail nous envoyant le nom du travail et l'étape à laquelle il a échoué.

Je cherche à créer un tableau de bord de sorte à surveiller ce processus plus efficacement. Je sais que les mêmes informations disponibles dans la fenêtre Historique des travaux de SSIS sont également disponibles en interrogeant la base de données msdb. Je veux configurer un emplacement central pour signaler les échecs (probablement en utilisant SQL Reporting Services), ainsi qu'un système d'alerte par courrier électronique plus intelligent.

Est-ce que quelqu'un d'autre a traité ce problème? Si oui, quel type de processus/de reporting avez-vous créé autour des procédures SSIS pour rationaliser la notification des échecs de travail ou des alertes?

Answer 1

Nous avons une configuration similaire dans notre société. Nous comptons principalement sur le fait de laisser les emplois nous informer quand il y a un problème et nous avons des employés qui vérifient les statuts de travail à des moments précis pour s'assurer que tout fonctionne correctement et que rien n'a été négligé. Mon équipe reçoit un e-mail HTML SQL Server Agent Job Activity Report tous les matins à 6h et 16h qui répertorie tous les travaux échoués en haut, les travaux en cours en dessous, et tous les autres emplois en dessous de ceux groupés en quotidienne, hebdomadaire, mensuelle, trimestriel et d'autres catégories. Nous surveillons essentiellement les travaux de l'Agent SQL Server, pas les packages SSIS eux-mêmes. Nous nous appuyons sur les catégories d'emploi et les conventions de dénomination des horaires de travail pour automatiser le regroupement dans le rapport.

Nous avons une configuration similaire pour surveiller nos abonnements SSRS. Cependant, nous ne surveillons que celui-ci une fois par jour puisque la plupart de nos abonnements sont déclenchés vers 3h-4h du matin. Le rapport d'activité d'abonnement SSRS va plus loin que le rapport d'activité de l'agent SQL Server en ce sens qu'il contient des liens vers l'écran d'abonnement du rapport et que la gestion des exceptions y est plus importante. En plus de compter sur les rapports, nous avons également quelques tâches qui sont configurées pour notifier l'opérateur par e-mail à la fin du travail et non en cas d'échec du travail. Cela permet de vérifier rapidement si tous les principaux processus ETL ont été exécutés avec succès. C'est en quelque sorte un indicateur précoce de la santé du système. Si nous n'avons pas reçu ce courriel au moment où le premier membre de l'équipe arrive au bureau, nous savons que quelque chose ne va pas. Nous avons également une série de tâches qui échoueront avec une erreur de travail si certaines sources de données n'ont pas été chargées à une heure spécifique. Avant que quelqu'un ne travaille tôt, je vérifiais l'adresse e-mail de mon iPhone à chaque fois que je me réveillais au milieu de la nuit (ce qui arrivait souvent depuis que j'avais un nouveau-né). Dans les rares occasions où je n'ai pas reçu d'e-mail indiquant que tout était terminé ou que j'ai reçu une erreur concernant une étape de travail, je me suis connecté à mon ordinateur via le bureau distant pour vérifier l'état des travaux. Je pensais que nos responsables du centre de données vérifiaient l'état des serveurs en publiant un rapport chaque matin vers 4 heures du matin, mais finalement j'ai décidé que ce ne serait pas nécessaire puisque nous avons une personne qui commence à travailler à 6 heures du matin. La principale préoccupation que j'avais à propos de la mise en œuvre de ce processus est que notre ETL change au fil du temps et il aurait été nécessaire pour moi de conserver la documentation sur la façon de vérifier les tâches correctement et d'escalader les notifications à mon équipe. Je serais prêt à le faire si les processus devaient se dérouler au milieu de la nuit. Cependant, notre ETL fonctionne toutes les heures de la journée, donc si nous devions lancer tous nos principaux processus ETL tôt le matin, nous terminerions le chargement de notre entrepôt de données et publierions des rapports avant que quiconque n'entre au bureau.De plus, notre bureau commence VRAIMENT en retard pour une raison quelconque, donc les gens ne font normalement pas fonctionner nos rapports interactivement jusqu'à 9 heures du matin.

Answer 2

Si vous ne souhaitez pas créer de version personnalisée complète, vous pouvez utiliser https://cronitor.io pour surveiller les travaux etl.