wulfstat - En ligne dans le Cloud

PROGRAMME:

Nom

wulfstat - Un modèle de projet simple

SYNOPSIS

wulfstat [-h] [-v] [-t type_affichage] [-d délai] [-c nombre]
[-f /chemin/vers/wulfhosts] [-l]

WULFSTAT OPTIONS

-h affiche l'aide (synopsis de la commande).
-v rend l'exécution verbeuse pour le débogage ou l'ennui.
-t display_type sélectionne le type d'affichage dans la liste ci-dessous
-d delay (en secondes) sélectionne le délai de boucle de mise à jour
-c count l'oblige à afficher uniquement le nombre de fois et à quitter (pour le débogage)
-f /chemin/vers/wulfhosts pour utiliser un fichier wulfhosts particulier
-l afficher uniquement localhost (n'utiliser aucun fichier wulfhosts de n'importe quel emplacement)

DESCRIPTION

wulfstat est un outil de surveillance de cluster simple mais puissant basé sur tty (ncurses). Ce
nécessite xmlsysd (exécuté sur chaque système à surveiller) pour lui fournir efficacement
système et informations dérivées du processus qui sont traitées et fournies à l'utilisateur dans l'un des
plusieurs formats d'affichage sélectionnables par l'utilisateur. Avec lui, un utilisateur peut surveiller les choses à travers en
des descripteurs de systèmes LAN complets de beowulf, de cluster ou de poste de travail, tels que la moyenne de charge,
consommation de mémoire, swap, page et interruption de l'activité et des charges réseau ou peut même
récupérer et afficher des informations banales telles que la marque du processeur et l'horloge de base, l'heure du système,
temps de disponibilité ou d'autres descripteurs de système potentiellement utiles mais variant lentement. L'information
présenté est mis à jour régulièrement après un délai sélectionnable par l'utilisateur. L'outil permet aux affichages de
être sélectionné ou modifié pendant l'exécution de l'application, et plus d'hôtes ou de nœuds peuvent être
affichés qui s'adapteront facilement sur un seul, par exemple xterm en les parcourant avec la touche-
commandes basées.

HÔTE WULF

Pour exécuter wulfhost comme autre chose qu'un moniteur de l'hôte local, il faut un fichier wulfhost.
wulfstat s'exécute sans fichier wulfhost viable par défaut sur une connexion localhost. Un hôte local
la connexion peut également être forcée (en supplantant la recherche d'un fichier wulfhost) avec le -l
argument de ligne de commande.

Le fichier wulfhost indique à wulfstat où se connecter à xmlsysd. Il se compose de n'importe quel mélange
des descripteurs XML suivants :

<? Xml version = "1.0"?>




RVB
On_spin3d


ganesh



192.168.1.132
7887



Lucifer
192.168.1.131
7887



g%02d
1
15
7887



152.3.182.193
152.3.182.200
7887




A partir de cet exemple, on voit que le La balise définit un hôte auquel se connecter.
Dans cette balise, l'hôte peut être spécifié par le tag (qui peut contenir n'importe quel
nom résolvable par gethostbyname()) ou le tag, le plus couramment utilisé pour les hôtes dans
un cluster qui n'a pas été nommé. De plus, pour chaque hôte, on peut spécifier un
si l'un pour une raison quelconque exécute le xmlsysd sur un port différent de son
défaut d'installation.

Cette information peut facilement être surspécifiée. Dans la plupart des cas, par exemple, il vaut mieux
utilisez simplement le port par défaut (7887) et laissez la recherche d'adresse IP du nom d'hôte local s'occuper de
déterminer le numéro IP de l'interface. Notez que xml ne se soucie pas de la façon dont les balises sont disposées
tant qu'ils sont correctement imbriqués et qu'il peut y avoir plus d'un ,
, ou jeu de balises dans un wulfhosts pour spécifier la surveillance simultanée de
n'importe quel mélange d'hôtes, de clusters, de réseaux locaux.

Notez également que xml préserve les espaces, donc

b0

n'est PAS la même chose

b0

et ne fonctionnerait probablement pas correctement. Si vous entrez le port, le nom et l'adresse IP explicitement et
de manière incorrecte ou incohérente, préparez-vous à un comportement étrange.

Les est, espérons-le, explicite. Il peut être utilisé pour définir rapidement un
cluster sur la base d'un classement systématique des noms d'hôtes. Le contenu du
La balise doit être une chaîne SIMPLE au format printf pour un entier présumé qui sera itéré
de à par pas d'un. De cette façon, une seule balise xml peut définir un ensemble
cluster, par exemple g01-g15.

Les est similaire, sauf qu'il utilise le numéro ip directement dans et .
Soyez prudent - dans presque tous les cas, les trois premiers tuples du numéro IP doivent être les
MÊME dans et . Cette option est fournie au cas où les hôtes n'ont pas de
nom d'hôte défini et publié et ne sont accessibles que par exemple par le numéro IP attribué par DHCP dans
n'importe quel evenement.

