WebLog de Stéphane PAPP [MSFT]

Journal sur le web de Stéphane PAPP sur l'administration de systèmes.

Article d’Alban MONTANERA sur la proactivité avec Operations Manager

Blog - About

A propos du WebLog de Stéphane PAPP [MSFT]

Après près de 10 ans de conseil dans l'équipe française de Microsoft Consulting Services (MCS), j'ai rejoint l'équipe européenne de Customer Service and Support (CSS) comme ingénieur conseil grands comptes. Mon rôle consiste à délivrer du conseil proactif et réactif sur les logiciels de la gamme System Center (ConfigMgr et OpsMgr, principalement).
Je délivre de l'expertise technique associée aux méthodologies ITIL/MOF sous la forme d'atelier de type vérification de l'état de santé, évaluation des risques, revues de supportabilité, cours magistraux.
Si vous êtes intéressés pour avoir un contact Microsoft dédié pour des ressources techniques, travailler avec vous sur des projets, délivrer une formation ou un transfert d’expertise et vous aider à résoudre vos problèmes, le PFE dédié est fait pour vous. Pour en savoir plus, contactez votre responsable technique de compte ou interlocuteur habituel chez Microsoft.

Article d’Alban MONTANERA sur la proactivité avec Operations Manager

  • Comments 0

On parle souvent d’être plus proactif avec Operations Manager, qu’est-ce que cela signifie ?

En plus de traiter les alertes pour ne plus qu’elles reviennent plus, cela revient aussi à regarder les rapports qui permettent d’anticiper d’éventuels problèmes avant qu’ils n’arrivent.

Un exemple concret serait de regarder régulièrement le rapport ci-dessous. Il donne une idée des machines les plus sollicitées sur différents critères :

clip_image001

Ce rapport, permettra de vérifier qu’une nouvelle machine n’apparait pas en haut de la liste. Il faudrait alors vérifier ce qu’il se passe sur cette machine.

Si on clique sur la machine scomFY1312.nabla.local, on tombe sur un rapport lié qui ressemble à cela :

clip_image002

La partie  processor est vide car nous avons une règle de collecte qui n’est pas en phase avec le rapport. La règle de collecte se base maintenant sur le nouveau compteur « Processor Information »

clip_image003

Si vous souhaiter voir le graphique apparaitre, je vous recommande de rajouter une règle de collecte comme suit :

clip_image004

Imaginons maintenant que vous voyez régulièrement une machine qui fait des pics processors ou disques régulièrement la nuit. Vous allez devoir rajouter des compteurs pour le troubleshooting pour savoir si vous n’avez pas par exemple un backup qui passe en même temps qu’un scan antivirus. Pour ce genre de troubleshooting de performance, je vous recommande d’utiliser PAL de codeplex dont Clint Huffman de Microsoft est l’auteur.

L’outils permet d’analyser des compteurs de performance (SQL, AD, BizTalk, Exchange et bien d’autres) et de les représenter sous la forme d’un rapport unique avec tous les compteurs. Vous pouvez aller sur codeplex si vous voulez tester l’outils, si vous souhaitez uniquement voir un exemple de rapport vous en avez un ICI.

Pour que le troubleshooting de performance devienne plus proactif, il suffirait de générer automatiquement ces rapports. Pour arriver à cela j’ai créé une procédure stockée, qui va me retourner une liste de serveurs qui posent le plus de problèmes dans Scom. 

USE [OperationsManager]

GO

/****** Object:  StoredProcedure [dbo].[pall_GetAllComputerFromClass]  Script******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

Create PROCEDURE [dbo].[pall_GetAllComputerFromClass]

(

    @Class nvarchar(max),

    @Top int,

@Period int

)

AS

BEGIN

create table #tempo (

[NumStateChanges] integer NULL,

[ObjectName] [nvarchar](max) NULL,

[Path] [nvarchar](max) NULL,

[MonitorDisplayName] [nvarchar](max) NULL,

[MonitorIdName] [nvarchar](max) NULL,

[TargetClass] [nvarchar](max) NULL,

)

insert into #tempo ([NumStateChanges],[ObjectName],[Path],[MonitorDisplayName],[MonitorIdName],[TargetClass])

select top (@Top) count(sce.StateId) as NumStateChanges,

bme.DisplayName AS ObjectName,

bme.Path,

m.DisplayName as MonitorDisplayName,

m.Name as MonitorIdName,

mt.typename AS TargetClass

from StateChangeEvent sce with (nolock)

join state s with (nolock) on sce.StateId = s.StateId

join BaseManagedEntity bme with (nolock) on s.BasemanagedEntityId = bme.BasemanagedEntityId

join MonitorView m with (nolock) on s.MonitorId = m.Id

join managedtype mt with (nolock) on m.TargetMonitoringClassId = mt.ManagedTypeId

where m.IsUnitMonitor = 1

AND mt.TypeName = @Class

AND sce.TimeGenerated > dateadd(HH,-@Period,getutcdate())

group by s.BasemanagedEntityId,bme.DisplayName,bme.Path,m.DisplayName,m.Name,mt.typename

order by NumStateChanges desc

--To see the table

--select * from #tempo

select distinct [path] from #tempo order by [Path]

drop table #tempo

RETURN 0

END

A partir de la liste des serveurs, je lance sur les machines des perfmon que je récupèrerai par la suite (étape 2) pour les analyser puis les présenter dans Scom (étape 3). Vous trouverez ci-dessous un aperçu de ce que cela donne :

clip_image005

On aura ainsi la possibilité de partager les rapports PAL via la console Scom. On pourra donner accès aux DBA aux rapports SQL, aux administrateurs Windows aux rapports systèmes, etc.

Je ne détaille pas plus le mode de fonctionnement car cela a été fait pour montrer que l’on pouvait augmenter la proactivité, et ce « post » est déjà long. Smile

Enfin, je souhaite attirer votre attention sur le fait qu’il existe un workshop en rapport avec l’interprétation des compteurs de performance qui s’intitule : « Performance Monitor : Monitoring Vital Signs ».

Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post