0
I Use This!
Activity Not Available

Project Summary

Chaque machine supervisée du parc a un « agent » déployé dessus, qui tourne en arrière-plan. Il s'agit d'un script Ruby que je vous fournis, capable d'examiner les taux d'occupation de la RAM et de différents points de montage disque (attention, il ne fonctionnera pas sous Windows).

Un serveur central (que vous allez réaliser en Rails) permet à l'administrateur de définir facilement et rapidement son parc (salles, machines dans ces salles avec leurs IP…), et va interroger à intervalles réguliers ces machines pour vérifier qu'elles sont actives, et leur agent opérationnel. Les agents examinent à intervalle régulier leur machine, et font spontanément remonter au serveur tout incident (taux d'utilisation trop élevé). Le serveur fournit, dans son interface web, une page de supervision en temps réel, qui représente « graphiquement » le parc, et utilise AJAX pour ajuster fréquemment l'aspect des machines représentées, afin de traduire les éventuels incidents (ou terminaisons d'incident).

Définition simple de parc

L'administrateur doit pouvoir injecter son parc dans le système : salles et machines dans ces salles. Une machine, pour les besoins de notre outil, peut se limiter à son nom et son IP, mais si vous voulez vous lâcher, libre à vous.

La définition du parc doit pouvoir se faire sans JavaScript, évidemment. Tout le système doit d'ailleurs être accessible, et JavaScript/AJAX ne sont là que pour rendre le tout bien plus confortable. On doit donc avoir des liens et des formulaires classiques pour ajouter une salle, ajouter des machines dans une salle, et maintenir tout ça par la suite (retrait ou déplacement de machine, retrait de salle, etc.).

Une salle a simplement un nom : pour notre outil, on se fout un peu de sa capacité, son emplacement, etc.

À intervalle régulier (par exemple toutes les minutes), le serveur va vérifier que les machines inscrites dans le système sont joignables, et que l'agent y est opérationnel. Pour cela, il se connecte sur l'agent et envoie le message idoine.

Affichage de supervision

Il s'agit d'un écran affichant graphiquement le parc, qui se met à jour régulièrement pour refléter les incidents éventuels en cours.

Les salles sont représentées sous forme de boîtes rectangulaires. Dans ces boîtes, les machines concernées sont affichées (boîte obtenue par CSS, grand icône d'ordinateur, comme vous voulez…) Tout incident en cours pour une machine est affiché en association avec celle-ci (icône plus petit superposé à, ou au-dessous de, la représentation de la machine) L'écran doit pouvoir se mettre à jour régulièrement, de façon accessible. Si JavaScript n'est pas actif, on aura donc recours à une équivalent HTTP de l'en-tête Refresh, grâce à l'élément

. Dans le cas contraire, on utilisera AJAX pour éviter de rafraîchir toute la page : la réponse nous indiquera alors uniquement les incidents terminés ou apparus depuis la dernière consultation, et on ajustera dynamiquement le contenu de la page.

Toujours dans un souci d'accessibilité, toute image doit bien sûr avoir une contrepartie textuelle (qui n'est pas forcément visible avec les images activées, mais doit l'être en images désactivées ou dans une consultation textuelle de la page).

Il est inutile de rafraîchir trop souvent, sauf peut-être pendant les tests : un intervalle d'une minute est a priori amplement suffisant (en revanche, au-delà de 5 minutes on n'est vraiment plus « temps réel »).

Remontée d'incidents et historisation

Les incidents parviennent au serveur de deux façons :

Il les détecte lui-même lors de vérifications périodiques de connectivité des agents, comme vu en section II.2. Les agents font spontanément remonter des incidents au travers d'une requête HTTP de création REST appropriée, comme indiqué dans leur documentation. Le serveur doit historiser les incidents, ce qui suppose qu'un incident a au moins les propriétés suivantes :

Machine concernée Type d'incident (ex. RAM trop basse, espace libre trop bas sur un point de montage, connectivité défaillante) Propriétés complémentaires (ex. RAM restante, espace disque restant, etc.) Moment de détection (date/heure) Moment de résolution (constatation d'incident terminé) Pour la connectivité, c'est le serveur lui-même qui crée l'incident et, lorsqu'il constate qu'elle fonctionne alors qu'un incident est actif (détection sans résolution), le marque comme résolu. Pour les autres types d'incidents, qui sont remontés spontanément par les agents, ces derniers gardent trace des incidents qu'ils ont signalés et notifient automatiquement leur résolution lorsqu'ils la constatent.

Cette historisation ouvre la voie au calcul de durées de résolution, de durées totales d'incident, etc. On peut imaginer pas mal de statistiques.

Partie authentifiée

L'application dispose d'un ou plusieurs comptes utilisateur, tous administrateurs, et il est nécessaire de s'authentifier pour pouvoir accéder à toute opération modificatrice, donc principalement la définition du parc. En revanche, la supervision, l'interrogation manuelle, les éventuelles statistiques, etc. sont accessibles en anonyme.

Interrogation manuelle d'une machine

Depuis l'écran de supervision, il doit être possible d'interroger manuellement l'état d'une machine en s'adressant à son agent. On peut simplement vérifier sa connectivité, ou demander l'état de la RAM ou d'un point de montage. Cela peut avoir lieu dans un écran à part ou en AJAX (ceci dit, ça doit pouvoir être utilisable sans AJAX, comme d'habitude).

Le contrôleur sollicité va se connecter à l'agent comme il le ferait pour vérifier la connectivité, mais invoquer d'autres commandes (voir la documentation), créer ou résoudre l'incident éventuel comme il le ferait lors des vérifications périodiques normales, et signifier le résultat à la partie client.

Tags

bliss carot insia rails ruby

In a Nutshell, blisscarot...

 No code available to analyze

Open Hub computes statistics on FOSS projects by examining source code and commit history in source code management systems. This project has no code locations, and so Open Hub cannot perform this analysis

Is this project's source code hosted in a publicly available repository? Do you know the URL? If you do, click the button below and tell us so that Open Hub can generate statistics! It's fast and easy - try it and see!

Add a code location

GNU General Public License v2.0 or later
Permitted

Commercial Use

Modify

Distribute

Place Warranty

Forbidden

Sub-License

Hold Liable

Required

Distribute Original

Disclose Source

Include Copyright

State Changes

Include License

These details are provided for information only. No information here is legal advice and should not be used as such.

All Licenses

This Project has No vulnerabilities Reported Against it

Did You Know...

  • ...
    Black Duck offers a free trial so you can discover if there are open source vulnerabilities in your code
  • ...
    you can embed statistics from Open Hub on your site
  • ...
    use of OSS increased in 65% of companies in 2016
  • ...
    search using multiple tags to find exactly what you need

 No code available to analyze

Open Hub computes statistics on FOSS projects by examining source code and commit history in source code management systems. This project has no code locations, and so Open Hub cannot perform this analysis

Is this project's source code hosted in a publicly available repository? Do you know the URL? If you do, click the button below and tell us so that Open Hub can generate statistics! It's fast and easy - try it and see!

Add a code location

Community Rating

Be the first to rate this project
Click to add your rating
   Spinner
Review this Project!
Sample ohloh analysis