Syndiquer le contenu
Mis à jour : il y a 21 heures 8 min

Travailler avec des expressions rationnelles

8 février, 2016 - 08:55

Les expressions rationnelles sont un outil d'analyse de texte par un ordinateur. Elles permettent de décrire des enchaînements de caractères d'une complexité suffisamment grande pour être réellement utiles mais suffisamment faible pour être implémentées efficacement. Elles sont d'une importance capitale pour le théoricien des langages comme pour l'UNIX power-user.

Dans cette dépêche, nous :

  • décrivons brièvement la notion abstraite d'expression rationnelle et recensons les implémentations les plus courantes sur un système Unix ;
  • présentons quelques commandes permettant de rechercher des motifs décrits par une expression rationnelle dans un texte, réécrire des fichiers automatiquement ou transformer et analyser des fichiers structurés automatiquement en utilisant des expressions rationnelles ;
  • montrons comment améliorer votre productivité avec Emacs grâce aux expressions rationnelles.

Dans cette dépêche, nous allons nous pencher sur les expressions rationnelles (souvent nommées abusivement expressions régulières suite à une traduction littérale de regular expression). Elles permettent de représenter formellement un motif de recherche, par exemple : 1 caractère alphabétique majuscule suivi de 4 caractères minuscules, puis 2 chiffres, 1 point à la fin. Les expressions rationnelles représentent un outil puissant pour qui sait les utiliser à bon escient mais nécessitent une phase d'apprentissage non négligeable. La diversité des moteurs et des syntaxes n'aide pas non plus à leur simplicité, et les confusions entre les différents outils peuvent parfois donner des résultats surprenants.

    Sommaire

    Source: original en VO XKCD, traduction en VF

    Description abstraite et implémentations principales

    Les expressions rationnelles sont souvent utilisées comme brique de l'analyse des textes, pour faire de l'analyse lexicale. Elles sont issues des théories mathématiques des langages formels.

    Le concept ayant montré sa pertinence, il faut faire face à une richesse des implémentations : POSIX, puis chaque Unix à sa version, GNU, FreeBSD, puis Perl et Emacs pour les plus répandues. Certaines apportent des extensions (sucre syntaxique +, répétitions, groupes, et backtracking).

    Wikipédia fournit divers exemples illustratifs. Pour citer quelques exemples variés ici :

    • recherche de motif avec grep pour avoir un filtre pour sélectionner des lignes, pour identifier des fichiers, pour sélectionner des logs à une certaine date ou pour rechercher dans les pages de manuel, etc.
    • avec sed, transformation de logs en format Apache en format tabulaire, transformation de la sortie de docker ps, etc.
    • dans Emacs, mettre en valeur un motif dans du code pour une revue ou pour l'édition, extraire des listes d'un fichier avec re-search, etc.
    Les expressions rationnelles Posix basiques

    Les Expressions Rationelles Posix génèrent des machines à état fini déterministe. Elle ne sont ainsi pas capables de faire des retours en arrière.

    La commande grep

    Le premier usage des expressions rationnelles pour les utilisateurs de systèmes basés sur Linux ou Unix est en général la commande grep, qui permet de trouver toutes les lignes correspondant à une expression rationnelle. La syntaxe de la commande grep est simplement :

    grep <options> <expression rationnelle> <liste de fichiers>

    Pour les exemples ci-dessous, nous ferons des recherches dans le fichier french d'une Debian stable (paquet wfrench qui amène le fichier /usr/share/dict/french, informations de licence), ce fichier contenant la liste des mots de la langue française à raison d'un mot par ligne

    Dans une expression rationnelle, la première règle est que chaque caractère représente lui-même, par exemple l'expression rationnelle « rationnelles » correspond à « toute ligne contenant un r, suivi d'un a, suivi d'un t, suivi d'un i, suivi d'un o, suivi d'un n, suivi d'un autre n, suivi d'un e, suivi d'un l, suivi d'un autre l, suivi d'un e, suivi d'un s » :

    Chaque caractère ne représente pas vraiment lui-même, il existe des exceptions avec des méta-caractères qui décrivent autre chose qu'eux-mêmes. Un des plus utilisés de ces méta-caractères est le point, qui signifie « un caractère quelconque », par exemple l'expression rationnelle « rationnelle. » correspond à « toute ligne contenant un r, suivi d'un a, suivi d'un t, suivi d'un i, suivi d'un o, suivi d'un n, suivi d'un autre n, suivi d'un e, suivi d'un l, suivi d'un autre l, suivi d'un e, suivi d'un caractère quelconque » :

    Le problème des métacaractères est qu'on peut vouloir chercher du texte les contenant, par exemple dans notre dictionnaire il y a des abréviations terminant par un point. Pour qu'un métacaractère ne soit pas interprété, il faut le précéder d'un « \ », par exemple « \. » représente le caractère point. On peut alors s'amuser à chercher les abréviations d'au moins six caractères, en les décrivant comme « un caractère quelconque, suivi d'un autre caractère quelconque, suivi d'un troisième caractère quelconque, suivi d'un quatrième caractère quelconque, suivi d'un cinquième caractère quelconque, suivi d'un sixième caractère quelconque, suivi d'un point » :

    On remarquera que le point lui-même est un caractère quelconque.

    Un autre métacaractère utile est le crochet, qui permet de décrire un caractère pouvant correspondre à plusieurs valeurs, par exemple une voyelle non accentuée peut être représentée par « [aeiouy] » (qu'on peut lire comme « n'importe quel caractère étant soit un a, soit un e, soit un i, soit un u, soit un y »). Par exemple si vous voulez briller en société en citant des mots comportant 6 voyelles non accentuées à la suite :

    Deux métacaractères particuliers sont utiles entre crochets :

    • le tiret situé entre deux caractères permet de définir une liste de caractères qui se suivent, par exemple « [a-f] » définit « soit un a, soit un b, soit un c, soit un d, soit un e, soit un f »
    • l'accent circonflexe situé au début permet de définir une exclusion de caractères, par exemple « [^aeiouy] définit « un quelconque caractère qui ne soit ni un a, ni un e, ni un i, ni o, ni un u, ni un y ») Ces deux métacaractères sont cumulables, par exemple « [^a-z] » définit « un quelconque caractère qui ne soit pas une lettre », ce qui peut nous permettre de trouver tous les mots qui ont à la suite deux caractères qui ne sont pas des lettres :

    On peut économiser les copier/coller lorsque l'on veut chercher plusieurs fois la même information, en utilisant le symbole « \{min,max\} » qui permet d'indiquer que l'on cherche la présence d'un caractère successivement entre min et max fois, par exemple si vous cherchez les mots contenant deux « q » séparés par 5 à 7 lettres [1] :

    Il est possible avec certaines versions de grep de spécifier un seul chiffre entre accolades :

    • si on cherche exactement X occurrences on indique : « \{x\} »
    • si on cherche de 0 à X occurrences on indique : « \{,x\} »
    • si on cherche au moins X occurrences on indique : « \{x,\} » Ainsi, on pourrait donc abréger la recherche des mots contenant 6 voyelles non accentuées ainsi :

    Si on veut répéter plusieurs caractères au lieu d'un seul, il faut encadrer la recherche avec des « \( \) », Par exemple si vous bloquez dans une grille de mots croisés sur la définition « mot contenant 7 fois à la suite une consonne suivie d'une voyelle » :

    Le contenu trouvé à partir d'une expression entre parenthèses est dit « capturé », cela signifie qu'il est gardé en mémoire et peut être réutilisé dans l'expression rationnelle. La contenu capturé est accessible en utilisant « \1 », « \2 », « \3 », etc. (en général on ne peut pas dépasser \9). Le numéro de capture est défini en comptant le nombre de parenthèses ouvrantes précédant l'expression capturée. Cela permet par exemple de lister les mots contenant un palindrome de 4 lettres :

    On peut encore affiner les recherches en utilisant les ancres, qui permettent de situer où se situe une expression rationnelle dans la ligne :

    • le dollar, lorsqu'il est situé à la fin de l'expression rationnelle, représente la fin de la ligne
    • l'accent circonflexe, lorsqu'il est situé au début de l'expression rationnelle, représente le début de la ligne

    On peut cumuler les deux ancres dans la même expression, par exemple si on veut chercher les vrais palindromes de 4 lettres :

    Pour en terminer avec les expressions rationnelles Posix basiques, il ne reste plus qu'un métacaractère à présenter, qui est l’astérisque. Ce caractère est équivalent à « {0,} ».

    Utiliser dans vi

    VimRegex détaille largement le sujet.

    Extension des expressions rationnelles

    Les extensions rationnelles basiques étant peu lisibles, la norme Posix a évolué pour intégrer les expressions rationnelles étendues, aussi appelées « ERE ».

    grep est mieux avec -E

    Les versions récentes de grep permettent d'utiliser les expressions rationnelles étendues avec l'option -E. Si vous ajoutez l'option -E à grep, vous devez modifier votre expression rationnelle ainsi :

    • \{ et \} deviennent { et }
    • \( et \) deviennent ( et )
    • tous les autres métacaractères (« . », « [ », «  ] », « - », « ^ », « $ », « * », « \1 », etc.) sont inchangés

    Outre cette suppression des « \ » superflus, les ERE apportent trois nouveaux métacaractères. Le premier est « ? » qui est un synonyme de « {0,1} », qui permet par exemple de chercher les palindromes de 4 ou 6 lettres avec une seule expression :

    On dispose aussi de « + » qui est un synonyme de {1,}

    Enfin le dernier métacaractère spécifique aux ERE est le « | » qui permet de séparer plusieurs options :

    Les classes de caractères

    Posix prévoit des classes de caractère, qui sont des notations spécifiques entre crochets. À noter que les classes de caractères sont aussi bien gérées par les expressions rationnelles basiques que étendues (il n'y a donc pas besoin d'utiliser l'option -E pour en bénéficier), mais il existe des implémentations d'expressions rationnelles basiques non compatibles Posix qui ne les acceptent pas.

    Les classes de caractères sont des mots ou abréviations en anglais désignant ce à quoi ils correspondent et encadrés par « [: :] ».

    • [:digit:] : désigne un chiffre décimal (équivalent à [0-9])
    • [:lower:] : désigne une lettre minuscule (équivalent à [a-z])
    • [:upper:] : désigne une lettre majuscule (équivalent à [A-Z])
    • [:alpha:] : désigne une lettre minuscule ou majuscule (équivalent à [A-Za-z])
    • [:alnum:] : désigne une lettre minuscule ou majuscule ou un chiffre (équivalent à [A-Za-z0-9])
    • [:xdigit:] : désigne un chiffre hexadécimal (équivalent à [a-fA-F0-9])
    • [:space:] : désigne un caractère d'espacement (espace, tabulation, retour chariot, etc.)
    • [:blank:] : désigne un espace ou une tabulation horizontale (à ne pas confondre avec [:space:])
    • [:punct:] : désigne à un crochet ou un caractère de la classe suivante : ['!"#$%&()*+,./:;<=>?@^_`{|}~-]
    • [:cntrl:] : désigne un Caractère de contrôle
    • [:print:] : désigne un caractère affichable (ainsi qu'une espace), cette classe est à peu près le contraire de [:cntrl:]
    • [:graph:]: désigne l'ensemble des caractères visibles sauf les espaces, les caractères de contrôle, etc. Équivalent à [\x21-\x7E].
    Pour aller plus loin Attention au GLOB

    Dans les exemples précédents, il était important d'utiliser de simples apostrophes pour éviter l'interprétation de caractères spéciaux par le shell.

    Outils pour tester vos expressions rationnelles

    Plusieurs outils s'offrent à vous pour tester et triturer dans tous les sens vos expressions rationnelles comme par exemple le site Regexpal qui propose notamment de la coloration syntaxique et se veut "temps réel" dans les modifications, ou regex101 permet de tester des expressions rationnelles Python, javascript ou pcre.

    Ne pas toujours utiliser les expressions rationnelles

    Les expressions rationnelles ne sont par exemple pas l'outil idéal pour analyser du XML ou de l'HTML.

    Jouer avec les expressions rationnelles

    Voir la dépêche Regexcrossword : un subtil mélange de sudoku et de mots croisés, à la sauce Regex, ainsi que la chasse au trésor du MIT en 2014, etc.

    Un peu de théorie Les automates finis

    La base théorique des expressions rationnelles se trouve dans la théorie des langages. Notamment elles permettent de décrire les langages rationnels. Elles sont fortement liées aux automates finis.

    Pour illustrer le parallèle nous allons utiliser les caractères et les quantificateurs de base :

    • a qui permet de reconnaitre la lettre a ;
    • ? qui permet de définir un groupe optionnel ;
    • * qui permet de définir un groupe se répétant zéro fois ou plus ;
    • + qui permet de définir un groupe se répétant une fois ou plus.
    Littérature

    [1] avec ça vous allez vraiment briller en société, il faudra juste trouver un moyen d'intégrer ça dans la conversation

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Un système d’exploitation français pour la souveraineté numérique

    7 février, 2016 - 15:48

    C’est passé à l’Assemblée nationale française (en attendant le Sénat), au sein d’un texte comportant plusieurs volets : l’État français veut se doter d’un système d’exploitation afin d’obtenir une certaine souveraineté numérique. Le texte vise à la production d’un rapport envisageant la « possibilité créer un Commissariat à la souveraineté numérique » et précisant « les conditions de mise en place, sous l’égide de ce commissariat, d’un système d’exploitation souverain » (article 16 ter dans la version adoptée à l’Assemblée nationale).
    Si le sujet suscite des critiques, la France n’est pas le seul pays à vouloir en quelque sorte protéger sa souveraineté numérique. Il y a des précédents, tous basés sur GNU/Linux. Tour d’horizon en seconde partie.

    Des précédents en France

    Déjà l’année dernière, on avait assisté à la création d’un Institut pour la souveraineté numérique. Le Conseil national du numérique, lors d’une de ses sessions de travail, avait abordé cette thématique. Même si la tentation est forte de dire que GNU/Linux serait la solution, ce n’est pas si évident.

    L’opérateur télécom Orange avait déjà envisagé d’avoir son propre système d’exploitation en 2010 (et avait sorti sa tablette Tabbee sous GNU/Linux). Et le ministre français de l’Économie, du Redressement productif et du Numérique, Arnaud Montebourg, avait déjà évoqué un système d’exploitation bleu, blanc, rouge en 2014 (en se basant sur le concept de « résogiciel français » du président de Skyrock, Pierre Bellanger).

    Ajoutons qu’il existe déjà un système « souverain » CLIP, basé sur GNU/Linux et développé par l’ANSSI depuis 2005, pour les opérateurs d’importance vitale (OIV), prévu pour des cas d’usage spécifiques et pas pour une utilisation par le grand public ou les administrations en général. Il est « en phase préliminaire de déploiement ».

    Des précédents dans d’autres pays

    D’autres pays ont déjà créé des distributions pour garantir leur indépendance. En Espagne, l’Andalousie produit GuadaLinex et l’Argentine propose Huayra (ces deux distributions sont basées sur Debian). L’article de ZDNet cite aussi la Chine, l’Inde, le Brésil et la Turquie.

    On notera que tout le monde semble avoir opté pour une base GNU/Linux. Est‐ce que la souveraineté numérique peut exister en dehors de Linux ? C’est le sujet de la dissertation à laquelle vous allez participer par vos commentaires.

    Et des critiques de toute part

    Le Monde rappelle que « La secrétaire d’État au numérique “ne croit pas à la possibilité d’un système d’exploitation souverain, qui serait peu opérant” » et des députés de la majorité et de l’opposition l’ont qualifié d’« erreur » et de « ridicule ». Et le directeur général de l’ANSSI l’a qualifié de « non‐sens » et refuser l’idée d’un système noyauté (« plein de saletés ») pour les services de renseignement.

    Les critiques sont nombreuses : travail gigantesque, coût exhorbitant, usine à gaz en préparation, lubie du made in France, fiascos précédents dans le secteur éducatif français et du « cloud souverain », railleries multiples via Twitter.

    En tout cas le projet de loi « Économie : pour une République numérique » a permis d’évoquer largement les logiciels libres au sein de l’Hémicycle.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Firefox 44 débarque

    7 février, 2016 - 11:32

    Firefox 44 a débarqué le 26 janvier 2016 (NdA : 44, débarquer, toussa…). Nous proposons dans cette dépêche les nouveautés pour les versions de bureau et mobile, ainsi que pour les développeurs.

    NdA : nous avons toujours besoin de toute aide afin de publier régulièrement les dépêches liées aux sorties de Firefox, rendez-vous sur l’espace de rédaction collaborative de LinuxFr.org (linuxfr.org/redaction).

    Sommaire Firefox bureau

    Commençons par ce qui ne change finalement pas : depuis la version précédente, seules les extensions signées par Mozilla sont acceptées par le navigateur. Ce comportement peut toutefois être désactivé à l’aide d’un réglage du navigateur qui devait disparaître avec la présente version. La suppression de ce réglage est repoussée.

    NB : La décision de n’accepter que les extensions signées dans Firefox, pour des raisons de sécurité selon Mozilla, fait débat parmi les utilisateurs de Firefox, et ce jusque dans les rangs de la distribution GNU/Linux Fedora. Elle a été temporairement désactivée dans le paquet.

    Quelques améliorations :

    • amélioration de la page d’avertissement dans les cas d’erreurs de certificats et de connexions non certifiées ;
    • lecture des vidéos avec le codec H.264 sous GNU/Linux lorsque FFmpeg est disponible ;
    • lecture des vidéos en WebM/VP9 sur les systèmes d’exploitation qui n’intègrent pas le MP4/H.264 ;
    • dans la chronologie de l’inspecteur d’animation, l’icône éclair à côté des animations tourne dans la partie compositeur ;
    • pour les connexions HTTPS seulement, les données peuvent être compressé avec la bibliothèque Brotli. Ce format de compression est en cours de normalisation au sein de l’IETF (plus d’informations) ;
    • les commandes de capture d’écran permettent le choix du rapport d’aspect de pixel dans les outils développeurs ;
    • la gestion des fontes web sous Linux utilise désormais le même code que sur les autres plates‐formes ;
    • utilisation d’une signature électronique SHA-256 pour les versions destinées à Windows afin de suivre les nouvelles recommandations pour les signatures ;
    • validation plus stricte des polices web ;
    • désactivation du clavier à l’écran pour Windows 8 et Windows 8.1.
    Firefox Mobile

    Quelques améliorations :

    • Les utilisateurs peuvent maintenant choisir une page d’accueil à afficher au démarrage au lieu du panneau Top Sites ;
    • Ajout de la prise en charge des URI avec le protocole mms: ;
    • Page des comptes Firefox basée sur le web ;
    • Montrer les suggestions d’historique de recherche ;
    • Demander aux utilisateurs avant d’ouvrir une URI d’Intent dans un onglet de navigation privée ;
    • Onglets améliorés sur les téléphones ;
    • Utilisation du service d’impression Android pour la possibilité d’impression dans le cloud.
    Changements commun au bureau et Android Améliorations pour les développeurs

    Au menu :

    • un clic droit sur un objet journalisé dans la console permet de le stocker comme une variable globale sur la page ;
    • nouvel outil de mémoire pour inspecter le tas ;
    • API pour les Services Workers ;
    • lecteur de JSON intégré pour voir, rechercher, copier et sauver intuitivement les données sans extensions ;
    • sauter aux définitions de fonctions dans le débogueur avec Cmd-Clic ;
    • extension et API de débogage des WebSockets ;
    • la vue des règles montre désormais les styles en utilisant le texte de leur auteur, et les éditions dans la vue des règles sont désormais liées à l’éditeur de style ;
    • obligation des signatures d’extensions.

    Outils visuels pour Animation :

    • visualiser et éditer les règles d’animations CSS keyframes directement depuis l’inspecteur ;
    • modifier visuellement les courbes cubic-bezier qui dirigent la manière dont les animations progressent à travers le temps ;
    • découvrir et inspecter les animations CSS et les transitions jouées dans la page ;
    • pour en savoir plus, rendez‐vous sur http://devtoolschallenger.com/.

    Outils visuels pour les mises en forme et les styles :

    • montrer les règles dans la vue (?) pour vérifier la taille et la position et utiliser l’outil de mesure pour facilement détecter les problèmes d’espacement et d’alignement ;
    • utiliser les filtres CSS pour prévisualiser et créer des effets temps réel comme les drop-shadows, sépia, etc. ;
    • en apprendre plus : http://devtoolschallenger.com/.
    Prochaines versions Firefox 46

    Poursuite de la mise en avant des connexions HTTPS : si vous entrez un couple identifiant/mots de passe sans passer par TLS, Firefox 46 affiche une alerte (voir la page informative anglophone).
    [Crédit NextInpact]

    Firefox 46 acceptera les préfixes webkit (bug 1213126). On ne dira pas merci aux webmestres qui ne se préoccupent que des iPhones et nuisent à l’interopérabilité (Microsoft avec Edge a dû faire les mêmes concessions).

    Firefox 48 et suivants

    Les WebExtensions vont descendre progressivement dans Firefox, à partir de la version 45 et avec la version 48 pour objectif (vous pouvez suivre l’avancement du projet). Rappelons qu’elles sont déjà à l’honneur dans Firefox OS 2.5.

    Mozilla travaille à l’intégration de l’API Web Speech, logiquement l’approche est un peu moins centralisée que dans Chrome (voir la traduction du billet).

    WebGL 2 arrive dans Firefox Nigtly, faites chauffer vos GPU ;-)

    La navigation classique pourrait bénéficier de la même option de protection contre le traçage que celle introduite dans la version 42 au sein de la navigation privée, voir bug 1231359 et bug 1231373.

    Firefox (Bureau et Android) permettait de lancer des pseudo-applications qui s'appuient sur Firefox pour fonctionner, ce mode WebRT pourrait être retiré. Avec le retrait de Firefox OS du monde des ordiphones, c'est l'idée que le HTML pourrait servir de base à tout programme qui est moins promue chez Mozilla.

    Pendant ce temps là, chez Mozilla…

    La feuille de route de Servo a été mise à jour en ce début d’année. Il se dit par ailleurs dans les milieux autorisés que le maintien de la prise en charge de Windows XP par Firefox repousse l’intégration de morceaux de Servo dans ce dernier (processus nommé Oxidation), « vu que le support de Windows XP par Rust n’est pas complet ».

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Présentation technique de Canopsis

    7 février, 2016 - 10:41

    Supervision et visualisation des données : des domaines de l'informatique qui nous permettent de surveiller, analyser une infra, des données afin de comprendre et éventuellement prédire des dysfonctionnements.

    De nombreux outils existent et excellent dans chacune de ces tâches. Les accorder ensemble afin d'unifier l'information permet ainsi de faciliter la prise de décision.

    C'est ce que l'on appelle l'hypervision.

    Canopsis se veut une solution d'hypervision (on évite l'appellation hyperviseur qui reste dans le langage courant spécifique à la virtualisation). Solution open-source sous licence AGPL3 développée par la société française Capensis, elle se veut simple d'utilisation, et suffisamment souple pour répondre à un maximum de besoin.

    Sommaire La problématique

    Dans une infra hétérogène, on dispose de nombreuses sources d'information :

    • côté supervision, on peut avoir un mélange de :
      • Nagios/Icinga
      • Centreon
      • Shinken
      • HPOV
      • Zabbix
      • SNMP
    • côté récolte de données, on peut avoir :
      • CollectD
      • Logstash
      • Munin
      • Telegraf (de la pile TICK)
    • ou encore :
      • des logs
      • des données stockées en base de données
      • un résultat de tests unitaires et fonctionnels (jMeter, Sikuli…)

    La mise en place d'un accès à l'ensemble de ces informations peut être fastidieuse, et dans la plupart des cas, l'utilisateur (l'administrateur technique et/ou fonctionnel) devra accéder à plusieurs interfaces et maîtriser plusieurs outils.

    Cela empêche d'avoir une vue d'ensemble cohérente et rend difficile l'anticipation ainsi que la prise de décision.

    Objectif : la solution

    C'est là que Canopsis intervient.

    Étape 1 : les connecteurs

    Dans un premier temps, nous devons récupérer les informations produites par cet ensemble hétérogène.

    Ainsi, pour chaque source de données, nous sommes en mesure de développer un connecteur, capable d'extraire les informations voulues, et de les transmettre à Canopsis sous la forme d'événements standardisés.

    Un certain nombre de connecteurs sont déjà disponibles sur le Gitlab.

    Le cas le plus simple est donc celui ci :

    #!/usr/bin/env python from time import time # lib qui nous permet de nous connecter au bus de données (cf étape 2) from kombu import Connection # module qui sera utilisé pour envoyer les événements from kombu.pools import producers # construction de l'événement selon le standard Canopsis event = { "timestamp": int(time()), # émetteur de l'événement "connector": "myconnector", "connector_name": "myconnector-instance0", # nature de l'événement "event_type": "check", # source de l'événement "source_type": "resource", "component": "<hostname>", "resource": "<job's name>", # données portées par l'événement "state": 0, # 0 = INFO, 1 = MINOR, 2 = MAJOR, 3 = CRITICAL "output": "<message>" } # construction de la routing_key, qui sert à identifier l'événement et à le router routing_key = "{0}.{1}.{2}.{3}.{4}".format( event['connector'], event['connector_name'], event['event_type'], event['source_type'], event['component'] ) if event['source_type'] == "resource": routing_key = "{0}.{1}".format( routing_key, event['resource'] ) # Connexion uri = 'amqp://cpsrabbit:canopsis@localhost:5672/canopsis' with Connection(uri) as conn: # Création de l'émetteur with producers[conn].acquire(block=True) as producer: # Publication producer.publish( event, serializer='json', exchange='canopsis.events', routing_key=routing_key )

    Bien évidemment, du moment qu'un connecteur envoie ses événements, il peut être développé dans n'importe quel langage, c'est le cas du connecteur Nagios qui se présente comme un Nagios Event Broker, et est donc développé en C.

    Étape 2 : le bus de données et les moteurs

    Les événements produits par les connecteurs sont transmis au bus de données de Canopsis, basé sur RabbitMQ.

    Source : http://igm.univ-mlv.fr/~dr/XPOSE2011/rabbitmq/usages.html

    Ces événements vont être consommés par des daemons que nous appelons moteurs.

    Leur but est simple :

    • traiter la donnée
    • enregistrer les informations pertinentes en base de données
    • transmettre, si nécessaire, l'événement à un ou plusieurs autres moteurs

    Nous avons, par exemple :

    • le moteur event_filter qui se charge de filtrer/modifier les événements entrants
    • le moteur context qui se charge d'enregistrer les informations sur l'entité cible de l'événement (connecteur source, composant/ressource qui a produit l'événement…)
    • le moteur perfdata qui s'occupe d'historiser les données de performance (comme remontées par Nagios ou CollectD)

    Comme pour les connecteurs, les moteurs peuvent être développés dans n'importe quel langage, bien que pour le moment nous les avons tous faits en Python.

    Étant un daemon, un moteur dispose de 2 fonctions :

    • une pour consommer les événements (dans un thread à part)
    • une pour exécuter une tâche régulièrement (recharger la configuration, envoyer des stats…)

    Ainsi que la configuration suivante :

    [engine:myengine] # chemin Python de la méthode de consommation event_processing=canopsis.myfeature.process.event_processing # chemin Python de la méthode exécutée régulièrement beat_processing=canopsis.myfeature.process.beat_processing # nom de l'exchange AMQP sur lequel écouter (par défaut: amq.direct) exchange_name=canopsis.event # RK à consommer routing_keys=nagios.#,shinken.# # intervalle entre 2 exécutions du beat_processing (en secondes) beat_interval=60 # liste des moteurs sur lesquels retransmettre l'événement reçu, possiblement modifié (par défaut: aucun) next=myengine2,myengine3

    Et donc l'implémentation se résume à :

    def event_processing(engine, event, **_): # traiter l'événement return event def beat_processing(engine, **_): # faire des choses Étape 3 : les schémas

    Toutes les données qui véhiculent dans le bus et qui sont sauvegardées en base sont munies de schémas les décrivant.

    Ces schémas servent à plusieurs choses :

    • valider que la donnée est bien formatée
    • décrire comment la donnée sera représentée
    • décrire comment la donnée sera éditée

    Ces deux derniers points permettent de générer une partie du code de l'UI (cf étape 5).

    À terme, ils serviront également à :

    • décrire comment la donnée sera utilisée
    • décrire comment la donnée pourra être transformée

    Ce qui permettra de générer une partie du code backend (cf étape 4).

    Le formalisme qui permet d'écrire un schéma est actuellement inspiré du standard JSON Schema :

    { "title": "MyData", "description": "Schéma décrivant la donnée, comment l'afficher et l'éditer" // description de la donnée "type": "object", "properties": { "color": { "type": "string", "required": true, /* comment la donnée sera affichée/éditée * le rôle 'color' : * - affichera un carré de couleur lorsqu'on l'affichera * - affichera un colorpicker lorsqu'on l'éditera */ "role": "color", // les champs suivants servent pour le formulaire "title": "Couleur de la donnée", "description": "Tooltip d'aide" } }, // les champs suivants aident à générer le formulaire d'édition "categories": [ { "title": "General", "keys": ["color"] } ] }

    L'id d'un schéma est construit de la manière suivante :

    • mydata
    • mydata.mydata2 : ici mydata2 hérite de mydata

    On obtient donc en base de données :

    { "_id": "<id du schema>", "schema": // le schéma à proprement parler } Étape 4 : gérer et servir la donnée

    Maintenant que nous avons la structure pour récupérer la donnée, et que nous sommes en mesure de la schématiser, il faut mettre en place les mécanismes permettant d'interagir avec et de la servir à l'UI.

    A. Les managers

    La gestion de la donnée est prise en charge par ce que l'on appelle les managers. Pour bien comprendre son rôle, il faut plonger un peu dans le code.

    Un configurable est un objet Python dont les propriétés sont définies par son fichier de configuration :

    from canopsis.configuration.configurable import Configurable from canopsis.configuration.configurable.decorator import conf_paths from canopsis.configuration.configurable.decorator import add_category from canopsis.configuration.model import Parameter CONF_PATH = 'myfeature/manager.conf' # {sys.prefix}/etc/{CONF_PATH} CATEGORY = 'MYFEATURE' # Définition du contenu de la catégorie CONTENT = [ Parameter('foo'), Parameter('bar', parser=int) ] # ajoute un fichier de configuration à lire par le configurable @conf_paths(CONF_PATH) # permet de spécifier la catégorie de configuration depuis laquelle on peut lire les paramètres @add_category(CATEGORY, content=CONTENT) class MyFeatureManager(Configurable): pass

    Ainsi, avec le fichier de configuration suivant :

    [MYFEATURE] foo=bar bar=42

    Ou :

    { "MYFEATURE": { "foo": "bar", "bar": 42 } }

    En effet, le configurable va tester différents drivers, actuellement on dispose de INI et JSON mais il est envisageable d'avoir un driver MongoDB ou autre

    Lorsque l'on instanciera la classe, on obtiendra :

    obj = MyFeatureManager() assert obj.foo == "bar" assert obj.bar == 42

    Et à partir de cette classe Configurable on va définir l'arbre d'héritage suivant :

    Un ConfigurableRegistry permet de spécifier, dans un paramètre de configuration, un autre Configurable à instancier :

    otherconfigurable_value = canopsis.myotherfeature.manager.MyOtherFeatureManager

    Et on y accèdera, dans l'instance, de la manière suivante :

    assert isinstance(self['otherconfigurable'], MyOtherFeatureManager)

    Le MiddlewareRegistry fait de même pour les Middleware (qui identifient un protocole ainsi qu'un type de données) :

    mymiddleware_uri = protocol-datatype-datascope://

    De même que pour le ConfigurableRegistry, on y accède de la manière suivante :

    assert self['mymiddleware'].connected()

    En général, un manager sera un MiddlewareRegistry, ce qui permettra de changer de techno utilisée, sans modifier le code :

    [MYFEATURE] mystorage_uri = mongodb-timed-mydata:// # mystorage_uri = influxdb-timed-mydata:// mymanager_value = canopsis.myotherfeature.manager.MyOtherFeatureManager # mymanager_value = canopsis.myotherfeature.manager2.MyOtherFeatureManager2

    Et ce manager sera utilisé par le moteur et le webservice.

    En reprenant l'exemple du moteur :

    from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager def event_processing(engine, event, manager=None, **_): if manager is None: # instancie la classe une seule fois par module manager = singleton_per_scope(MyFeatureManager) # faire des choses avec l'événement et le manager return event def beat_processing(engine, event, manager=None, **_): if manager is None: manager = singleton_per_scope(MyFeatureManager) # faire des choses avec le manager B. Les webservices

    Afin de servir la donnée à l'UI, on dispose d'une application WSGI découpée en modules, que l'on appelle webservice.

    Ces derniers se trouvent dans le paquet Python canopsis.webcore.services.

    Et grâce au code suivant (à placer dans le __init__.py), on peut avoir plusieurs paquets Python fournissant du code à cet emplacement :

    from pkgutil import extend_path __path__ = extend_path(__path__, __name__)

    Bref, un webservice s'écrit très simplement :

    # couche d'abstraction qui nous permettra de passer de Bottle à Flask from canopsis.common.ws import route from canopsis.common.utils import singleton_per_scope from canopsis.myfeature.manager import MyFeatureManager # Sera appelé par l'application WSGI pour charger les routes HTTP def exports(ws): # ici `ws` désigne donc le webserver manager = singleton_per_scope(MyFeatureManager) # ici on créé la route /foo qui accepte la méthode GET @route(ws.application.get) def foo(): return manager.foo # l'API retournera : # { # "total": 1, # "data": ["bar"], # "success": true # } # cette fois ci, on créé la route /bar/:baz @route(ws.application.get) def bar(baz): return (manager.bar == baz) Étape 5 : l'application web

    Côté backend, on dispose désormais du nécessaire pour fournir à l'UI tout ce dont elle a besoin.
    Ainsi, nous avons également travaillé la modularité de cette UI, basée sur Ember, au maximum.

    A. Les briques

    Afin de répondre à cette problématique de modularité, nous avons mis en place un système de briques, permettant de sélectionner les fonctionnalités effectivement chargées.

    Concrètement, on peut voir une brique comme étant un addon apportant plusieurs fonctionnalités telles que :

    • nouveaux éléments graphiques (composants)
    • nouveaux outils de rendus (widgets, renderers)
    • nouveaux outils d'éditions (éditors)

    Pour construire une brique, il suffit de créer un paquet NPM avec le package.json suivant :

    { "name": "<nom de la brique>", "description": "<description de la brique>", "version": "0.1.0", // il s'agit du fichier principal de la brique, il pointera vers la version de dev ou minifiée "main": "init.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "compile": "rm -Rf tmp/build && broccoli build tmp/build && cp tmp/build . -RT", "lint": "eslint src", "doc": "./node_modules/canopsis-ui-toolbelt/scripts/buildDoc", "minify": "node node_modules/canopsis-ui-toolbelt/scripts/minify.js" }, "repository": { "type": "git", "url": "<url du dépôt>" }, "author": "<auteur>", "license": "AGPL-3.0", "devDependencies": { "broccoli": "^0.16.9", "broccoli-funnel": "^1.0.1", "broccoli-merge-trees": "^1.0.0", "broccoli-sourcemap-concat": "^1.1.6", "broccoli-template": "^0.1.1", "broccoli-uglify-js": "^0.1.3", // outil de gestion des briques Canopsis "canopsis-ui-toolbelt": "https://git.canopsis.net/canopsis/canopsis-ui-toolbelt/repository/archive.tar.gz?ref=<branche git de canopsis-ui-toolbelt>", "jsdoc": "^3.3.0", "pre-commit": "^1.1.1" }, "pre-commit": [ "lint", "doc" ] }

    Puis, dans un dossier src on placera le code source de la brique :

    • components/mycomponent/component.js
    • components/mycomponent/template.hbs
    • renderers/renderer-myrole.hbs
    • editors/editor-myrole.hbs
    • widgets/mywidget/controller.js
    • widgets/mywidget/mywidget.hbs
    • mixins/mymixin.js

    L'outil canopsis-ui-toolbelt se charge de :

    • récupérer récursivement tout le code JS dans le dossier src
    • référencer le code JS dans le fichier init.js qui représente la brique
    • récupérer récursivement tout les templates (*.hbs) dans le dossier src
    • référencer les templates également dans le fichier init.js
    • référencer les templates dans Ember.TEMPLATES :
      • pour un composant, il est requis d'avoir le dossier components/<mycomponent>, afin que le template soit reconnu comme étant un template de composant
      • pour le reste, le nom du template dans Ember sera le nom du fichier sans extension

    NB: Le découpage n'est donc obligatoire que pour les composants, le reste peut être mis en vrac dans src.

    Une fois que l'on a créé tout cela (ou récupéré le dépôt Git), on peut finaliser la brique :

    $ npm install $ npm run compile

    Chaque fichier source contiendra au moins un Ember Initializer :

    Ember.Application.initializer({ name: 'MyModule', after: ['Dependency1', 'Dependency2'], initialize: function(container, application) { var Dependency1 = container.lookupFactory('deptype:dependency1'), Dependency2 = container.lookupFactory('deptype:dependency2'); // do stuff application.register('modtype:mymodule', /* stuff */); } });

    Cela permet ainsi de s'assurer du bon chargement de chaque module.

    Au final, pour installer une brique, il suffit de :

    • cloner le dépôt finalisé dans : /opt/canopsis/var/www/canopsis
    • lancer la commande webmodulemanager enable mybrick afin de l'activer au chargement de l'UI

    L'ensemble des briques existantes (hormis celle par défaut livrées avec Canopsis) sont disponible ici.

    B. Les composants

    Le composant, l'élément le plus basique de l'UI, sera utilisé par tout les autres éléments.
    Il s'agit simplement d'un composant Ember avec un template à fournir.

    On définira notre composant dans src/components/mycomponent/component.js :

    Ember.Application.initializer({ name: 'MyComponent', after: [], initialize: function(container, application) { var MyComponent = Ember.Component.extend({ init: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // on implémente les actions, déclenchable depuis le template foo: function() { alert('bar'); } } }); application.register('component:component-mycomponent', MyComponent); } });

    Et le template dans src/components/mycomponent/template.hbs :

    <h1>My awesome component</h1> <a {{action foo}}>Launch action</a> C. Les renderers/éditeurs

    Une fois nos composants définis, on est en mesure de les utiliser dans des renderers ou des éditeurs.

    Le but de ces éléments est simple :

    • lorsqu'on demande l'affichage d'une donnée avec le composant renderer :
      • le champ role du schéma JSON est également lu
      • si un renderer du même nom est trouvé, il est utilisé dans le template
      • sinon, on affiche la donnée telle quelle
    • lorsqu'un formulaire d'édition est généré à partir du schéma JSON, en utilisant le composant editor :
      • le champ role est lu
      • si un éditeur du même nom est trouvé, il est utilisé dans le formulaire
      • sinon, on utilise l'éditeur par défaut

    Les renderers/éditeurs ne sont donc que de simple templates HTMLBars.

    On aura le renderer dans src/renderers/renderer-myrole.hbs :

    <p>My rendered data: {{value}}</p> {{component-mycomponent}}

    Et l'éditeur dans src/editors/editor-myrole.hbs :

    <p>My data is being edited :</p> {{input type="password" value=attr.value}} {{component-mycomponent}} D. Les widgets

    Enfin, on aura les widgets, qui seront en mesure d'utiliser composants et
    renderers afin d'implémenter des outils de visualisation de données plus complexes.

    Un widget est un MVC complet :

    • on implémente un contrôleur
    • on implémente des mixins qui viendront s'appliquer à la vue
    • on écrit un template

    Ce qui donne :

    Ember.Application.initializer({ name: 'MyWidget', after: ['WidgetFactory'], initialize: function(container, application) { var WidgetFactory = container.lookupFactory('factory:widget'); var widgetOptions = {}; var MyWidgetViewMixin = Ember.Mixin.create({ didInsertElement: function() { this._super.apply(this, arguments); // faire des choses }, willDestroyElement: function() { this._super.apply(this, arguments); // faire des choses }, actions: { // actions de la vue } }); var widget = WidgetFactory('mywidget', { viewMixins: [ MyWidgetViewMixin ], actions: { // actions du contrôleur }, init: function() { // faire des choses }, findItems: function() { // méthode appelée lors de la récupération des données pour le template } }, widgetOptions); application.register('widget:mywidget'); } });

    Ensuite, il est nécessaire de créer un schéma widget.mywidget.json qui sera utilisé pour configurer le widget lors de son ajout dans une vue :

    { "title": "MyWidget", "description": "Schéma de configuration de MyWidget", "metadata": { // icône dans le formulaire d'ajout de widget "icon": "fa fa-cog" }, "categories": [ { "title": "General", "keys": ["foo"] } ], "type": "object", "properties": { "foo": { "title": "Foo", // nom du champ dans le formulaire "description": "Foo field", // tooltip dans le formulaire "type": "string", "role": "myrole" } } } E. Les mixins

    Lorsque l'on a des fonctionnalités communes à plusieurs widgets (comme le PeriodicRefresh qui actualise le widget régulièrement), il convient de factoriser le code en un mixin.

    Ce dernier pourra être ajouté et configuré au widget via l'UI, et ensuite appliquer la-dite configuration au contrôleur du widget :

    Ember.Application.initializer({ name:'MyMixin', after: ['MixinFactory'], initialize: function(container, application) { var Mixin = container.lookupFactory('factory:mixin'); var get = Ember.get; var MyMixin = Mixin('mymixin', { mixinsOptionsReady: function() { this._super.apply(this, arguments); var mixinOptions = get('mixinOptions.mymixin'); // faire des choses } }); application.register('mixin:mymixin', MyMixin); } });

    Et il ne manque plus que le schéma mixin.mymixin.json décrivant la configuration du mixin :

    { "title": "MyMixin", "description": "Schéma de configuration de MyMixin", "metadata": { // description affiché dans l'UI "description": "Add stuff to widget" }, "categories": [ { "title": "General", "keys": ["bar"] } ], "type": "object", "properties": { "bar": { "title": "Bar", "description": "Bar field", "type": "string" } } } F. Les vues

    Tout les outils sont désormais à notre disposition pour construire nos dashboards.

    Donc si on résume :

    • une vue est composée de widgets
    • un widget est composé de composants et de mixins

    L'UI fournit les outils qui permettent de construire ces vues, le résultat final est un document JSON stocké en base :

    { "_id": "id de ma vue", "description": "description de ma vue" "crecord_name": "nom de ma vue", "crecord_type": "view", "author": "<user qui a créé la vue>", "enable": true, "internal": false, "tags": [], // le widget initial de la vue "containerwidget": { // identifiant du widget "xtype": "widgetcontainer", "title": "container title vbox", // le widget "widgetcontainer" s'attend à avoir un champ "items" "items": [ { // le widget "widgetwrapper" sert à inclure des widgets dans un container pour les placer correctement "xtype": "widgetwrapper", "title": "wrapper", // le widget encapsulé : "widget": { "xtype": "mywidget", "title": "My awesome widget", // configuration spécifique au widget "foo": "bar", // mixins appliqués via l'UI : "mixins": [ { "name": "periodicrefresh", // paramètres du mixin "refreshInterval": 60 }, { "name": "mymixin", // paramètres du mixin "bar": "baz" } ] } } ], // le container de base de la vue à un widget de layout par défaut "mixins": [ { "name": "lightlayout" } ] } }

    La totalité de l'UI est générée à partir de ces vues JSON, et est donc complètement personnalisable.

    Le bac à événements

    Parmi les vues par défaut qui sont livrées avec Canopsis, on trouve le Bac à événements.

    Cette vue fournit un dashboard de supervision commun, unifiant ainsi la totalité des superviseurs remontant des informations à Canopsis.

    Depuis ce bac, on voit apparaître les différentes alarmes avec comme informations :

    • leurs sources d'émission (le connecteur)
    • leurs sources cible (composant/ressource, qui dans la plupart des cas correspond au couple host/service)
    • le dernier message associé à un check (Nagios, Shinken, Centreon, …)
    • le statut de l'alarme associé au check :
      • Off : aucune alarme n'est présente
      • On Going : un problème a été remonté et n'est toujours pas résolu
      • Stealthy : une alarme a été remontée et est immédiatement repassée OK (durée paramétrable)
      • Flapping : il y a eu X changements d'état en 1h sur l'alarme (durée et fréquence paramétrable)
      • Cancelled : l'alarme a été annulée par un utilisateur (pour éviter les faux-positifs)
    • l'état du check :
      • INFO : tout va bien
      • MINOR : équivalent au Warning de Nagios
      • MAJOR : équivalent au Critical de Nagios
      • CRITICAL : les Unknown de Nagios sont remontés en tant que tel, mais cela ne se limite pas à cette notion
      • UNKNOWN : état non pris en charge à l'heure actuelle, c'est tout ce qui est supérieur à CRITICAL (3)
    • la présence d'un acquittement et/ou d'un ticket :
      • les connecteurs pour Nagios, Shinken, etc… peuvent remonter les acquittements posés
      • depuis Canopsis, on peut en poser manuellement
    • la date du dernier changement d'état

    Sur chaque alarme, on peut réaliser différentes actions :

    • l'acquittement (permet de déverrouiller les autres actions), cela émettra le même événement qui serait remonté par un superviseur, soit un événement de type ack
    • une suppression de l'acquittement, cela émettra un événement de type ackremove
    • une annulation de l'alarme, cela émettra un événement de type cancel
    • une fois l'alarme annulée, on peut annuler cette action, cela émettra un événement de type uncancel
    • une déclaration de ticket :
      • cela émettra un événement de type declareticket
      • cet événement pourra être capturé par le moteur event_filter pour déclencher un job (voir plus bas) qui communiquera le ticket à un outil tiers (par exemple iTop)
    • une association de ticket existant :
      • cela émettra un événement de type assocticket
      • on peut imaginer que le job qui communique la déclaration du ticket à l'outil tiers récupère le numéro du ticket nouvellement créé, et l'associe automatiquement
    • une requalification de l'événement :
      • cela changera l'état du check manuellement, et ce dernier gardera cet état jusqu'à la résolution de l'alarme
      • cela émettra un événement de type check, comme le superviseur
      • la seule différence est la présence d'un champ keep_state qui vaut true dans l'événement

    Toutes ces actions permettent ainsi d'unifier une supervision hétérogène, et l'administrateur (technique) ne devra utiliser/maîtriser qu'un seul outil.

    Sélecteur et widget météo : simplifier la supervision

    Lorsque l'on supervise une grosse infrastructure, les informations remontées via les checks deviennent tout de suite beaucoup plus conséquentes. C'est pourquoi nous avons mis en place la possibilité d'agréger ces checks afin d'avoir une visibilité plus simple sur l'infra.

    Cette agrégation se fait à l'aide des sélecteurs :

    • on créé un filtre d'événements
    • on applique un algorithme à l'état de chaque check qui matche le filtre (actuellement seul l'algo Worst State est disponible)
    • on produit un événement de type selector qui contient :
      • l'état agrégé
      • le champ output qui est le rendu du template spécifié dans la configuration du sélecteur
    • si le sélecteur est configuré pour, on déclenche le calcul des SLA :
      • sur une période de temps (spécifiée dans la configuration du sélecteur)
      • on calcule le pourcentage de temps passé sur chaque état possible
      • on produit une métrique pour chacune de ces métriques, ainsi qu'un événement de type sla
      • l'état remonté par l'événement correspond aux seuils de SLA configurés dans le sélecteur

    Le résultat est finalement affichable avec un widget weather :

    NB: Le sélecteur peut afficher également des checks unitairement

    On peut ainsi noter les couleurs suivantes :

    • vert : l'état du sélecteur est INFO
    • jaune : l'état du sélecteur est MINOR
    • orange : l'état du sélecteur est MAJOR
    • rouge : l'état du sélecteur est CRITICAL
    • violet : toutes les alarmes du sélecteur ont été acquittée
    • la couleur du widget est celle du pire état des sélecteurs positionnés dans celui ci

    Un clic sur le sélecteur dans le widget nous redirigera sur le Bac à événements, filtré avec le filtre du sélecteur.

    Monitoring et séries

    Chaque connecteur, moteur, et sélecteur produisent des données de performances :

    • temps d'exécution d'un check
    • usage CPU/RAM/Disque
    • temps moyen passé sur un événement
    • nombre moyen d'événements par seconde
    • donnée de SLA

    Tout cela est remonté dans Canopsis dans un événement via le champ perf_data_array :

    { // info de l'événement classique "perf_data_array": [ { "metric": "nom_de_ma_metrique", "value": 42.1337, "type": "GAUGE", // GAUGE, COUNTER, ABSOLUTE ou DERIVE // champs optionnels "unit": "...", "min": 0, "max": 1337.42, "warn": 1000, "crit": 1300 } ] }

    Ces données vont être historisée dans Canopsis. On peut donc noter 4 types de métriques :

    • GAUGE : on historise la valeur telle quelle
    • COUNTER : lorsque l'on récupère la valeur, on fait l'addition des valeurs historisées
    • ABSOLUTE : on historise la valeur absolue
    • DERIVE : il s'agit de la valeur dérivée par rapport au temps

    Une métrique est ensuite identifiée par :

    • le composant de l'événement
    • la ressource de l'événement
    • le nom de la métrique dans le tableau de perfdata

    Le tout peut être affiché dans un chart :

    On est ainsi en mesure de sélectionner un ensemble de métrique avec un filtre basé sur des expressions régulières :

    • co:.*\.myhost re:cpu-.* me:system me:user me:wait

    Qui se traduit en filtre MongoDB :

    { '$and': [ {'component': {'$regex': '.*\.myhost'}}, {'resource': {'$regex': 'cpu.*'}}, { '$or': [ {'name': {'$regex': 'system'}}, {'name': {'$regex': 'user'}}, {'name': {'$regex': 'wait'}} ] } ] }

    Une fois les identifiants de métriques récupérés, on peut aller demander les points stockés en base, dans une fenêtre de temps bien définie.

    Une série est donc munie :

    • d'un filtre de métrique
    • d'une période d'agrégation avec un opérateur d'agrégation (le manager de perfdata nous retournera les données agrégées)
    • d'une période de consolidation
    • d'une formule de consolidation

    Ici la partie consolidation sert à consolider les différents points agrégés en un seul, afin de produire une nouvelle métrique.

    La formule se construit de la manière suivante :

    • on a des opérateurs qui prennent en paramètre un filtre de métrique qui sera appliqué sur l'ensemble de métriques déjà sélectionnées
    • ces opérateurs retournent un point consolidé
    • on peut les utiliser dans une expression mathématique classique

    Par exemple, SUM("me:.*") / COUNT("me:.*"), permet de réaliser une moyenne.

    Les tâches ordonnancées et les notifications

    Parmi les moteurs de Canopsis, certains sont dédiés à une fonction précise : exécuter une tâche.

    Il y a donc un moteur scheduler qui, régulièrement, va chercher à exécuter des jobs configurés selon une règle de récurrence.
    En fonction du type de job, ce dernier sera redirigé au moteur correspondant, que l'on appellera un taskhandler.

    Cela permet de construire un équivalent de crontab au sein de Canopsis.

    Ces taskhandlers ne servent pas uniquement à l'exécution de tâches ordonnancées, ils peuvent être utilisés en tant que notification :

    • une règle du moteur event_filter peut déclencher l'exécution d'un job si l'événement reçu matche le filtre de la règle
    • par exemple, à la réception d'un événement declareticket, on peut lancer l'exécution d'un job réalisant une requête d'insertion de ticket à un outil tiers
    Conclusion

    Grâce à tout ces éléments, Canopsis est en mesure de répondre à de nombreux besoins, allant de la supervision simple, à l'analyse poussée de données afin de générer des rapports sur une infrastructure (ou autre).

    Notre objectif premier est la modularité du projet, afin de pouvoir fournir une solution sur mesure et de ne pas transformer l'outil en énorme usine à gaz. Pour résumer, on a répondu à cette problématique avec :

    • le découpage du backend en projets Python embarquant : un manager, éventuellement un moteur et un webservice
    • le découpage du frontend en briques embarquant : des composants, des renderers, des éditeurs, des mixins, des widgets
    • la schématisation des données et à l'avenir des actions possibles sur cette dernière (transformation, schématisation de l'API des managers, …)
    • le développement d'API générique permettant le changement de technologies sans modification du code

    Beaucoup de choses ont été faites, et beaucoup de travail reste à faire, notamment :

    • la finalisation des rôles Ansible
    • l'intégration d'une notion de graphe pour les entités qui sont le centre de toutes les données stockées par Canopsis, afin de rendre le système complètement réflexif
    • une séparation totale du backend et du frontend, permettant d'utiliser l'un sans l'autre
    • génération de code à partir des schémas

    Bref, Canopsis est en constante évolution, et touche à de nombreuses problématiques toutes plus intéressantes les unes que les autres.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Agenda du Libre pour la semaine 6 de l'année 2016

    7 février, 2016 - 01:18

    Calendrier web, regroupant des évènements liés au Libre (logiciel, salon, atelier, install party, conférence) en France, annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 28 événements est en seconde partie de dépêche.

    Sommaire Agenda du Libre pour la semaine 6 de l'année 2016 [Kunheim] Formation Linux - Le lundi 8 février 2016 de 18h00 à 22h00.

    Tous les lundis à partir de 18h00 jusqu'à 22h00 venez découvrir ou vous former sur Linux et les logiciels libres.
    Ces séances de formation ont lieu à la salle "Kegreiss" au 56 rue principale - Kuhneim - face à la mairie - cette salle est accessible aux personnes à mobilité réduite.
    Nous vous attendons nombreux. Le Team Linux

    [Paris] Atelier OpenData - Le lundi 8 février 2016 de 19h00 à 22h00.

    L'atelier « Opendata : les enjeux des données ouvertes » est organisé par Ritimo et animé par Regards Citoyens.
    Il est à destination du monde associatif (venir avec son portable). L'entrée est libre et l'inscription obligatoire.
    Extrait de la présentation :

    [Teyran] Notions PC - Le mardi 9 février 2016 de 09h00 à 10h00.

    Réaliser une carte d’invitation avec le traitement de texte LibreOffice Writer
    Writer est le composant de traitement de texte de LibreOffice. En plus des fonctionnalités habituelles d’un traitement de texte (correcteur orthographique, dictionnaire des synonymes et de coupure de mots, autocorrection, rechercher et remplacer, génération automatique de table des matières et d’index, mailing et autres) Writer fournit des modèles et styles, des méthodes de mise en page incluant les cadres, les colonnes et les tableaux, incorporer ou lie des images, des feuilles de calcul et d’autres objets, il a des outils de dessins natifs, possède un suivi de modification, exporte en PDF, incluant les repères de texte…
    La participation aux ateliers nécessite :

    [Castelnau-le-Lez] Section GNU/Linux - Le mardi 9 février 2016 de 10h00 à 12h00.

    Rendez-vous hebdomadaire, tous les mardis, salle 38 de la mjc (hors vacances scolaires).
    L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.
    Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi d’adapter l’acquisition de nouvelles compétences au rythme de chacun.

    [Castelnau-le-Lez] Atelier de développement et programmation - Le mardi 9 février 2016 de 10h00 à 12h00.

    Rendez-vous hebdomadaire, tous les mardis, salle 40 de la mjc (fermé pendant les vacances).
    Cet atelier de développement est essentiellement axé sur les langages du Web : html, css (même si ce ne sont pas des langages à proprement parler) javascript et PHP, possibilité aussi d’utiliser Ajax, Jquery, Sqlite et MySql.
    Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.

    [Brignoles] Atelier Libre - Le mardi 9 février 2016 de 18h30 à 21h30.

    Les membres de l'association GULLIVAR (Groupe d'Utilisateurs de Logiciels Libres de l'Intérieur du Var) vous invitent à une soirée atelier / présentation logiciel libre qui aura lieu le 9 février 2016, dans la salle des Saint Anges, chemin de San Sumian à Brignoles à partir de 18h30.
    À 19h30, l'atelier / présentation.
    Cette soirée est ouverte à tous, adhérents et sympathisants.

    [Bordeaux] Atelier CLI - Le mardi 9 février 2016 de 19h00 à 21h00.

    Damien Goutte-Gattat, post-doctorant à l'Institut Européen de Chimie et Biologie, présentera GnuPG (GNU Privacy Guard) pour les utilisateurs avancés.
    Déjà habitué avec ses articles, tel que « De la gestion des clefs OpenPGP », postés dans son journal sur linuxfr.org, cet atelier sera certainement très instructif. On pourra, en autre, créer sa clé GPG et la partager :)
    L'atelier sera suivi d'un apéritif permettant aux participants de se rencontrer et de poursuivre la discussion.

    [Paris] Tuppervim #43 - Le mardi 9 février 2016 de 20h00 à 22h00.

    Le tuppervim est un évènement mensuel organisé dans les locaux de Mozilla.
    Il a lieu un mardi du mois (généralement le premier).
    Le texte suivant a été honteusement copié du site http://tuppervim.org

    [Teyran] Notions PC - Le mercredi 10 février 2016 de 09h30 à 10h30.

    Ajouter de la profondeur de champ à une photographie avec Gimp
    Gimp offre de nombreuses fonctionnalités. Il peut être utilisé comme un simple programme de dessin, comme un programme de retouche photo, comme un système en ligne de traitement par lot, comme un générateur d’image pour la production en masse, pour convertir un format d’image en un autre. GIMP est extensible. On peut lui ajouter de nombreux « Greffons » (plug-ins). Une interface de scripts bien développée permet de créer des procédures, les scripts, regroupant plusieurs opérations.
    La participation aux ateliers nécessite :

    [Nantes] Quadr'apéro - Le mercredi 10 février 2016 de 19h00 à 23h00.

    Venez discuter des libertés et d'Internet au quadr'apéro mensuel.
    Venez nombreux.
    Entrée Libre. Tout Public.

    [Paris] Atelier design : les couleurs - Le mercredi 10 février 2016 de 19h00 à 21h00.

    Atelier Do It Yourself Design : 16,8 Millions de couleurs, et moi et moi!
    Dans la série des atelier Do it yourself, l’association Silex Labs vous propose un nouvel atelier pour découvrir l’importance des couleurs dans les projets numériques. Cet atelier sera animé par Pol Goasdoué designer professionnel spécialiste de l’UX UI Président de l’entreprise UFO et co-fondateur du projet Silex.
    Au programme de cet atelier

    [Paris] Apéro des nouveaux mozilliens - Le mercredi 10 février 2016 de 19h00 à 21h00.

    L'apéro des nouveaux aura lieu le 10 février à partir de 19h chez Mozilla (16 bis boulevard Montmartre, 75009 Paris).
    Ça sera bien évidement l'occasion pour les nouveaux de rencontrer une partie de la communauté mozfr et pour tous de (re)découvrir comment il est possible de participer. Plus largement, ça serait chouette qu'on profite de l'occasion pour se dire sur quoi on bosse et sur quoi on aimerai bosser. Ça permet de mieux savoir qui est intéressé par quoi et de faciliter la participation de nouvelles personnes. Tout cela se faisant bien sûr  de manière informelle et dans la bonne humeur.
    Afin de gérer l'intendance, veuillez-vous inscrire sur le pad:https://public.etherpad-mozilla.org/p/aperoNouveaux

    [Proposition en ligne] Appel à communications AgoraCMS 2016 - Du jeudi 11 février 2016 à 00h00 au vendredi 12 février 2016 à 00h00.

    La 3ème édition d'AgoraCMS, premier événement européen dédié aux CMS se tient à Paris le 1er avril prochain.
    L'appel à communications pour les conférences vient d'être lancé: http://agoracms.com/appel-a-communication.
    Vous pouvez y proposer vos idées de conférences, de retours d'expérience, de vos projets.

    [Mauguio] Infolibres - Le jeudi 11 février 2016 de 17h00 à 19h00.

    Rendez-vous salle de formation informatique de la médiathèque.
    L’équipe de Montpel’libre vous propose une permanence de dépannages pour vous aider à apprivoiser votre système GNU/Linux au quotidien. Le contenu de l’atelier s’adapte aux problèmes des personnes présentes.
    Vous pourrez y aborder entre autre :

    [Paris] Mapathon Missing Maps - Le jeudi 11 février 2016 de 19h00 à 22h00.

    Venez découvrir comment contribuer à OpenStreetMap, le "Wikipedia de la carte", durant un « mapathon » !
    (un événement convivial où l'on se retrouve pour cartographier, échanger et apprendre à utiliser les outils permettant de contribuer à OSM).
    Cet événement s'inscrit dans le cadre de l'initiative globale Missing Maps, projet humanitaire qui vise à cartographier en amont les parties du mondes vulnérables aux catastrophes naturelles, crises sanitaires, environnementales, aux conflits et à la pauvreté.

    [Lyon] Jeudi du Graphisme - Le jeudi 11 février 2016 de 19h00 à 21h00.

    L'Association Lyonnaise pour le Développement de l'Informatique Libre organise un atelier découverte du logiciel : Darktable : Corrections et profils d’effet qui est animé par les étudiants de la licence CoLibre.
    Darktable est un logiciel de développement et retouche de photo. L’application pour les photographes passionnés. Cette année, nous appliquerons à voir quelques techniques de retouche simple et utile et surtout comment créer des profils d’effets qui seront la signature de votre touche personnelle.
    Entrée Libre et gratuite

    [Paris] Soirée de Contribution au Libre - Le jeudi 11 février 2016 de 19h30 à 23h00.

    Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.
    Nous nous réunissons donc tous les jeudis soirs dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies)).
    Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

    [Montpellier] Formation sécurité informatique et cryptographie - Le vendredi 12 février 2016 de 09h00 à 13h00.

    Montpel’libre a le plaisir de vous proposer un nouveau cycle de formation, cryptographie et sécurité informatique.
    Merci d’avoir choisi de participer aux ateliers « Sécurité Informatique et Cryptographie » organisés par Le Club de la Presse et Montpel’libre. Les trois ateliers auront lieu les vendredis 5, 12 et 19 février 2016 de 9h00 à 13h00 à l’Atelier des Pigistes du Club de la Presse de Montpellier.
    Formation Crypto, séance de préparation, premier module :

    [Paris] Locasprint MozFR n°4 - Du vendredi 12 février 2016 à 14h00 au dimanche 14 février 2016 à 20h00.

    La communauté Mozilla francophone organise son 4e évènement autour de la traduction. La communauté Mozilla de bénévoles francophones est à l’origine de l’ensemble du contenu en français publié par Mozilla (logiciels, sites web, documentation, pages d’assistance, etc.)
    Cet évènement est ouvert à toute personne qui souhaite nous aider à produire des traductions françaises de qualité. Vous avez juste besoin de venir avec un ordinateur et de la motivation.
    Ce week-end de travail est l’occasion d’accueillir de nouveaux contributeurs, de leur expliquer notre façon de travailler, nos outils, nos bonnes pratiques…

    [Montpellier] Permanence Les logiciels libres - Le vendredi 12 février 2016 de 17h00 à 19h00.

    Le Faubourg Marché, qu’est-ce que c’est ?
    Le Faubourg Marché est une permanence partagée qui permet aux associations d’accueillir ensemble, les publics de ces associations une fois par semaine, le vendredi entre 17h00 et 19h00 (ou au delà sous réserve d’accord préalable), au 19, rue du Faubourg de Nîmes, 34000 Montpellier.
    Si vous avez un peu de temps le vendredi soir, voici une occupation qui me semble très intéressante et si vous êtes intéressés par la promotion des logiciels libres, des biens communs, de l’accessibilité, de l’économie sociale et solidaire, de l’innovation sociale et numérique, de l’éducation populaire, ou encore du développement durable.

    [Villeneuve d'Ascq] Libre à Vous - Le samedi 13 février 2016 de 09h00 à 12h00.

    Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres ?
    Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.
    C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

    [Castelnau-le-Lez] Café Numérique GNU/Linux & Logiciels Libres - Le samedi 13 février 2016 de 09h00 à 11h00.

    Samedi 13 février 2016 de 9h00 à 11h00 MJC Centre André Malraux 10, avenue de la Moutte, 34170 Castelnau-le-Lez
    Bus Ligne 35 arrêt Collège Frédéric Bazille Tramway ligne 2 arrêt La Galine
    GPS : Latitude : 43.633946 | Longitude : 3.905794

    [Teyran] Notions PC - Le samedi 13 février 2016 de 09h30 à 10h30.

    Enregistrer, importer, manipuler des fichiers sonores avec Audacity
    Audacity est un logiciel libre4 pour la manipulation de données audio numériques. Audacity permet d’enregistrer du son numérique par le biais des entrées ligne/micro/cd des cartes sons. Il permet d’éditer (copier, coller, sectionner…) les sons sur plusieurs pistes, et il est accompagné de divers filtres et effets : pitch, tempo, réduction de bruit, égaliseur, filtres de Fourier, augmentation de fréquences précises, compression, amplification, normalisation, écho, phaser, wahwah, inversion…
    La participation aux ateliers nécessite :

    [Toulouse] Atelier Blender pour tous - Le samedi 13 février 2016 de 10h00 à 18h00.

    La communauté toulousaine des utilisateurs de Blender est l'une des plus actives de France.
    Elle se retrouve régulièrement pour organiser des ateliers, des repas, des soirées.
    C'est donc dans ce cadre que le Blender User Group toulousain organise, en coopération avec Toulibre, environ un samedi par mois, de 10h à 18h dans les locaux de l'espace Ékito, 15 rue Gabriel Péri à Toulouse.

    [Saint-Denis] Assemblée générale de l'April - Du samedi 13 février 2016 à 13h00 au dimanche 14 février 2016 à 19h00.

    L'assemblée générale de l'April aura lieu le samedi 13 février 2016 de 14h à 18h (accueil à partir de 13h00) à l'université Paris 8 à Saint-Denis (bien que l'AG se tienne en 2016, elle concerne le bilan de l'année 2015 mais bien sûr les perspectives 2016 seront abordées).
    Il s'agit d'un des événements importants de la vie de l'association, l'occasion de voter les rapports moral et financier, faire un point sur l'année qui vient de s'écouler, de rencontrer les autres adhérents et d'élire le conseil d'administration.
    L'assemblée générale est l'occasion d'organiser un week-end de réunion des membres. Le dimanche sera consacré à des ateliers en petits groupes ou discussions en plénière. Ce week-end est en cours d'organisation, plus de détails bientôt. Cette partie atelier est ouverte à tout le monde et aura lieu à la Fondation pour le Progrès de l'Homme à Paris. Une soirée festive est prévue le samedi soir et des ateliers sont prévus le dimanche. Le lieu pour la soirée n'est pas encore fixé.

    [Ramonville Saint Agne] Atelier web: les squelettes sous SPIP - Le samedi 13 février 2016 de 14h00 à 18h00.

    Deux nouvelles animations organisées très prochainement par le Projet Internet et Citoyenneté à la Maison des Associations de Ramonville. Ces deux animations sont complémentaires: c'est une bonne idée de participer aux deux, mais ce n'est pas obligatoire.
    1/ SAMEDI 30 JANVIER 2016: Personnaliser son site Web avec les CSS: Initiation aux CSS. À partir de la version distribuée de SPIP, personnaliser son site en modifiant les fichiers CSS.
    2/ SAMEDI 13 FEVRIER 2016: Initiation à l’écriture/modification des squelettes qui conditionnent les fonctionnalités présentes dans les pages d’un site sous SPIP. Modifier le squelette des articles, rubriques, etc. pour changer l’aspect et les fonctionnalités présentes dans les pages du site.

    [Saint-Aunès] Permanence Emmabuntüs et Logiciels Libres - Le samedi 13 février 2016 de 14h00 à 18h00.

    Samedi 13 févier 2016 de 14h00 à 18h00 Communauté Emmaüs Montpellier-Saint-Aunès La Vieille Cadoule 34130 Saint-Aunès
    GPS Latitude : 43.649363 | Longitude : 3.991591
    Rendez-vous mensuel, le deuxième samedi. Pour les animateurs, réservez les repas et le covoiturage le jeudi au plus tard.

    [Marseille] Atelier « Découverte des Logiciels Libres Firefox » - Le samedi 13 février 2016 de 14h30 à 18h00.

    L’association CercLL vous invite à l’ Atelier du Samedi Libre qui se déroule le samedi 13 février 2016 de 14h30 à 18h00, à la Fabulerie 4 rue de la Bibliothèque 13001 Marseille.
    Ces ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé.
    Comme le mot atelier le laisse présumer, dans ce cadre, nous proposons une approche pratique des outils libres.

    Télécharger ce contenu au format Epub

    Lire les commentaires