Les centres qui gèrent les réseaux qui composent
l'Internet, les NOC, ont
régulièrement besoin d'échanger de l'information. Celle-ci, concernant
les incidents, les nouveautés, les problèmes, circule souvent en
quantités impressionnantes et est donc une bonne candidate pour
l'automatisation. Ce RFC expérimental propose
donc un format standard, basé sur XML, pour
représenter l'information qui circule entre NOC, notamment ceux qui
gèrent en commun une grande grille, ce qui est
le cas d'EGEE, où travaillent les auteurs. Il est important pour de grosses infrastructures réseau comme les grilles de
calculs, qui s'étendent sur plusieurs domaines administratifs, de pouvoir interpréter correctement les
tickets avec un minimum de dépendance vis-à-vis de l'origine du ticket. L'effort de
normalisation prend tout son sens dans ce contexte. Un ticket pourra donc être lu et compris sans avoir besoin de connaître les particularités et la terminologie du domaine d'origine.
Le but (section 1) n'est pas de remplacer les outils de
gestion de tickets de chaque
NOC mais d'avoir un format d'échange standard,
suivant les souhaits du . Les
tickets ainsi formatés pourront automatiquement
être émis par un NOC, reçus par un autre, être analysés, etc. Ces outils de gestion de
tickets seront ensuite utilisés pour analyser le problème, suivre son
évolution et, d'une manière générale, assurer un bon fonctionnement du
réseau.
On comprend mieux la taille du problème quant on voit que la
grille de calcul EGEE
qui utilise les NREN (vingt participants) pour sa connectivité,
reçoit 800 tickets et 2500 messages par mois.
Notre RFC décrit un modèle de données en
UML, puis un format concret de représentation
en XML. Un problème classique que rencontrent
toutes les tentatives de normalisation dans ce domaine est qu'il faut
à la fois décrire de manière formelle l'incident, en énumérant de
manière limitative les choix possibles, pour permettre son
traitement automatique, tout en gardant des possibilités d'exprimer
des problèmes nouveaux, ce qui impose de garder la possibilité de
mettre du texte libre, non formaté.
Voyons d'abord les types de données utilisés (section 2). On y
trouve plusieurs énumérés comme
TT_TYPE qui indique si le ticket concerne un
problème opérationnel, administratif, ou bien n'est là que pour
information, TYPE qui indique si l'événement
était prévu ou accidentel, TT_STATUS qui donne
l'état du ticket (ouvert, résolu, annulé, fermé..., avec un diagramme
de transition apparemment obligatoire). On trouve aussi bien sûr des
chaînes de caractères (qui seront simplement le type W3C
XML Schema xs:string) et des heures
(au format du , alias
xs:dateTime).
Armée de ces définitions, la section 3 détaille la longue liste des
attributs d'un ticket. On y trouvera même un diagramme de classe
UML en art
ASCII... Parmi ces attributs, les grands classiques, comme
l'identificateur unique du ticket (formé par la concaténation de
l'identificateur du NOC et d'un identificateur local, ce qui permet d'allouer ces identificateurs uniques de
manières décentralisée), l'état du ticket, sa date de création, l'identificateur du NOC qui est
à l'origine du ticket (le RFC n'explique pas comment ses
identificateurs, qui doivent être uniques, sont attribués et
conservés), une description courte qui est sélectionnée à partir d'une
liste pré-définie (pour permettre le traitement automatique) et une
description longue qui est en texte libre (la
langue utilisée peut être représenté dans le
fichier XML par un attribut lang - pour des
raisons que j'ignore, l'attribut standard XML
xml:lang n'a pas été utilisé), les identificateurs de
tickets ayant un rapport avec celui-ci, etc. Pour chaque attribut est
indiqué s'il est obligatoire ou non.
La section 4 décrit l'approche utilisée pour l'internationalisation
puisque les tickets seront échangés entre NOC de pays et de langues différents. Les
champs formels (comme la description courte) n'ont pas besoin d'être
adaptés (le logiciel de chaque NOC pourra les présenter comme il le
voudra), les textes libres (comme la description longue de l'incident)
peuvent être dans n'importe quelle langue (des systèmes de
traduction automatique sont prévus pour
EGEE dans le futur).
Si vous êtes impatients de voir à quoi ressemblent ces fameux
tickets en XML, sautez directement à la section 5, qui présente les
exemples. Voici un joli ticket indiquant une panne chez
Forth en Grèce :
5985
01
01_5985
Forth Link Failure
Operational
Closed
2008-12-16T10:01:15+02:00
Core Line Fault
Forth Link Failure
Unscheduled
No connectivity
2008-12-16T09:55:00+02:00
2008-12-16T15:00:34+02:00
HERAKLION
Optical transmitter was changed
2008-12-16T15:05:00+02:00
2008-12-16T15:01:21+02:00
FORTH
FORTH-2
Dimitris Zisiadis
Guillaume Cessieux
Spyros Kopsidas
Chrysostomos Tziouvaras
High
]]>
On notera que l'exemple est imparfait :
l'étiquette de langue el indique du
grec mais le texte est entièrement en anglais.
Enfin, la section 6 contient le schéma complet, en langage
W3C XML schema et la section 7 quelques
avertissements de sécurité. Comme le contenu des tickets peut être
sensible, il peut être utile de chiffrer et
d'authentifier les
tickets mais le RFC ne suggère pas de technique standard pour cela.
Merci à Xavier Jeannin pour sa relecture.