En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.
Network Summary, Network Node, Network Interfaces et Vicinity view.
- La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)
Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.
- La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :
- la vue des liens connectés à l’équipement sélectionné
- des jauges sur la disponibilité de l’équipement dans le temps
- la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.
- La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.
- La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.
Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.
La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.
En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.
La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».
Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.
A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.
Trop souvent, les souscriptions d’alertes ne sont pas utilisées à leur plein potentiel : une seule souscription est créée, ce qui peut bien entendu suffire dans certains cas mais pourraient être largement optimisé dans d’autres.
On peut ainsi définir de vrais scénarios d’escalade : par exemple si aucune action n’a été effectuée pour résoudre une alerte après un délai imparti, on peut décider d’envoyer un SMS à un responsable ou bien de transférer l’alerte à un autre service.
Prenons l’exemple de la souscription suivante, nommée « Alerte Linux » :
Il s’agit d’une souscription des plus classique, où toutes les nouvelles alertes (resolution state 0) concernant les serveurs membres du groupe Unix Computers (donc tous les ordinateur Unix/Linux monitorés par SCOM) et de priorité moyenne ou haute seront adressées par mail à l’utilisateur « Support_Linux ».
Imaginons maintenant que nous souhaitons que cette alerte soit automatiquement transmise par SMS à un responsable si elle n’est pas prise en charge au bout d’une heure.
Il suffit pour ce faire de créer une alerte avec des conditions de déclenchement identiques en tous points à la précédente, que nous nommerons par exemple « Alerte Linux (+1h) » et qui sera cette fois destinée à l’utilisateur « Manager_Linux » avec un délai (alert aging) d’une heure :
En se basant sur ce système, il devient très simple de créer des scénarios d’escalade en fonction du niveau de résolution, de l’heure de la journée (en créant des subscribers valables uniquement la nuit pour les astreintes par exemple) ; ou bien de n’envoyer l’alerte par mail que si elle n’a pas été prise en compte directement dans la console… les possibilités sont vastes !
Et comme il peut être fastidieux de recopier à l’identique les conditions de déclenchement d’une subscription (sans parler du risque de se tromper), Timothy McFadden (PFE chez Microsoft) a developpé un outil très pratique, Subscription Copier :
Il permet de sélectionner une subscription initialement créée avec les bons paramètres de la copier autant de fois que vous en aurez besoin pour votre scénario d’escalade. Il permet également de prédéfinir un délai (alert aging) qui s’incrémente de copie en copie.
Disponible sur son blog : http://www.scom2k7.com/subscription-copier/
La taille des sources de cette mise a jour (un peu plus d’1 Gb) qui contiens les mises a jours des cumulative update précédents, s’explique aussi par la présence de composants propre a la supervision Unix/linux (Cross Platform).
Indépendamment des correctifs inclus, cette mise a jour apporte un nouvel assistant pour la supervision des applications issus de la plate-forme de service en ligne Microsoft Azur, ainsi que des fonctions d’utilisation de paramètres pour la supervision avancée des sites web.
Les sources de cette mise a jour sont disponible ici:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9f1e1154-52ae-42df-aeea-b3ee83247e6a
Pour une description complète et un retour d’expérience précieux sur cette mise a jour:
http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/81313/Default.aspx
Ce qui avait été annoncé comme non supporté fait finalement l’objet d’une procédure particulière utilisant l’outil de création des bases SCOM, DBCreateWizard.exe inclu dans les sources de SCOM.
Pour plus de détails rendez vous sur http://support.microsoft.com/kb/2425714
Un type d’alerte dont la répétition est particulièrement indésirable est celui des erreur liés a des requêtes WMI en échec du a des problèmes de ressources système:
HRESULT: 0x800700a4
Details: No more threads can be created in the system.
HRESULT: 0x80041001
Details: Generic failure
HRESULT: 0x80041006
Details: Out of memory
En effet, la gestion de la mémoire dans WMI est assez spécifique et ces erreurs sont susceptibles d’intervenir même sur des systèmes bien dimensionnés
Cette alerte qui peut être récurrente a donc une source externe a SCOM.
Ces alertes et erreurs associées peuvent être évitées en modifiant un des paramètres WMI correspondant a la mémoire.
Pour cela, sur la machine concernée par l’erreur:
- Executez la commande wbemtest (en mode administrateur)
- Connectez vous a l’espace de nom "root" (pas "root\default", juste "root")
- Selectionnez Ouvrir une instance (ou Open an instance)
- Tapez __ProviderHostQuotaConfiguration=@ et cliquez OK
- Cochez la case “Locales seulement" (Local Only), selectionnez la propriété MemoryPerHost ou ThreadsPerHost selon la source de l’erreur (voir plus haut)
Modifiez ces valeurs de manière raisonnable (valeur double pour commencer)
- Cliquez sur Enregistrer la propriété (Save Property) puis sur Enregistrer l’objet (Save Object)
- Redémarrer le service Windows Management Instrumentation
La version R2 de Xian Network Manager IO viens de sortir !
Au menu de la plus facile a intégrer et a configurer des solutions de supervision complémentaire de SCOM:
- La possibilité d’ajouter vos propres règles de supervision SNMP si elles ne sont pas fournis nativement dans les smart management pack de Jalasoft.
- Une interaction avec Savision liveMaps (solution de cartographie proposé en bundle avec Xian) permet désormais de découvrir automatiquement la topologie réseau et de la cartographier a partir des informations fournis par Xian.
- Calcul de seuil de performance automatique dans le même esprit que les self-tunning threshold ce SCOM
- Gestion plus intelligente des informations envoyés a SCOM afin de limiter les alertes
- Système de filtrage des composants issus des équipements réseaux afin de n’afficher dans SCOM que les objets réellement supervisés
Un paramètre important lors de l’installation d’un serveur RMS en cluster:
Dans les propriétés des ressources services…
Il est indispensable dans l’onglet Dependencies de faire dependre la ressource sur le nom reseau du cluster RMS
Puis dans l’onglet General de cocher l’option Use Network Name for computer name
Ainsi les agents discuteront bien avec le SPN de la ressource RMS et non celui des nœuds physiques du cluster.
Microsoft a mis en ligne une nouvelle version du management pack d’administration “natif” de SCOM 2007 R2: la 6.1.7599.0
Parmi les nouveautés, peuvent être soulignés:
- Une fonctionnalité permettant à l’agent SCOM de superviser sa propre consommation mémoire et en cas d’une consommation excessive, la capacité de s’auto-redémarrer.
- Un meilleur suivi des agents inactifs: Si l’agent ne répond plus, test du ping du serveur hôte, démarrage du service s’il est simplement arrêté, éventuellement déclencher la réinstallation de l’agent…
- Détection de problème au sein des Management Packs (aide à la détection des problèmes dans les découvertes, scripts, droits d’accès…)
Je vous laisse découvrir la suite en cliquant sur le lien ci-dessous:
http://www.microsoft.com/downloads/details.aspx?FamilyID=61365290-3c38-4004-b717-e90bb0f6c148&displaylang=en
Nous avons rencontrés aujourd’hui un souci avec les agents scom 2007 R2.
Sur un cluster RMS, la procédure de déploiement d’agents se déroulait bien mais les agents ne s’installaient pas. Ces derniers restaient bloqués en « pending » avec une « installation in progress », les event ID 21016 apparaissent dans le journal d’évènements.
La solution pour les approuver fut de passer par la commande powershell : get-agentpendingaction | approve-agentpendingaction