Toutes les formes de définition d'un hôte ou d'une liste d'hôtes permettent une option être affecté à
remplacer la valeur par défaut d'installation de xmlsysd de 7887.

wulfstat se connectera à ces hôtes aussi vite que possible dans un thread parallèle, puis
essayez périodiquement de vous reconnecter à tous les hôtes qui pourraient être en panne ou qui pourraient tomber
pendant que wulfstat est en cours d'exécution. wulfstat lui-même est donc modérément robuste contre le nœud de cluster
changements d'état, bien que ce soit un domaine en cours de débogage (1/9/03).

wulfstat recherche un fichier wulfhosts utilisable à plusieurs endroits (dans l'ordre) :

AUCUN fichier wulfhosts (localhost uniquement) via l'indicateur -l ;
où il est dirigé par l'option de ligne de commande -f /path/to/wulfhosts ;
dans ./wulfhosts (dans le répertoire de travail actuel) ;
dans $HOME/.wulfhosts (dans le répertoire personnel, notez le ".");
dans le fichier pointé par la variable d'environnement WULFHOSTS ;
dans /etc/wulfhosts ;

et s'il ne trouve aucun d'entre eux, il essaie d'apparaître sur localhost.

Notez que tous les hôtes qui ne se résolvent pas sont affichés mais marqués inconnus. Tous les hôtes qui
résoudre mais qui ne peut pas accepter une connexion (ce qui pourrait signifier qu'aucun démon n'est installé
ou en cours d'exécution, le démon a plus de connexions que le nombre autorisé dans, par exemple
/etc/xinetd.d/xmlsysd, ou que l'hôte est en panne) sont marqués.

DISPLAY TYPES

Les types d'affichage suivants sont pris en charge par wulfstat :

0 - charge et état uniquement (par défaut), un affichage très utile pour le cluster
des opportunités
1 - stat -- informations et taux primaires dérivés de /proc/stat
2 - mémoire uniquement (similaire à l'exécution "libre" sur chaque hôte)
3 - tarifs du réseau
4 - l'heure affiche les horloges système, la disponibilité, le type de processeur et l'horloge
5 - interface "utilisateur" pour le suivi des tâches distribuées par nom d'utilisateur ou
nom de la tâche (expérimental).

Chacune de ces interfaces peut également être atteinte de manière interactive dans wulfstat en tapant le
première lettre comme indiqué dans le menu.

INTERACTIF COMMANDES

wulfstat permet également de sélectionner des éléments tels que le délai, le type d'affichage et la sortie avec un seul
frappes lorsque le focus de la souris est dans la fenêtre. Commandes à touche unique qu'il reconnaît
consistent à

quitter)

+/- incrémente ou décrémente l'horloge de retard, zéro est la valeur minimale autorisée et
fait tourner wulfstat aussi vite qu'il peut tourner, ce qui est utile pour créer un modeste
"charger" sur le processeur ou le réseau afin que vous puissiez voir le travail de wulfstat.

PgUp affiche la page suivante des hôtes
PgDn affiche la dernière page des hôtes
UpArrow fait défiler l'affichage vers le haut
DnArrow fait défiler l'affichage vers le bas

dans une file d'attente circulaire. À l'aide de ces touches, un utilisateur peut rapidement parcourir de très grandes
groupes.

l(oad) sélectionne l'affichage de la charge du processeur (probablement le plus utile)
m(emory) sélectionne l'affichage de la mémoire
n(etwork) sélectionne l'affichage de la charge du réseau
t(ime) sélectionne l'affichage de l'heure (et des informations sur le processeur)
u(ser) sélectionne l'interface de tâche utilisateur (expérimentale).

Enfin, s'il y a assez de place (il est recommandé d'utiliser wulfstat avec au moins
35x80 xterms ou plus), une fenêtre de débogage affichera rarement des messages intéressants. Départ
wulfstat avec une option -v augmentera le bruit dans cette fenêtre, mais ce n'est pas le cas
recommandé, sauf si vous déboguez la source wulfstat pour une raison quelconque.

DÉBOGAGE

Pour aider à déboguer wulfstat (ou les problèmes que vous pourriez avoir avec wulfhosts), notez le tableau de
valeurs détaillées/de débogage qui sont imprimées dans le cadre de son utilisation (indicateur -h). Cela donne
quoi que ce soit d'une simple trace d'un sous-système particulier tel que connect_hosts() à
tout ce que fait le programme. Pour limiter la sortie, on peut également utiliser le drapeau -c count pour
n'afficher qu'un seul cycle. C'est une bonne idée de diriger stderr dans un fichier journal séparément
de sorte que la sortie d'affichage ne soit pas modifiée. Le fichier journal peut être examiné plus tard ou renvoyé par courrier
à moi pour analyse.

Un exemple de ceci pourrait être :

wulfstat -l -c 1 -v 10 2>connect_hosts.log

pour tracer ce que wulfstat fait en se connectant à localhost.

Utilisez wulfstat en ligne en utilisant les services onworks.net