pegasus-monitord - En ligne dans le Cloud

PROGRAMME:

Nom

pegasus-monitord - suit la progression du flux de travail, les informations d'extraction

SYNOPSIS

moniteur-pégase [--Aidez-moi|-Aide] [--verbeux|-v]
[--régler|-a i] [--premier plan|-N]
[--no-démon|-n] [--travail|-j jobstate.log filet]
[--Journal|-l fichier journal] [--conf propriétés filet]
[--non-récursif] [--no-base de données | --pas d'événements]
[--rejouer|-r] [--aucune notification]
[--notifications-max max_notifications]
[--notifications-timeout temps mort]
[--sim|-s millisommeil] [--db-stats]
[--skip-stdout] [--Obliger|-f]
[--prise] [--rép-sortie | -o dir]
[--dest|-d PATH or URL] [--codage|-e bp | bson]
DAGMan sortie filet

DESCRIPTION

Ce programme suit un flux de travail, analysant la sortie du fichier dagman.out de DAGMAN. Dans
en plus de générer le fichier jobstate.log, moniteur-pégase peut aussi être utilisé le mien
les informations du fichier dag de workflow et des fichiers de soumission et de sortie des travaux, et soit
remplir une base de données ou écrire un fichier d'événements NetLogger avec ces informations.
moniteur-pégase peut également effectuer des notifications lors du suivi de la progression d'un flux de travail dans
temps réel.

OPTIONS

-h, --Aidez-moi
Imprime un résumé d'utilisation avec toutes les options de ligne de commande disponibles.

-v, --verbeux
Définit le niveau de journalisation pour moniteur-pégase. S'il est omis, la valeur par défaut niveau sera réglé sur
ATTENTION. Lorsque cette option est donnée, le niveau de journalisation est modifié en INFO. Si cette option
est répété, le niveau de journal sera modifié en DEBUG.

Le niveau de connexion moniteur-pégase peut également être ajusté de manière interactive, en envoyant le
USR1 et USR2 signaux au processus, respectivement pour incrémenter et décrémenter
le niveau de journalisation.

-a i, --régler i
Pour ajuster les différences de fuseau horaire en i secondes, la valeur par défaut est 0.

-N, --premier plan
Ne pas démoniser moniteur-pégase, faites les mouvements comme si (Condor).

-n, --no-démon
Ne pas démoniser moniteur-pégase, gardez-le au premier plan (pour le débogage).

-j jobstate.log filet, --travail jobstate.log filet
Emplacement alternatif pour le jobstate.log déposer. La valeur par défaut est d'écrire un jobstate.log
dans le répertoire de workflow. Un nom de fichier absolu ne doit être utilisé que si le workflow
n'a pas de sous-workflow, car chaque sous-workflow générera son propre
jobstate.log déposer. Si un nom de fichier alternatif, non absolu, est donné avec ce
option, moniteur-pégase créera un fichier dans chaque workflow (et sous-workflow)
répertoire avec le nom de fichier fourni par l'utilisateur avec cette option. Si un absolu
le nom de fichier est fourni et des sous-workflows sont trouvés, un message d'avertissement sera imprimé
et moniteur-pégase ne suivra aucun sous-workflow.

--Journal fichier journal, --fichier journal fichier journal
Spécifie une alternative fichier journal à utiliser à la place du monitoré.log fichier dans le fichier principal
répertoire de flux de travail. Différemment du jobstate.log fichier ci-dessus, moniteur-pégase
n'en génère qu'un fichier journal par exécution (et non un par workflow et sous-workflow il
des pistes).

--conf fichier_propriétés
est un fichier alternatif contenant des propriétés dans le key = format et permet aux utilisateurs
pour remplacer les valeurs lues à partir du braindump.txt déposer. Cette option a priorité sur
le fichier de propriétés spécifié dans le braindump.txt déposer. Veuillez noter que ces
les propriétés s'appliqueront non seulement au workflow principal, mais également à tous les sous-workflows
trouvé.

--non-récursif
Cette option désactive moniteur-pégase pour suivre automatiquement tous les sous-workflows qui
sont trouvés.

--nodatabase, --no-base de données, --pas d'événements
Désactive la génération d'événements (lorsque cette option est donnée, moniteur-pégase sera seulement
générer le fichier jobstate.log). La valeur par défaut est d'enregistrer automatiquement les informations dans un
Base de données SQLite (voir le --dest option ci-dessous pour plus de détails). Cette option remplace
tout paramètre donné par le --dest option.

