Imprimer
Catégorie : eXtended Logging
Affichages : 9721

Le logiciel Orchestrator 2012 proposé par Microsoft dans la gamme System Center, est un outil puissant et pourvu de nombreux atouts pour qui souhaite automatiser de nombreux processus au sein de l'entreprise et notamment au niveau de l'infrastructure informatique. Néanmoins un point faible de ce logiciel est l'absence (presque totale) de système de log. La journalisation interne se cantonne à conserver, dans la base de données du produit, et pendant un temps limité (quelques jours dans la configuration par défaut), des informations basiques comme par exemple quel utilisateur a modifié quel runbook ou les erreurs rencontrées lors de l'exécution des runbooks. Nativement il n'est pas possible d'indiquer au système de conserver une donnée particulière.

Un Integration Pack nommé "Standard Logging" est proposé par Charles Joy (Microsoft) sur codeplex : http://orchestrator.codeplex.com/releases/view/76097. Cet Integration Pack permet de combler en partie la lacune de Orchestrator en termes de possibilité de journalisation. Cependant cet Integration Pack est encore trop limité à mon goût car il a été pensé uniquement pour permettre de débugguer un runbook, et il ne propose que de conserver les dernieres données issues d'un runbook. C'est pourquoi j'ai décidé de développer un nouvel Integration Pack basé sur celui de Charles Joy en apportant une nouvelle logique de fonctionnement. Je l'ai baptisé "eXtended Logging".

Le principe de base reste le même, permettre à l'administrateur utilisant Orchestrator de rajouter au sein des runbooks des activités permettant d'écrire de la donnée diverse dans une bases de données SQL. La base de données SQL de destination est composée de deux tables qui représentent pour la première les différents journaux (une entrée par journal), et pour la seconde le contenu du journal divisé en étape (une ligne par étape). J'ai également introduit la notion de durée de rétention souhaitée qui permet, à l'aide d'une procédure stockée, de supprimer les différents jounaux et contenus associés, arrivés à péremption.

 

L'Integration Pack est disponible au téléchargement ici (version 64 bits pour System Center Orchestrator 2022) : OIPeXtendedLogging2.0.zip (664 ko)

 

Le fichier ZIP contient plusieurs fichiers dont :

 

Installation et configuration :

Les pré requis à l'utilisation de cet Integration Pack sont :

La mise en oeuvre de cet Integration Pack consiste donc à déployer l'OIP, à créer la base de données SQL associée sur une instance SQL, et enfin à configurer l'IP afin de lui indiquer ou est hébergée la base de données que le système utilisera pour stocker les journaux. La création de la base de données et des éléments la consitituant doit être réalisé à l'aide des scripts SQL fournis dans le package. Il est nécessaire d'exécuter les scripts dans l'ordre (du 01 au 04).

Dans le script "01 - CreateeXtendedLoggingDatabase.sql" attention de bien modifier le chemin des fichiers qui composent la base de données (lignes surlignées en jaune ci dessous).

 

CREATE DATABASE [eXtendedLogging] ON   PRIMARY

( NAME = N'eXtendedLogging' , FILENAME = N'Z:\SGBDData\MSSQL11.SCOR\MSSQL\DATA\eXtendedLogging.mdf' , SIZE = 104448KB , MAXSIZE = UNLIMITED , FILEGROWTH = 102400KB )

LOG ON

( NAME = N'eXtendedLogging_log' , FILENAME = N'Z:\SGBDData\MSSQL11.SCOR\MSSQL\DATA\eXtendedLogging_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 64512KB )

GO

 

Une fois que l'OIP est déployé sur le ou les serveurs Orchestrator et que la base de données est créée il est nécessaire de procéder à la configuration de l'Integration Pack à l'aide de la console "Runbook Designer".

Dans le menu "Option" un élément nommé "eXtended Logging" devra être disponible (aprés le déploiement de l'OIP réalisé précedemment). Il suffit donc de cliquer sur "eXtended Logging" et d'ajouter un élément de configuration. Une fois le type de configuration "eXtended Logging Settings" choisit, il sera nécessaire de saisir plusieurs champs :

 

Utilisation :

L'Integration Pack eXtended Logging contient 4 activités :

Les activités "Log Step" et "Get Log Data" requièrent  le paramètre "LogID" en entrée. Ce paramètre peut être founit par l'intermédiaire du bus de données ("published data") depuis l'activité "Create Log" qui renvoit sur le bus de données le "LogID" qui a été généré lors de la création d'un nouveau journal dans la base de données.

 

Create Log :

L'activité "Create Log" propose de saisir plusieurs propriétés dont 3 optionnelles ("Description", "Custom Field 01" et "Custom Field 02").

L'activité Create Log renvoit les données suivantes sur le bus de données :

 

Log Step :

L'activité "Log Step" permet de créer une nouvelle entrée dans un journal créé auparavant. Cette activité propose de nombreuses propriétés dont 4 sont optionnelles ("Custom Field" de 01 à 04).

Les données renvoyées sur le bus de données par cette activité sont les suivantes :

 

Get Log Data :

L'activité Get Log Data permet de lire un journal donné dans la base de données. La seule propriété à fournir à cette activité est le "Log ID" du journal à lire.

L'activité "Get Log Data" renvoit une collection contenant autant d'élements que de lignes dans le journal concerné. Cette activité renvoit les données suivantes sur le bus de données (Noter que tout ce qui est spécifique à la table eXtended_Logging_LOG est préfixé par "Log") :

 

Purge Log :

L'activité "Purge Log" a pour unique fonction de supprimer les logs périmés (ainsi que les steps associés) dans la base de données. Cette activité ne nécessite aucune propriété ; elle renvoit néanmoins les données suivantes sur le bus de données :

 

Exemple d'utilisation :

 

La capture d'écran ci dessus montre un exemple de runbook simple mettant en oeuvre l'Integration Pack eXtended Logging. Il s'agit d'une suite de 3 activités (création d'un déploiement d'un groupe de mise à jour SCCM sur une collection donnée) dont les retours respectifs, qu'ils soient positifs ou négatifs (succès ou échec) sont enregistrés dans la base de données de journalisation. L'activité nommé "Log Get Deployment Success" dans l'exemple permet ici d'enregistrer en base de données le fait que l'activité "Get Deployment" s'est correctement déroulée, ainsi que certaines données comme ici l'ID de l'éventuel déploiement existant pour le groupe de mise à jour SCCM sur la collection donnée.

La requête SQL ci dessous montre le contenu d'un journal aprés l'exécution du runbook exemple :

SELECT FROM eXtended_Logging_STEP

WHERE LogID =(SELECT TOP(1) LogID FROM eXtended_Logging_LOG

WHERE Log_Name LIKE '%Create Deployment%'

ORDER BY LastUpdate_DateTime DESC)

ORDER BY Activity_End_DateTime

 

 

Le journal enregistré en base de données est donc composé des 3 steps ("Get SUG", "Get Deployment", et "Create Deployment On SUG"). Dans le champs "Custom_Field_02" j'ai choisi d'enregistrer l'ID (18056 dans l'exemple) du groupe de mise à jour SCCM (Software Update Group) que je récupère pendant l'exécution de l'activité "Get SUG".

 

Historique des versions :

1.0 (18/09/2014) - Première version publique
2.0 (22/03/2023) - Version 64 bits pour System Center Orchestrator 2022