Résumé

  • Le RFC 2039 distinguait un modèle opérationnel — matériel, système, processus, dépendances et capacité — d’un modèle de service centré sur les requêtes et réponses vues par les clients web.
  • Son exemple d’un même ordinateur hébergeant trois domaines virtuels montrait pourquoi l’inventaire des processus ne permettait pas, à lui seul, d’identifier le service réellement atteint.

Un serveur peut être parfaitement observable et mal compris. Si l’objet mesuré est le processeur, un taux normal dit quelque chose de vrai sur le processeur. Il ne dit pas qu’une page dynamique a traversé sa passerelle, atteint sa base de données et produit une réponse correcte.

Publié en novembre 1996, le RFC 2039 portait sur l’applicabilité des MIB normalisées à la gestion des serveurs du World Wide Web. C’était un document Informational, non une norme Internet. Demandé après le BOF HTTP-MIB du 35e IETF à Los Angeles, il répondait moins par une nouvelle métrique que par une séparation conceptuelle.

Dans le modèle opérationnel, le serveur web est un ordinateur composé de matériel, de disque, de système d’exploitation et de logiciels. Il faut suivre CPU, stockage et réseau, connaître les dépendances entre applications, produire des erreurs de façon cohérente, conserver un historique pour la capacité et savoir ce qu’une opération d’arrêt ou de reconfiguration va toucher.

Dans le modèle de service, la machine devient une boîte noire qui reçoit des demandes de clients et renvoie des réponses. La question n’est plus seulement « le processus tourne-t-il ? », mais « le service de récupération fonctionne-t-il, pour quel document, avec quelles autorisations et quelles dépendances dynamiques ? ».

Les deux modèles se complètent sans se substituer. Une interface réseau et un processus peuvent être disponibles alors que la base nécessaire à un contenu dynamique ne l’est plus. Inversement, un service peut encore répondre tandis que sa marge de disque ou de connexions se réduit dangereusement. La contradiction n’est qu’apparente : les mesures portent sur des objets différents.

Le cas décisif des domaines virtuels

Le mémo examinait les outils déjà disponibles. MIB-II décrivait le système et les interfaces ; la Host Resources MIB couvrait processeurs, stockage, périphériques et logiciels ; la Network Services Monitoring MIB suivait des applications de service et leurs associations ; les travaux Application MIB visaient les exécutables, fichiers et applications instrumentées.

Le constat n’était pas un rejet. Les attributs existants répondaient largement au modèle opérationnel, et certains donnaient une première vue du service. Mais les deux piles restaient orthogonales. Leur relation ne pouvait se réduire à un pointeur universel, puisque l’architecture logicielle variait selon l’implémentation.

Imaginons, comme le RFC, un ordinateur qui sert trois domaines virtuels. Un seul programme peut les prendre en charge, ou trois processus distincts. Une page statique dépend d’un fichier ; une page dynamique traverse peut-être une passerelle puis une base. La table des processus peut affirmer avec exactitude que le serveur tourne, sans indiquer quel domaine ne répond plus. La table des services peut distinguer les domaines et les associations, sans désigner l’exécutable, le fichier de configuration ou l’application aval à réparer.

Il fallait donc maintenir la correspondance entre identité de service et composants opérationnels, puis ajouter une instrumentation propre au Web. Accumuler les compteurs de machine ne suffisait pas.

Ce que chaque plan devait rendre visible

Le volet opérationnel réclamait l’utilisation du processeur, du disque et du réseau, les dépendances applicatives, une remontée d’erreurs standardisée, des historiques de capacité et une représentation structurée d’informations habituellement enfermées dans les journaux. Ces dépendances déterminent si redémarrer un composant rétablit un service ou en interrompt plusieurs.

Le volet service réclamait l’usage et les performances du service de récupération, le suivi des documents statiques et dynamiques, des statistiques et permissions par document, ainsi que l’état des applications qui produisent les contenus dynamiques. Il ajoutait configuration centrale, démarrage, arrêt, rotation des journaux et indication de qualité de service.

Il faut conserver la modestie de la source. Le RFC ne mesure aucun gain de fiabilité, ne décrit pas un déploiement représentatif et ne définit pas les objectifs de service actuels. Le brouillon, la liste de diffusion et l’implémentation exemple qu’il mentionne témoignent d’un travail en cours, pas d’une adoption. Les questions de sécurité sont explicitement hors de son champ.

Le RFC 2594, publié en 1999 comme Proposed Standard, donna ensuite une forme plus précise au côté service : protocole abstrait de transfert de documents, actions, requêtes, réponses, codes d’état, hôtes virtuels et statistiques. Il revendiquait une vue orientée service, non processus, limitée à la détection et au diagnostic à court terme, sans comptabilité ni comptage de visites. Il n’a pas formellement remplacé le RFC 2039, mais il confirmait que le service avait besoin de son propre vocabulaire.

Sources