-r, --rejouer
Cette option est utilisée pour relire la sortie d'un workflow déjà terminé. Cela devrait
être utilisé uniquement une fois le flux de travail terminé (pas nécessairement avec succès). Si un
jobstate.log fichier est trouvé, il sera pivoté. Cependant, lors de l'utilisation d'une base de données, tous
les références précédentes à ce workflow (et à tous ses sous-workflows) seront effacées de
ce. Lors de la sortie vers un fichier bp, le fichier sera supprimé. Lors de l'exécution en replay
Mode, moniteur-pégase fonctionnera toujours avec le --no-démon option, et toutes les erreurs
sera envoyé directement au terminal. Aussi, moniteur-pégase ne traitera aucun
notifications en mode de relecture.

--aucune notification
Cette option désactive complètement les notifications, ce qui rend moniteur-pégase ignorer tous les
.notify fichiers pour tous les flux de travail qu'il suit.

--notifications-max max_notifications
Cette option définit le nombre maximum de notifications simultanées qui moniteur-pégase
va commencer. Quand le max_notifications la limite est atteinte, moniteur-pégase fera la queue
notifications et attendez qu'un script de notification en attente se termine avant de lancer une
nouveau. Si max_notifications est défini sur 0, les notifications seront désactivées.

--notifications-timeout temps mort
Normalement, moniteur-pégase lancera un script de notification et attendra indéfiniment
ça pour finir. Cette option permet aux utilisateurs de définir un maximum temps mort qui
moniteur-pégase attendra la fin d'un script de notification avant de le terminer.
Si les scripts de notification ne se terminent pas dans un délai raisonnable, cela peut entraîner
d'autres scripts de notification à mettre en file d'attente en raison du nombre maximal de
scripts autorisés par moniteur-pégase. De plus, jusqu'à ce que tous les scripts de notification
terminer, moniteur-pégase ne se terminera pas.

-s millisommeil, --sim millisommeil
Cette option simule les délais entre les lectures, en dormant millisommeil millisecondes. Cette
L'option est principalement utilisée par les développeurs.

--db-stats
Cette option permet au module de base de données de collecter et d'imprimer les statistiques de la base de données au
fin de l'exécution. Il n'a aucun effet si le --no-base de données option est donnée.

--skip-stdout
Cette option provoque moniteur-pégase de ne pas remplir les tâches stdout et stderr dans le
BP ou la base de données Stampede. Il doit être utilisé pour éviter d'augmenter la base de données
taille substantielle dans les cas où les travaux sont très verbeux dans leur sortie.

-f, --Obliger
Cette option provoque moniteur-pégase pour ignorer la recherche d'une autre instance de lui-même
s'exécutant déjà sur le même répertoire de workflow. Le comportement par défaut empêche deux ou
plus moniteur-pégase instances de démarrer et de s'exécuter simultanément (ce qui
le fichier bp et la base de données restent dans un état instable). Cette option devrait
ne doit être utilisé que lorsque l'utilisateur connaît l'instance précédente de moniteur-pégase is ne pas
courir plus.

--prise
Cette option provoque moniteur-pégase pour démarrer une interface socket qui peut être utilisée pour
débogage avancé. Le numéro de port pour la connexion à moniteur-pégase peuvent être trouvés dans
le monitor.sock dans le répertoire du workflow (le fichier est supprimé lorsque
moniteur-pégase finitions). Si ce n'est déjà fait, l'interface socket est également
créé quand moniteur-pégase reçoit un USR1 signal.

-o dir, --rép-sortie dir
Lorsque cette option est donnée, moniteur-pégase créera tous ses fichiers de sortie dans le
répertoire spécifié par Dir. Cette option est utile pour permettre à un utilisateur de déboguer un
workflow dans un répertoire, l'utilisateur n'a pas d'autorisations d'écriture. Dans ce cas, tout
fichiers générés par moniteur-pégase aura le flux de travail wf_uuid comme préfixe pour que
les fichiers de plusieurs sous-workflows peuvent être placés dans le même répertoire. Cette option est
principalement utilisé par analyseur-pegasus. Il est important de noter que l'emplacement du
le fichier BP ou la base de données de sortie n'est pas modifié par cette option et doit être défini via le
--dest option.

-d URL params, --dest URL params
Cette option permet aux utilisateurs de spécifier la destination des événements de journal générés par
moniteur-pégase. Si cette option est omise, moniteur-pégase va créer un SQLite
base de données dans le répertoire d'exécution du workflow avec le même nom que le workflow, mais avec
a .stampede.db préfixe. Pour un vide schème, params sont un chemin de fichier avec - sens
sortie standard. Pour un x-tcp schème, params Hôte_TCP[:port=14380]. Pour une base de données
schème, params sont un SQLAlchemy moteur URL avec une chaîne de connexion à la base de données qui peut
être utilisé pour spécifier différents moteurs de base de données. Veuillez consulter la section des exemples ci-dessous
pour plus d'informations sur l'utilisation de cette option. Notez que lors de l'utilisation d'un moteur de base de données
autre que sqlite, les pilotes de base de données Python nécessaires devront être installés.

