Forum Français

 View Only
Expand all | Collapse all

ArubaOS-CX et l'automatisation - Part 4.2 : Gestion des scripts et agents du NAE

This thread has been viewed 1 times
  • 1.  ArubaOS-CX et l'automatisation - Part 4.2 : Gestion des scripts et agents du NAE

    Posted Jan 02, 2019 08:46 AM

    Tous mes voeux à tous ! Afin de commencer cette nouvelle année, nous allons poursuivre notre découverte de l'automatisation avec ArubaOS-CX.

     

    Le Network Analytics Engine est un outil qui s’utilise avant tout au travers de la WebUI d’ArubaOS-CX. Il reste cependant disponible au travers de la CLI et des APIs.

     

    Nous allons donc reprendre notre script utilisé dans la partie 4.1, qui permettait de pouvoir monitorer le statut d’une interface spécifiée, et de prendre des actions lorsque cette dernière passe en statut « down ».

    Nous allons prendre le script natif, sans l’utilisation des « clear_actions ». Dans ce cadre, le script utilise la methodologie suivante :

    1. Un monitor, qui monitore le statut d’une interface donnée en paramètre.
    2. Une premiere règle, qui, si le statut passe de “up” à “down”, lance les actions comprises dans la fonction “action_interface_down”
    3. Une seconde règle, qui, si le statut passe de “down” à “up”, lance les actions comprises dans la fonction “action_interface_up”

    Afin d’uploader un script dans le Network Analytics Engine, il est donc nécessaire de prendre la main sur la WebUI, et de se rendre dans le menu « Analytics » :
    Screen Shot 2018-12-19 at 14.42.37.png

      

    A partir de cette page, vous avez accès alors à l’ensemble des informations liées au Network Analytics Engine :

    • La liste des agents créés (activés ou desactivés)
    • La liste des scripts installés (utilisés ou non)
    • La liste des alertes
    • Les widgets de certains agents (personnalisable)
    • Un lien vers la liste des scripts disponibles sur Aruba Solution Exchange

    La première étape est donc d’installer un script sur le Network Analytics Engine.

    Pour se faire, allez dans « scripts ». Vous pouvez alors soit uploader le script, soit l’installer via la page dédiée a ASE :

     Screen Shot 2018-12-19 at 14.47.46.png

     

    Si vous souhaitez consulter la liste des scripts disponibles sur ASE, cliquez alors sur le logo « ASE ». Vous obtiendrez alors la liste complète des scripts disponibles, avec plusieurs actions possibles :

    Screen Shot 2018-12-19 at 14.52.41.png

     

    Si nous revenons sur la méthodologie de gestion de vos scripts, vous devez alors cliquer sur « Upload ». Vous obtiendrez alors la fenêtre suivante, qui vous permet de naviguer jusqu’à votre script, ou simplement de faire un drag-and-drop.

    Les informations liées à votre script, contenues dans le dictionnaire « Manifest » apparaissent alors :

     

    Screen Shot 2018-12-19 at 14.53.29.png

      

    Vous avez également la possibilité de faire un « write memory » en cochant la case « copy running configuration to startup ». Sinon, si le switch redémarre de manière inopinée, alors le script, et le ou les agents associés ne seront plus présents.

     

    Une fois le script uploadé, il passe par une phase de validation, afin que NAE vérifie la conformité du script, que ce soit pour vérifier la présence des éléments obligatoires, comme le "manifest" ou qu’il n’y a pas d’erreurs de syntaxe.Screen Shot 2018-12-19 at 14.58.37.png

     

    Une fois le script présent sur l’équipement, il suffit alors de créer l’agent, en spécifiant le nom de l’agent ou en renseignant les valeurs des paramètres si ceux par défaut ne conviennent pas :

     

    Screen Shot 2018-12-19 at 14.58.55.png

     

    L’agent est donc créé, et la page dédiée est automatiquement générée, incluant la partie graphe.

    Étant donné que par défaut l’état de l’agent lors de sa création est sur « Enable », il entre directement en action, sans attendre une action quelconque de l’administrateur :

     Screen Shot 2018-12-19 at 14.58.41.png

      

    On y retrouve le listing des paramètres, avec la possibilité de modifier à tout moment les éléments définis lors de la création de l’agent, y compris la possibilité de l’activer ou de le désactiver.

    En cliquant sur un paramètre, on retrouve la description donnée dans le script.

     Screen Shot 2018-12-19 at 14.58.48.png

     

    Notre agent NAE est désormais actif et opérationnel.

     

    1. Les agents NAE en action

    L’agent est donc actif, et en statut « Normal ».

    Dans notre use case simple, l’agent est là pour superviser le statut de l’interface 1/1/1.

    Faisons donc un test afin de vérifier le comportement et les éventuelles actions prises par notre agent. Sur l’équipement :

     

    Switch-CX# conf
    Switch-CX(config)# int 1/1/1
    Switch-CX(config-if)# shutdown

    Au bout de quelques secondes, nous voyons donc le script qui réagit, notamment avec une barre d’alerte qui apparait en bas de la page, informant l’administrateur que le statut de l’agent est passé de « Normal » à « Critical ». Cette barre apparaît quelque soit la page sur laquelle se trouve l’administrateur :

     Screen Shot 2018-12-19 at 14.59.04.png

      

    Plusieurs éléments nouveaux apparaissent alors.

    Sur le graphe, nous avons des triangles qui apparaissent. Lorsque le triangle est rouge, il indique donc un passage de l’état Normal à l’état Critical :

     Screen Shot 2018-12-19 at 14.59.21.png

      

    Dans la partie « Alerts », une alerte nommée « Link went down », avec les types d’actions entreprises. Dans notre cas, comme définit dans le script : 1 changement d’alerte, 2 actions CLI, et 1 action de création de log :

     Screen Shot 2018-12-19 at 14.59.13.png

     

    Si on clique sur « Details » de l’alerte, alors nous obtenons toutes les informations relatives à cette dernière, avec une description complète de ces éléments, mais également le statut des actions et commandes CLI passées:

     

    Screen Shot 2018-12-19 at 14.59.27.png

     

    Et si on clique sur un « output » en face d’une commande, nous obtenons tout simplement le résultat de cette dernière. Dans notre cas :

     Screen Shot 2018-12-19 at 14.59.59.png

    Si nous réactivons l’interface, alors le statut revient à « Normal », avec une barre d’alerte l’indiquant.

     

    Screen Shot 2018-12-19 at 15.00.07.png

      

    De la même façon que pour le passage en mode Critical, nous avons une alerte générée, avec les actions réalisées :

     Screen Shot 2018-12-19 at 15.00.16.png

     

    2. Optimisation du script

     

    Modifions maintenant notre script, en incluant la notion de « clear_actions » :

     

    self.r1 = Rule('Interface Status changed')
    self.r1.condition('transition {} from "up" to "down"', [self.m1])
    self.r1.action(self.action_interface_down)
    self.r1.clear_condition('transition {} from "down" to "up"', [self.m1])
    self.r1.clear_action(self.action_interface_up)

    Si nous refaisons la même action de faire un shutdown sur l’interface, alors nous obtenons cette nouvelle alerte :

     
    Screen Shot 2018-12-19 at 15.00.23.png

    Et si nous la réactivons :
    Screen Shot 2018-12-19 at 15.00.31.png

      

    Nous venons de voir très simplement que nous pouvons simplifier et optimiser facilement notre script en évitant de multiplier les règles de monitoring.

     

    Maintenant, passons sur une action de modification automatique de la configuration. Pour cela, nous souhaitons que le script tente de réactiver l’interface de manière automatique dès que cette dernière est détectée comme « down ». Cela peut alors permettre d’optimiser les temps de recouvrement en cas de modification de la configuration de manière involontaire ou en cas d’erreur humaine.

    Pour cela, modifions la fonction d’action de la manière suivante :

     

    ActionCLI("show lldp configuration {}", [self.params['interface_id']])
    ActionCLI("show interface {} extended",[self.params['interface_id']])
    ActionCLI("config
    interface 1/1/1
    no shutdown
    exit
    exit",[self.params['interface_id']], title=Title("No shutdown command on the interface"))
     

    Notre ajout ici permet, comme si nous étions en CLI, d'aller dans le contexte de l'interface définie en tant que paramètre, et de faire un "no shutdown". Un titre, optionnel, est également positionné, afin de donner à cette commande, dans la fenêtre "Details" de l'alerte, une identification plus simple.

     

    Une fois le script mis a jour et uploadé, on désactive l’interface.

    Une alerte est alors générée, avec cette fois ci 3 actions, au lieu des 2 initiales :

     

    Screen Shot 2018-12-19 at 15.00.37.png

     

    Si on regarde de plus prêt, en cliquant sur « Details », on peut voir que notre nouvelle commande a été passée avec succès, et on peut même voir le contenu de la commande :

     Screen Shot 2018-12-19 at 15.02.24.png

     

    Screen Shot 2018-12-19 at 15.02.36.png

     

    Mais ce n’est pas tout. Si on retourne sur le graphe, on peut voir que le statut de l’interface est automatiquement remonté, après quelques secondes.

    Screen Shot 2018-12-19 at 15.00.54.png

     

    Cela est confirmé par les alertes, puisqu’une nouvelle alerte est générée 30 secondes après, sans que l’administrateur n’ait eu a intervenir :

    Screen Shot 2018-12-19 at 15.01.39.png

     

     3. Eléments complémentaires

     

    Comme vous pouvez le voir sur la page "Analytics" de la WebUI de votre équipement, plusieurs widgets sont disponibles. Ces widgets permettent d'accéder rapidement à l'information relative à un ou des agent(s) important(s).

    Screen Shot 2018-12-19 at 15.03.15.png

     

    Afin d'ajouter un widget, il suffit tout simplement, sur la partie "Agents" de cliquer le symbole "+" situé à côté de votre agent.Screen Shot 2018-12-19 at 15.03.08.png

     

    Enfin, sur le dashboard de la WebUI, vous disposez également d'un widget relatif au Network Analytics Engine. Il permet de pouvoir disposer rapidement de nombreuses informations sur l'état de l'outil.

    Screen Shot 2018-12-19 at 15.03.24.png

     

    En cas de problèmes sur le code Python, alors une alerte apparaît en face du script récemment importé :

    Screen Shot 2018-12-19 at 15.11.59.png

     

     

     

     



  • 2.  RE: ArubaOS-CX et l'automatisation - Part 4.2 : Gestion des scripts et agents du NAE

    Posted Jun 26, 2019 04:59 PM

    Bonjour à tous,

     

    Jusqu'à maintenant, lorsque des modifications devaient être apportées à un script, il était obligatoire de :

    - supprimer le ou les agents relatifs à ce script

    - le script lui-même

    - reuploader le script

    - recréer le ou les agents

    Cette tâche pouvait devenir fastidieuse, surtout lorsque c'était juste pour faire un toute petite modification...

     

    Avec l'arrivée de la version 10.03 d'ArubaOS-CX, il est possible d'upgrader un script existant, et ces agents, à la volée, sans avoir à faire des manipulations de suppressions au préalable.

     

    Pour se faire, le numéro de version, qui est présent dans la partie "Manifest" de votre script, n'est plus pris en compte dans le nom donné : 

    Screenshot 2019-06-26 at 22.47.05.png

     

    Ainsi, si un script uploadé possède le même nom, dans le Manifest, qu'un script existant ("Script Name" dans la WebUI de NAE), alors il est indiqué à l'utilisateur qu'un script existe déjà, et que le script existant sera alors mis à jour si l'utilisateur souhaite continuer le process :

     

    Screenshot 2019-06-26 at 19.13.01.png

     

    Un temps très important est alors gagné.

     

    Globalement, c'est AOS-CX qui gèrent, de manière transparente, la suppression des agents et scripts, tout en conservant les données de monitoring et d'analytics.

    Cependant, les paramètres seront de nouveau ceux par défaut.

     

    De fait, l'API NAE_Script possède supporte maintenant la méthode PUT : Screenshot 2019-06-26 at 22.50.01.png

     

    Enjoy !!!