none
Questions sur une interconnexion SCOM vers CA NSM RRS feed

  • Question

  • Bonjour à tous,

     

    Il faut donc que je  mette en place un renvoi d'alertes de SCOM  vers NSM (le connecteur dédié de CA n'est malheureusement pour moi pas envisageable).

    Pour ce faire, je vais configurer une réponse par ligne de commande avec une syntaxe bien définie pour que NSM puisse l'interpreter.

     

    J'ai cependant plusieurs problématiques :

    - dans cette syntaxe, je dois entrer à un endroit un code à 4 chiffres, totalement indépendant et inconnu de SCOM, qui sert de correspondance entre l'alerte SCOM et la reconnaissance dans NSM. J'avais dans l'idée de modifer les Custom fields des Rules et Monitors afin de pouvoir exploiter cette info supplémentaires dans le renvoi d'alerte, mais vu que les management packs sont verrouillés, ca n'est pas possible.

    Du coup, je me vois obliger de faire : soit 1 subscription et un channel par rule que je veux renvoyer (pas très propre à première vue), soit créer un management pack maison, donc non verrouillé, dans lequel je recrée chaque rule qui m'intéresse avec les infos en plus dans les custom field, mais là, je galère pour trouver comment dupliquer facilement une rule d'un management pack vers un autre (est-ce possible d'ailleurs ?)

     

    - je cherche également à créer un nouveau niveau de criticité (donc different de information, warninig et critical) pour cibler mes renvois d'alertes. Je sais qu'en faisant un override sur une alerte, on peut rentrer une valeur autre que 0, 1 ou 2 mais j'ai l'impression que ce n'est pas la bonne méthode car je ne retrouve que les 3 niveaux standards lorsque je filtre une nouvelle subscription sur le severity level.

    Sur notre archi Mom 2005, on a ce niveau supplémentaire grâce au connecteur Netcool installé, donc ca doit pouvoir se faire sur SCOM non ?

     

    Merci pour vos idées sur le sujet et n'hésitez pas si vous avez besoin de clarifier mon charabia :)

     

    mercredi 9 juin 2010 21:46

Réponses

  • Dans ce cas, c'est peut être plus simple de faire un script qui va lire le code dans une table de conversion dans un fichier Excel. Ce sera plus facile à maintenir.

    Quant à faire un pack d'administration et réécrire toutes les règles pour lesquelles vous voulez une notification c'est une mauvaise idée car vous aurez du mal à suivre les évolutions des packs d'administration. Pour info, un environnement moyen Operations Manager est composé de 10000 à 12000 règles et moniteurs.


    Yann Gainche MVP Operations Manager http://www.gainche.net
    • Marqué comme réponse JB Martin jeudi 10 juin 2010 14:14
    jeudi 10 juin 2010 13:58
    Modérateur

Toutes les réponses

  • Bonjour,

    Les niveaux de criticité sur SCOM sont figés et il n'est pas possible d'en créer. Lors d'une interconnection entre 2 produits, il y a toujours une correspondance à faire entre les champs disponibles sur les 2 produits. C'est pour cela qu'in utilise des connecteurs. Si vous ne pouvez pas utiliser le connecteur de CA, vous pouvez utiliser le connecteur universel (http://technet.microsoft.com/en-us/library/ee210410.aspx) mais il vous faudra faire un petit développement pour lire les fichiers xml, faire les correspondance et envoyer ver NSM.

    Recréer les règles dans un nouveau pack est une très mauvaise idée.

     

    Cordialement,


    Yann Gainche MVP Operations Manager http://www.gainche.net
    jeudi 10 juin 2010 09:23
    Modérateur
  • Merci Yann pour votre réponse.

     

    A dire vrai, je ne pense pas être capable de mettre en place le connecteur universel.

    Je vais détailler un peu mieux le type de réponse que l'on doit renvoyer à NSM. Sur mes 2 serveurs de management SCOM, il faut utiliser un exe (cawto.exe) qui s'est installé en même temps qu'une surcouche de communication spéciale . Celui-ci communique sur des ports bien particulier

    Voici la syntaxe :

    cawto -n <nom_du_serveur_NSM > "MOMTOTNG: <nom_du_serveur_à_problème > C_<xxxx> <description_de_l_alerte> DOWN"

     

    xxxx est donc ce fameux code à définir suivant l'alerte.

    C'est pour ça qu'une subscription + channel (type command) me paraissait repondre le mieux et le plus simplement à ce besoin.

     

    Sinon, au pire, je ne pourrais pas envisager une réponse par script dans lequel je liste toutes les correspondances numéro/alerte et formate la réponse cawto.exe grâce à un "select case "  (ou plutot switch en powershell) ?

     

    Pour ma culture personnelle, pourquoi est-ce une mauvaise idée de recréer les regles dans un nouveau pack ?

     

    Merci d'avance pour votre aide

     

    Jean-Baptiste

    jeudi 10 juin 2010 13:31
  • Dans ce cas, c'est peut être plus simple de faire un script qui va lire le code dans une table de conversion dans un fichier Excel. Ce sera plus facile à maintenir.

    Quant à faire un pack d'administration et réécrire toutes les règles pour lesquelles vous voulez une notification c'est une mauvaise idée car vous aurez du mal à suivre les évolutions des packs d'administration. Pour info, un environnement moyen Operations Manager est composé de 10000 à 12000 règles et moniteurs.


    Yann Gainche MVP Operations Manager http://www.gainche.net
    • Marqué comme réponse JB Martin jeudi 10 juin 2010 14:14
    jeudi 10 juin 2010 13:58
    Modérateur
  • Effectivement, vu sous cet angle, le travail parait démesuré :)

    Mais bon, je pensais de toute façon sélectionner les alertes qui, à mon sens, sont les plus pertinentes. Ca devrait épurer pas mal le nombre d'alertes remontées.

    Merci en tout cas pour vos conseils

    jeudi 10 juin 2010 14:13