-e codage, --codage codage
Cette option spécifie comment coder les événements de journal. Les deux possibilités disponibles sont bp
et bson. Si cette option n'est pas spécifiée, des événements seront générés dans le bp le format.

DAGMan_output_file
La DAGMan_output_file est le seul argument de ligne de commande requis dans moniteur-pégase
et doit avoir le .dag.dagman.out extension.

RETOUR VALEURE

Si le plan pouvait être construit, moniteur-pégase renvoie avec un code de sortie de 0.
Cependant, en cas d'erreur, un code de sortie différent de zéro indique des problèmes. Dans ce cas, le
fichier journal doit contenir des informations supplémentaires sur la condition d'erreur.

ENVIRONNEMENT VARIABLES

moniteur-pégase ne nécessite pas la définition de variables environnementales. Il localise son
modules Python requis en fonction de son propre emplacement et ne doivent donc pas être déplacés
en dehors du répertoire bin de Pegasus.

EXEMPLES

Habituellement, moniteur-pégase est invoqué automatiquement par pégase et suit le flux de travail
progrès en temps réel, produisant le jobstate.log fichier et un SQLite correspondant
base de données. Lorsqu'un workflow échoue et est soumis à nouveau avec un DAG de secours, moniteur-pégase
reprendra automatiquement là où il était parti précédemment et continuera le jobstate.log
fichier et la base de données.

Si les utilisateurs doivent créer le jobstate.log fichier après qu'un workflow est déjà terminé, le
--rejouer | -r L'option doit être utilisée lors de l'exécution moniteur-pégase manuellement. Par example:

$ pegasus_monitord -r diamant-0.dag.dagman.out

Va lancer moniteur-pégase en mode relecture. Dans ce cas, si un jobstate.log fichier déjà
existe, il sera pivoté et un nouveau fichier sera créé. Si un diamant-0.stampede.db
La base de données SQLite existe déjà, moniteur-pégase purgera toutes les références au workflow
identifiant spécifié dans le braindump.txt fichier, y compris tous les sous-workflows associés à ce
identifiant de flux de travail.

$ pegasus_monitord -r --no-database diamant-0.dag.dagman.out

fera la même chose, mais sans générer d'événements de journal.

$ pegasus_monitord -r --dest `pwd`/diamond-0.bp diamant-0.dag.dagman.out

va créer le fichier diamant-0.bp dans le répertoire courant, contenant les événements NetLogger
avec toutes les données de workflow. Ceci s'ajoute à la jobstate.log fichier.

Pour utiliser une base de données, les utilisateurs doivent fournir une chaîne de connexion à la base de données au format :

dialect://nom d'utilisateur:mot de passe@hôte:port/base de données

Où dialecte est le nom du pilote sous-jacent (mysql, sqlite, oracle, postgres) et
base de données est le nom de la base de données s'exécutant sur le serveur au hôte l'ordinateur.

Si les utilisateurs souhaitent utiliser un autre SQLite base de données, moniteur-pégase les oblige à
spécifiez le chemin absolu du fichier alternatif. Par example:

$ pegasus_monitord -r --dest sqlite:////home/user/diamond_database.db diamant-0.dag.dagman.out

Voici des documents avec des détails pour tous les pilotes pris en charge :
http://www.sqlalchemy.org/docs/05/reference/dialects/index.html

Des options supplémentaires par base de données qui fonctionnent dans les chaînes de connexion y sont décrites.

Il est important de noter qu'il faudra disposer de la bibliothèque d'interface de base de données appropriée
installée. C'est-à-dire, SQLAlchemy est un wrapper autour de la bibliothèque d'interface mysql
(par exemple), il ne fournit pas de MySQL conducteur lui-même. le Pegasus distribution
comprend à la fois SQLAlchemy et du SQLite Pilote Python.

Comme note finale, il est important de mentionner que contrairement à l'utilisation SQLite bases de données, utilisation
SQLAlchemy avec d'autres serveurs de bases de données, par exemple MySQL or Postgres, la base de données cible a besoin
exister. Ainsi, si un utilisateur souhaite se connecter à :

mysql://pegasus-user:supersecret@localhost:localport/diamond

il faudrait d'abord se connecter au serveur à localhost et émettre la création appropriée
commande de base de données avant l'exécution moniteur-pégase as SQLAlchemy s'occupera de créer
les tables et les index s'ils n'existent pas déjà.

Utilisez pegasus-monitord en ligne en utilisant les services onworks.net