Guide De Ligne De Commande
SR3 - Tout
sr3 est un outil de ligne de commande pour gérer les configurations Sarracenia individuellement ou en groupe. Pour l’utilisateur actuel, il lit sur tous les fichiers de configuration, des fichiers d’état et consulte la table de processus pour déterminer l’état de tous les composants. Il effectue ensuite la modification demandée.
sr3 options action [ composant/configuration … ]
Les composants sr3 sont utilisés pour publier et télécharger des fichiers à partir de sites Web ou de serveurs de fichiers qui fournissent des sr3_post(7). Ces sites publient des messages pour chaque fichier dès qu’il est disponible. Les clients se connectent à un broker (souvent le même que le serveur) et s’abonnent aux notifications. Les notifications sr3_post fournissent de véritables notifications push pour les dossiers accessibles sur le Web (WAF), et sont beaucoup plus efficaces que l’interrogation périodique des répertoires ou le style ATOM/RSS de notifications. Sr_subscribe peut être configuré pour publier des messages après leur téléchargement, les mettre à la disposition des consommateurs pour un traitement ultérieur ou des transferts.
sr3 peut également être utilisé à des fins autres que le téléchargement (par exemple, pour fourniture à un programme externe) en spécifiant le -n (égal à : download off) supprimer le comportement de téléchargement et publier uniquement l’URL sur la sortie standard. La sortie standard peut être redirigée vers d’autres processus dans le style de filtre de texte UNIX classique.
Les composants de sarracenia sont des groupes de valeurs choisi par défaut sur l’algorithme principal, pour réduire la taille des composants individuels. Les composants sont les suivants :
cpump - copier des messages d’une pompe a une autre (une implémentation C d’un shovel.)
flow - flux générique sans comportement par défaut. Bonne base pour créer un composant défini par l’utilisateur
poll - interroger un serveur Web ou de fichiers non sarracenia pour créer des messages à traiter.
post & watch - créer des messages pour les fichiers à traiter.
sarra - télécharger le fichier d’un serveur distant vers le serveur local et les republier pour d’autres.
sender - envoyer des fichiers d’un serveur local à un serveur distant.
shovel - copier des messages, uniquement, pas des fichiers.
watch - créer des messages pour chaque nouveau fichier qui arrive dans un répertoire ou à un chemin défini.
winnow - copier des messages, en supprimant les doublons.
Tous ces composants acceptent les mêmes options, avec les mêmes effets. Il existe également des sr3_cpump(1). qui est une version C qui implémente un sous-ensemble des options ici, mais là où elles sont implémentées, elles ont le même effet.
La commande sr3 prend généralement deux arguments : une action suivie d’une liste de fichiers de configuration. Lorsqu’un composant est appelé, une opération et un fichier de configuration sont spécifiés. Si la configuration est omise, cela signifie que l’action s’applique à toutes les configurations. L’action est l’une des suivantes :
foreground: exécuter une seule instance au premier plan, écrivant le journal à l´erreur standard.
restart: arrêter puis démarrer la configuration.
sanity: recherche les instances qui se sont plantées ou ont bloqué et les redémarre.
start: démarrer la configuration
status: vérifier si la configuration est en cours d’exécution.
stop: arrêter la configuration.
Les actions restantes gèrent les ressources (échanges, files d’attente) utilisées par le composant sur le courtier ou pour gérer les configurations.
cleanup: supprime les ressources du composant sur le serveur
declare: crée les ressources du composant sur le serveur.
add: copie une configuration à la liste des configurations disponibles.
list: Énumérer toutes les configurations disponibles.
list plugins: Énumérer toutes les plugins disponibles.
list examples: Énumérer toutes les exemples disponibles.
show voir une version interpreté d’un fichier de configuration.
edit: modifier une configuration existante.
remove: Supprimer une configuration
disable: marquer une configuration comme non éligible à l’exécution.
enable: marquer une configuration comme éligible à l’exécution.
convert: convertir une configuration de la version2 à la version3
Par exemple: sr_subscribe foreground dd exécute une instance du composant sr_subscribe en avant plan en se servant de la configuration dd.
L’action foreground est utilisée lors de la construction d’une configuration ou pour le débogage. L’instance foreground sera exécutée indépendamment des autres instances qui sont en cours d’exécution. Si des instances sont en cours d’exécution, il partage la même fil d’attente d’avis avec eux. Un utilisateur arrête l’instance foreground en utilisant simplement <ctrl-c> sur linux. ou utilise d’autres moyens pour tuer le processus.
Une fois qu’une configuration a été affinée, start lance le composant en tant que service d’arrière-plan (démon ou flotte de démons dont le numéro est contrôlé par l’option instances). Si plusieurs configurations et composants doivent être exécutés ensemble, l’ensemble de la flotte peut être contrôlé de la même manière à l’aide de la commande sr3(1)..
Pour que les composants roulent tous en meme temps,sur Linux on peut utiliser l’intégration systemd , comme décrit dans Admin Guide . Sur Windows, il est possible de configurer un service, comme décrit dans Windows user manual
Les actions cleanup, declare, peuvent être utilisées pour gérer les ressources sur le courtier rabbitmq. Les ressources sont soit des files d’attente, soit des échanges. declare crée les ressources.
Les actions add, remove, list, edit, enable & disable sont utilisées pour gérer la liste de configurations et plugins. On peut voir toutes les configurations disponibles en utilisant l´action list. et les plugins disponibles avec list plugins. En utilisant l’option edit, on peut travailler sur une configuration particulière. Une configuration disabled ne sera pas démarrée ou redémarrée par les actions start ou restart. Cela peut être utilisé pour mettre une configuration temporairement de côté.
L’option convert est utilisé pour traduire une configuration écrite avec des options de la version2 de Sarracenia, avec des options de la version3. Le fichier de configuration de la version2 doit etre placé dans le réportoire ~/.config/sarra/composant/v2_config.conf et la version traduite sera placé dans le répertoire ~/.config/sr3/composant/v3_config.conf. Pas exemple, cette action serais invoqué avec sr3 convert composant/config.
ACTIONS
declare
Appeler la fonction correspondante pour chacune des configurations:
$ sr3 declare
declare: 2020-09-06 23:22:18,043 [INFO] root declare looking at cpost/pelle_dd1_f04
2020-09-06 23:22:18,048 [INFO] sarra.moth.amqp __putSetup exchange declared: xcvan00 (as: amqp://tfeed@localhost/)
2020-09-06 23:22:18,049 [INFO] sarra.moth.amqp __putSetup exchange declared: xcvan01 (as: amqp://tfeed@localhost/)
2020-09-06 23:22:18,049 [INFO] root declare looking at cpost/veille_f34
2020-09-06 23:22:18,053 [INFO] sarra.moth.amqp __putSetup exchange declared: xcpublic (as: amqp://tfeed@localhost/)
2020-09-06 23:22:18,053 [INFO] root declare looking at cpost/pelle_dd2_f05
...
2020-09-06 23:22:18,106 [INFO] root declare looking at cpost/pelle_dd2_f05
2020-09-06 23:22:18,106 [INFO] root declare looking at cpump/xvan_f14
2020-09-06 23:22:18,110 [INFO] sarra.moth.amqp __getSetup queue declared q_tfeed.sr_cpump.xvan_f14.23011811.49631644 (as: amqp://tfeed@localhost/)
2020-09-06 23:22:18,110 [INFO] sarra.moth.amqp __getSetup um..: pfx: v03, exchange: xcvan00, values: #
2020-09-06 23:22:18,110 [INFO] sarra.moth.amqp __getSetup binding q_tfeed.sr_cpump.xvan_f14.23011811.49631644 with v03.# to xcvan00 (as: amqp://tfeed@localhost/)
2020-09-06 23:22:18,111 [INFO] root declare looking at cpump/xvan_f15
2020-09-06 23:22:18,115 [INFO] sarra.moth.amqp __getSetup queue declared q_tfeed.sr_cpump.xvan_f15.50074940.98161482 (as: amqp://tfeed@localhost/)
Déclare les files d’attente et les échanges liés à chaque configuration. On peut également l’appeler avec --users, afin qu’il déclare les utilisateurs ainsi que les échanges et les files d’attente:
$ sr3 --users declare
2020-09-06 23:28:56,211 [INFO] sarra.rabbitmq_admin add_user permission user 'ender' role source configure='^q_ender.*|^xs_ender.*' write='^q_ender.*|^xs_ender.*' read='^q_ender.*|^x[lrs]_ender.*|^x.*public$'
...
La fourniture d’un ou de plusieurs flux ne déclarera que les utilisateurs spécifiés dans le(s) flux:
$ sr3 --users declare subscribe/dd_amis
...
declare: 2024-05-17 20:02:18,548 434920 [INFO] sarracenia.rabbitmq_admin add_user permission user 'tfeed@localhost' role feeder configure=.* write=.* read=.*
...
dump
imprimer les trois structures de données utilisées par sr. Il existe trois listes :
processus considérés comme liés à sr.
configurations présentes
contenu des fichiers d’état.
dump est utilisé pour le débogage ou pour obtenir plus de détails que ce qui est fourni par status:
Running Processes
4238: name:sr_poll.py cmdline:['/usr/bin/python3', '/home/peter/src/sarracenia/sarra/sr_poll.py', '--no', '1', 'start', 'pulse']
.
.
.
Configs
cpost
veille_f34 : {'status': 'running', 'instances': 1}
States
cpost
veille_f34 : {'instance_pids': {1: 4251}, 'queue_name': None, 'instances_expected': 0, 'has_state': False, 'missing_instances': []}
Missing
C’est assez long, et donc un peu trop d’informations à regarder à l’état brut. Généralement utilisé en conjonction avec des filtres Linux, tels que grep. par exemple:
$ sr3 dump | grep stopped
WMO_mesh_post : {'status': 'stopped', 'instances': 0}
shim_f63 : {'status': 'stopped', 'instances': 0}
test2_f61 : {'status': 'stopped', 'instances': 0}
$ sr3 dump | grep disabled
amqp_f30.conf : {'status': 'disabled', 'instances': 5}
fournit une méthode simple pour déterminer quelles configurations sont dans un état particulier. Autre exemple, si sr3 status signale que l’expéditeur/tsource2send_f50 est partiel, alors on peut utiliser dump pour obtenir plus de détails:
$ sr3 dump | grep sender/tsource2send_f50
49308: name:sr3_sender.py cmdline:['/usr/bin/python3', '/usr/lib/python3/dist-packages/sarracenia/instance.py', '--no', '1', 'start', 'sender/tsource2send_f50']
q_tsource.sr_sender.tsource2send_f50.58710892.12372870: ['sender/tsource2send_f50']
foreground
exécuter une seule instance d’une configuration unique en tant que processus interactif de journalisation à la sortie stderr/terminal actuelle. pour le débogage.
list
montre à l’utilisateur les fichiers de configuration présents
$ sr3 list
User Configurations: (from: /home/peter/.config/sarra )
cpost/pelle_dd1_f04.conf cpost/pelle_dd2_f05.conf cpost/veille_f34.conf
cpump/xvan_f14.conf cpump/xvan_f15.conf poll/f62.conf
post/shim_f63.conf post/t_dd1_f00.conf post/t_dd2_f00.conf
post/test2_f61.conf sarra/download_f20.conf sender/tsource2send_f50.conf
shovel/rabbitmqtt_f22.conf subscribe/amqp_f30.conf subscribe/cclean_f91.conf
subscribe/cdnld_f21.conf subscribe/cfile_f44.conf subscribe/cp_f61.conf
subscribe/ftp_f70.conf subscribe/q_f71.conf subscribe/rabbitmqtt_f31.conf
subscribe/u_sftp_f60.conf watch/f40.conf admin.conf
credentials.conf default.conf
logs are in: /home/peter/.cache/sarra/log
La dernière ligne indique dans quel répertoire se trouvent les fichiers journaux.
list examples montre également les modèles de configuration inclus disponibles comme points de départ avec l’action add
$ sr3 list examples
Sample Configurations: (from: /home/peter/Sarracenia/development/sarra/examples )
cpump/cno_trouble_f00.inc poll/aws-nexrad.conf poll/pollingest.conf
poll/pollnoaa.conf poll/pollsoapshc.conf poll/pollusgs.conf
poll/pulse.conf post/WMO_mesh_post.conf sarra/wmo_mesh.conf
sender/ec2collab.conf sender/pitcher_push.conf shovel/no_trouble_f00.inc
subscribe/WMO_Sketch_2mqtt.conf subscribe/WMO_Sketch_2v3.conf subscribe/WMO_mesh_CMC.conf
subscribe/WMO_mesh_Peer.conf subscribe/aws-nexrad.conf subscribe/dd_2mqtt.conf
subscribe/dd_all.conf subscribe/dd_amis.conf subscribe/dd_aqhi.conf
subscribe/dd_cacn_bulletins.conf subscribe/dd_citypage.conf subscribe/dd_cmml.conf
subscribe/dd_gdps.conf subscribe/dd_ping.conf subscribe/dd_radar.conf
subscribe/dd_rdps.conf subscribe/dd_swob.conf subscribe/ddc_cap-xml.conf
subscribe/ddc_normal.conf subscribe/downloademail.conf subscribe/ec_ninjo-a.conf
subscribe/hpfx_amis.conf subscribe/local_sub.conf subscribe/pitcher_pull.conf
subscribe/sci2ec.conf subscribe/subnoaa.conf subscribe/subsoapshc.conf
subscribe/subusgs.conf watch/master.conf watch/pitcher_client.conf
watch/pitcher_server.conf watch/sci2ec.conf
$ sr3 add dd_all.conf
add: 2021-01-24 18:04:57,018 [INFO] sarracenia.sr add copying: /usr/lib/python3/dist-packages/sarracenia/examples/subscribe/dd_all.conf to /home/peter/.config/sr3/subscribe/dd_all.conf
$ sr3 edit dd_all.conf
Les actions add, remove, list, edit, enable & disable sont utilisées pour gérer la liste des configurations. On peut voir toutes les configurations disponibles en utilisant l’action list. Pour afficher les plugins disponibles, utilisez list plugins. À l’aide de l’option edit, on peut travailler sur une configuration particulière. Un disabled met une configuration de côté (en ajoutant .off au nom) afin qu’elle ne soit pas démarrée ou redémarrée par les actions start, foreground ou restart.
show
Afficher tous les paramètres de configuration (le résultat de toutes les analyses… ce que les composants du flux voient réellement)
% sr3 show subscribe/q_f71
2022-03-20 15:30:32,507 1084652 [INFO] sarracenia.config parse_fil download_f20.conf:35 obsolete v2:"on_message msg_log" converted to sr3:"logEvents after_accept"
2022-03-20 15:30:32,508 1084652 [INFO] sarracenia.config parse_file tsource2send_f50.conf:26 obsolete v2:"on_message msg_rawlog" converted to sr3:"logEvents after_accept"
2022-03-20 15:30:32,508 1084652 [INFO] sarracenia.config parse_file rabbitmqtt_f22.conf:6 obsolete v2:"on_message msg_log" converted to sr3:"logEvents after_accept"
Config of subscribe/q_f71:
{'_Config__admin': 'amqp://bunnymaster@localhost/ None True True False False None None',
'_Config__broker': 'amqp://tsource@localhost/ None True True False False None None',
'_Config__post_broker': None,
'accelThreshold': 0,
'acceptSizeWrong': False,
'acceptUnmatched': False,
'admin': 'amqp://bunnymaster@localhost/ None True True False False None None',
'attempts': 3,
'auto_delete': False,
'baseDir': None,
'baseUrl_relPath': False,
'batch': 1,
'bindings': [('xs_tsource_poll', ['v03', 'post'], ['#'])],
'broker': 'amqp://tsource@localhost/ None True True False False None None',
'bufsize': 1048576,
'byteRateMax': None,
'cfg_run_dir': '/home/peter/.cache/sr3/subscribe/q_f71',
'component': 'subscribe',
'config': 'q_f71',
'currentDir': None,
'debug': False,
'declared_exchanges': [],
'declared_users': {'anonymous': 'subscriber', 'eggmeister': 'subscriber', 'ender': 'source', 'tfeed': 'feeder', 'tsource': 'source', 'tsub': 'subscriber'},
'delete': False,
'destfn_script': None,
'directory': '//home/peter/sarra_devdocroot/recd_by_srpoll_test1',
'discard': False,
'documentRoot': None,
'download': True,
'durable': True,
'env_declared': ['FLOWBROKER', 'MQP', 'SFTPUSER', 'TESTDOCROOT'],
'exchange': 'xs_tsource_poll',
'exchangeDeclare': True,
'exchangeSuffix': 'poll',
'expire': 1800.0,
'feeder': ParseResult(scheme='amqp', netloc='tfeed@localhost', path='/', params='', query='', fragment=''),
'fileEvents': {'create', 'link', 'modify', 'delete', 'mkdir', 'rmdir' },
'file_total_interval': '0',
'filename': 'WHATFN',
'fixed_headers': {},
'flatten': '/',
'hostdir': 'fractal',
'hostname': 'fractal',
'housekeeping': 300,
'imports': [],
'inflight': None,
'inline': False,
'inlineByteMax': 4096,
'inlineEncoding': 'guess',
'inlineOnly': False,
'instances': 1,
'identity_arbitrary_value': None,
'identity_method': 'sha512',
'logEvents': {'after_work', 'after_accept', 'on_housekeeping'},
'logFormat': '%(asctime)s [%(levelname)s] %(name)s %(funcName)s %(message)s',
'logLevel': 'info',
'logReject': False,
'logRotateCount': 5,
'logRotateInterval': 86400,
'logStdout': True,
'log_flowcb_needed': False,
'masks': ['accept .* into //home/peter/sarra_devdocroot/recd_by_srpoll_test1 with mirror:True strip:.*sent_by_tsource2send/'],
'messageAgeMax': 0,
'messageCountMax': 0,
'messageDebugDump': False,
'messageRateMax': 0,
'messageRateMin': 0,
'message_strategy': {'failure_duration': '5m', 'reset': True, 'stubborn': True},
'message_ttl': 0,
'mirror': True,
'msg_total_interval': '0',
'fileAgeMax': 0,
'nodupe_ttl': 0,
'overwrite': True,
'permCopy': True,
'permDefault': 0,
'permDirDefault': 509,
'permLog': 384,
'plugins_early': [],
'plugins_late': ['sarracenia.flowcb.log.Log'],
'post_baseDir': None,
'post_baseUrl': None,
'post_broker': None,
'post_documentRoot': None,
'post_exchanges': [],
'post_topicPrefix': ['v03', 'post'],
'prefetch': 25,
'pstrip': '.*sent_by_tsource2send/',
'queueBind': True,
'queueDeclare': True,
'queueName': 'q_tsource_subscribe.q_f71.76359618.62916076',
'queue_filename': '/home/peter/.cache/sr3/subscribe/q_f71/subscribe.q_f71.tsource.qname',
'randid': 'cedf',
'randomize': False,
'realpathPost': False,
'rename': None,
'report': False,
'reset': False,
'resolved_qname': 'q_tsource_subscribe.q_f71.76359618.62916076',
'retry_ttl': 1800.0,
'settings': {},
'sleep': 0.1,
'statehost': False,
'strip': 0,
'subtopic': [],
'timeCopy': True,
'timeout': 300,
'timezone': 'UTC',
'tls_rigour': 'normal',
'topicPrefix': ['v03', 'post'],
'undeclared': ['msg_total_interval', 'file_total_interval'],
'users': False,
'v2plugin_options': [],
'v2plugins': {'plugin': ['msg_total_save', 'file_total_save']},
'vhost': '/',
'vip': []}
%
convert
Conversion d’une configuration : les deux formats sont acceptés, ainsi que les fichiers d’inclusion (.inc)
$ sr3 convert poll/sftp_f62
2022-06-14 15:00:00,762 1093345 [INFO] root convert converting poll/sftp_f62 from v2 to v3
$ sr3 convert poll/sftp_f62.conf
2022-06-14 15:01:11,766 1093467 [INFO] root convert converting poll/sftp_f62.conf from v2 to v3
$ sr3 convert shovel/no_trouble_f00.inc
2022-06-14 15:03:29,918 1093655 [INFO] root convert converting shovel/no_trouble_f00.inc from v2 to v3
Pour écraser une configuration SR3 existante, utilisez l’option –wololo. Lors de l’écrasement de plusieurs configurations SR3 est voulu, il faut également utiliser –dangerWillRobinson=n dans le mode normale… où n est le nombre de configurations à convertir.
start
lancer tous les composants configurés:
$ sr3 start
gathering global state: procs, configs, state files, logs, analysis - Done.
starting...Done
stop
arrêter tous les processus:
$ sr3 stop
gathering global state: procs, configs, state files, logs, analysis - Done.
stopping........Done
Waiting 1 sec. to check if 93 processes stopped (try: 0)
All stopped after try 0
status
Exemple d’état OK (sr3 est en cours d’exécution)
fractal% sr3 status
status:
Component/Config Processes Connection Lag Rates
State Run Retry msg data Queued LagMax LagAvg Last %rej pubsub messages RxData TxData
----- --- ----- --- ---- ------ ------ ------ ---- ---- ------ -------- ------ ------
cpost/veille_f34 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s
cpump/pelle_dd1_f04 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 31.3% 0 Bytes/s 4 msgs/s 0 Bytes/s 0 Bytes/s
cpump/pelle_dd2_f05 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 31.3% 0 Bytes/s 4 msgs/s 0 Bytes/s 0 Bytes/s
cpump/xvan_f14 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s
cpump/xvan_f15 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s
poll/f62 run 1/1 0 100% 0% 0 0.08s 0.04s 1.4s 0.0% 2.0 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s
post/shim_f63 stop 0/0 - - - - - - -
post/test2_f61 stop 0/0 0 100% 0% 0 0.02s 0.01s 0.4s 0.0% 8.1 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s
sarra/download_f20 run 3/3 0 100% 10% 0 13.17s 5.63s 1.8s 0.0% 5.4 KiB/s 4 msgs/s 1.7 KiB/s 0 Bytes/s
sender/tsource2send_f50 run 10/10 0 100% 9% 0 1.37s 1.08s 1.9s 0.0% 8.1 KiB/s 5 msgs/s 0 Bytes/s 1.7 KiB/s
shovel/pclean_f90 run 3/3 136 100% 0% 0 0.00s 0.00s 0.6s 0.0% 4.0 KiB/s 5 msgs/s 0 Bytes/s 0 Bytes/s
shovel/pclean_f92 run 3/3 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s
shovel/rabbitmqtt_f22 run 3/3 0 100% 0% 0 0.89s 0.67s 1.5s 0.0% 8.1 KiB/s 5 msgs/s 0 Bytes/s 0 Bytes/s
shovel/t_dd1_f00 run 3/3 0 100% 0% 124 23.15s 4.50s 0.1s 55.0% 3.9 KiB/s 9 msgs/s 0 Bytes/s 0 Bytes/s
shovel/t_dd2_f00 run 3/3 0 100% 0% 83 11.82s 3.50s 0.1s 49.2% 3.6 KiB/s 8 msgs/s 0 Bytes/s 0 Bytes/s
subscribe/amqp_f30 run 3/3 0 100% 12% 0 18.79s 9.22s 0.1s 0.0% 3.3 KiB/s 4 msgs/s 1.9 KiB/s 0 Bytes/s
subscribe/cclean_f91 run 3/3 145 100% 0% 1 0.00s 0.00s 0.4s 0.0% 2.3 KiB/s 6 msgs/s 0 Bytes/s 0 Bytes/s
subscribe/cdnld_f21 run 3/3 0 100% 17% 12 7.20s 2.81s 0.7s 0.0% 2.3 KiB/s 3 msgs/s 1.7 KiB/s 0 Bytes/s
subscribe/cfile_f44 run 3/3 0 100% 6% 1 3.32s 0.32s 0.4s 0.0% 2.3 KiB/s 6 msgs/s 1.7 KiB/s 0 Bytes/s
subscribe/cp_f61 run 3/3 0 100% 3% 0 6.42s 3.49s 1.6s 0.0% 4.2 KiB/s 6 msgs/s 635 Bytes/s 0 Bytes/s
subscribe/ftp_f70 run 3/3 0 100% 8% 0 1.18s 0.83s 0.2s 0.0% 1.8 KiB/s 3 msgs/s 1.8 KiB/s 0 Bytes/s
subscribe/q_f71 run 3/3 0 100% 0% 0 1.62s 0.57s 0.0s 0.0% 1.2 KiB/s 3 msgs/s 1.2 KiB/s 0 Bytes/s
subscribe/rabbitmqtt_f31 run 3/3 0 100% 11% 0 4.27s 1.95s 1.2s 0.0% 4.2 KiB/s 6 msgs/s 637 Bytes/s 0 Bytes/s
subscribe/u_sftp_f60 run 3/3 0 100% 1% 0 2.69s 2.23s 1.3s 0.7% 4.2 KiB/s 6 msgs/s 644 Bytes/s 0 Bytes/s
watch/f40 run 1/1 0 100% 0% 0 0.10s 0.05s 1.9s 0.0% 4.2 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s
winnow/t00_f10 run 1/1 0 100% 0% 0 12.31s 4.33s 3.5s 50.0% 3.2 KiB/s 3 msgs/s 0 Bytes/s 0 Bytes/s
winnow/t01_f10 run 1/1 0 100% 0% 0 11.59s 3.76s 0.1s 50.5% 4.2 KiB/s 4 msgs/s 0 Bytes/s 0 Bytes/s
Total Running Configs: 25 ( Processes: 64 missing: 0 stray: 0 )
Memory: uss:2.4 GiB rss:3.3 GiB vms:6.2 GiB
CPU Time: User:39.62s System:4.42s
Pub/Sub Received: 103 msgs/s (80.6 KiB/s), Sent: 63 msgs/s (32.8 KiB/s) Queued: 221 Retry: 281, Mean lag: 2.32s
Data Received: 32 Files/s (11.9 KiB/s), Sent: 5 Files/s (1.7 KiB/s)
fractal%
L’état au complet
fractal% sr3 --full status
status:
Component/Config Processes Connection Lag Rates Counters (per housekeeping) Data Counters Memory CPU Time
State Run Retry msg data Queued LagMax LagAvg Last %rej pubsub messages RxData TxData subBytes Accepted Rejected Malformed pubBytes pubMsgs pubMal rxData rxFiles txData txFiles Since uss rss vms user system
----- --- ----- --- ---- ------ ------ ------ ---- ---- ------ -------- ------ ------ ------- -------- -------- --------- ------- ------ ----- ----- ------- ------ ------- ----- --- --- --- ---- ------
cpost/veille_f34 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 0 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 121.40s 2.4 MiB 5.9 MiB 15.2 MiB 0.03 0.08
cpump/pelle_dd1_f04 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 83.5% 0 Bytes/s 11 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 1.4 Kim 1.1 Kim 0 msgs 0 Bytes 230 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 121.40s 3.9 MiB 6.8 MiB 17.2 MiB 0.12 0.11
cpump/pelle_dd2_f05 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 83.5% 0 Bytes/s 11 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 1.4 Kim 1.1 Kim 0 msgs 0 Bytes 230 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 121.40s 3.9 MiB 7.0 MiB 17.2 MiB 0.17 0.06
cpump/xvan_f14 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 0 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 12.90s 3.0 MiB 4.7 MiB 16.1 MiB 0.01 0.01
cpump/xvan_f15 run 1/1 0 100% 0% 0 0.00s 0.00s n/a 0.0% 0 Bytes/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 1 msg 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 8.63s 3.0 MiB 4.6 MiB 16.1 MiB 0.01 0.02
poll/f62 run 1/1 0 100% 0% 0 0.16s 0.05s 0.8s 0.0% 1.3 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 0 msgs 4.4 Kim 0 msgs 151.1 KiB 420 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 118.56s 45.1 MiB 59.0 MiB 229.3 MiB 2.62 0.32
post/shim_f63 stop 0/0 - - - - - - - - - - - - - - - - - - - 0 Bytes 0 Bytes 0 Bytes 0.00 0.00
post/test2_f61 stop 0/0 0 100% 0% 0 0.03s 0.02s 0.5s 0.0% 11.5 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 0 msgs 0 msgs 0 msgs 6.7 KiB 14 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 0.58s 0 Bytes 0 Bytes 0 Bytes 0.00 0.00
sarra/download_f20 run 3/3 0 100% 0% 0 10.17s 2.87s 1.1s 0.0% 1.1 KiB/s 0 msgs/s 1.1 KiB/s 0 Bytes/s 27.1 KiB 47 msgs 0 msgs 0 msgs 36.0 KiB 47 msgs 0 msgs 65.6 KiB 47 Files 0 Bytes 0 Files 57.57s 132.5 MiB 192.4 MiB 280.1 MiB 2.72 0.40
sender/tsource2send_f50 run 10/10 0 100% 9% 0 1.37s 0.52s 1.3s 0.0% 5.5 KiB/s 3 msgs/s 0 Bytes/s 1.3 KiB/s 326.0 KiB 421 msgs 0 msgs 0 msgs 326.6 KiB 421 msgs 0 msgs 0 Bytes 0 Files 152.7 KiB 421 Files 118.97s 425.6 MiB 562.8 MiB 2.2 GiB 7.80 0.93
shovel/pclean_f90 run 3/3 310 100% 0% 0 82.03s 75.72s 0.7s 0.0% 5.6 KiB/s 3 msgs/s 0 Bytes/s 0 Bytes/s 111.4 KiB 120 msgs 0 msgs 0 msgs 99.9 KiB 111 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 38.02s 127.4 MiB 169.0 MiB 249.6 MiB 2.37 0.27
shovel/pclean_f92 run 3/3 0 100% 0% 0 82.49s 76.06s 19.1s 0.0% 1.7 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s 99.9 KiB 111 msgs 0 msgs 0 msgs 103.0 KiB 111 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 118.28s 126.4 MiB 168.5 MiB 249.2 MiB 2.04 0.21
shovel/rabbitmqtt_f22 run 3/3 0 100% 0% 0 1.25s 0.54s 1.3s 0.0% 5.5 KiB/s 3 msgs/s 0 Bytes/s 0 Bytes/s 326.0 KiB 421 msgs 0 msgs 0 msgs 326.0 KiB 421 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 118.77s 126.0 MiB 167.6 MiB 248.7 MiB 2.12 0.20
shovel/t_dd1_f00 run 3/3 0 100% 0% 3 23.15s 3.06s 0.1s 82.3% 3.4 KiB/s 14 msgs/s 0 Bytes/s 0 Bytes/s 231.6 KiB 1.6 Kim 1.3 Kim 0 msgs 168.4 KiB 293 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 118.19s 127.3 MiB 171.0 MiB 250.1 MiB 2.77 0.32
shovel/t_dd2_f00 run 3/3 0 100% 0% 0 11.82s 2.61s 0.2s 82.2% 3.3 KiB/s 13 msgs/s 0 Bytes/s 0 Bytes/s 225.7 KiB 1.6 Kim 1.3 Kim 0 msgs 166.6 KiB 290 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 118.33s 127.3 MiB 170.6 MiB 250.1 MiB 2.74 0.39
subscribe/amqp_f30 run 3/3 0 100% 39% 0 18.79s 6.44s 0.7s 0.0% 1.5 KiB/s 2 msgs/s 1.2 KiB/s 0 Bytes/s 181.0 KiB 237 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 146.8 KiB 237 Files 0 Bytes 0 Files 117.95s 126.2 MiB 168.0 MiB 248.9 MiB 2.20 0.27
subscribe/cclean_f91 run 3/3 213 100% 0% 0 0.00s 0.00s 0.5s 17.4% 2.7 KiB/s 6 msgs/s 0 Bytes/s 0 Bytes/s 35.5 KiB 92 msgs 16 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 13.37s 126.1 MiB 167.9 MiB 248.8 MiB 2.53 0.36
subscribe/cdnld_f21 run 3/3 0 100% 41% 0 10.43s 3.13s 0.1s 0.0% 1.4 KiB/s 2 msgs/s 1.4 KiB/s 0 Bytes/s 167.1 KiB 262 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 162.7 KiB 262 Files 0 Bytes 0 Files 117.90s 131.6 MiB 190.7 MiB 277.6 MiB 3.39 0.42
subscribe/cfile_f44 run 3/3 0 100% 40% 0 3.32s 0.30s 0.0s 0.0% 1.5 KiB/s 4 msgs/s 1.4 KiB/s 0 Bytes/s 178.3 KiB 509 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 161.8 KiB 509 Files 0 Bytes 0 Files 118.09s 130.9 MiB 188.5 MiB 278.0 MiB 2.62 0.30
subscribe/cp_f61 run 3/3 0 100% 12% 0 6.42s 2.09s 0.1s 0.0% 2.8 KiB/s 3 msgs/s 597 Bytes/s 0 Bytes/s 326.6 KiB 421 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 69.0 KiB 123 Files 0 Bytes 0 Files 118.23s 125.9 MiB 166.8 MiB 248.9 MiB 2.48 0.31
subscribe/ftp_f70 run 3/3 0 100% 39% 0 1.75s 0.77s 0.1s 0.0% 1.3 KiB/s 2 msgs/s 1.4 KiB/s 0 Bytes/s 158.4 KiB 340 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 159.8 KiB 340 Files 0 Bytes 0 Files 118.04s 126.1 MiB 167.4 MiB 248.8 MiB 2.22 0.36
subscribe/q_f71 run 3/3 0 100% 31% 0 3.12s 1.18s 5.7s 0.0% 1.2 KiB/s 3 msgs/s 1.1 KiB/s 0 Bytes/s 142.7 KiB 396 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 124.6 KiB 396 Files 0 Bytes 0 Files 118.49s 135.0 MiB 191.9 MiB 928.8 MiB 4.30 0.68
subscribe/rabbitmqtt_f31 run 3/3 0 100% 8% 0 4.27s 1.10s 1.1s 0.0% 2.8 KiB/s 3 msgs/s 598 Bytes/s 0 Bytes/s 326.0 KiB 421 msgs 0 msgs 0 msgs 0 Bytes 0 msgs 0 msgs 69.0 KiB 123 Files 0 Bytes 0 Files 118.15s 126.2 MiB 167.9 MiB 248.9 MiB 2.22 0.27
subscribe/u_sftp_f60 run 3/3 0 100% 9% 0 2.69s 1.71s 1.2s 0.2% 2.8 KiB/s 3 msgs/s 599 Bytes/s 0 Bytes/s 326.6 KiB 421 msgs 1 msg 0 msgs 0 Bytes 0 msgs 0 msgs 69.0 KiB 122 Files 0 Bytes 0 Files 117.93s 126.4 MiB 167.8 MiB 249.2 MiB 2.05 0.33
watch/f40 run 1/1 0 100% 0% 0 0.06s 0.02s 1.6s 0.0% 3.0 KiB/s 0 msgs/s 0 Bytes/s 0 Bytes/s 0 Bytes 0 msgs 74 msgs 0 msgs 169.5 KiB 203 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 57.21s 46.3 MiB 65.3 MiB 311.8 MiB 1.95 0.14
winnow/t00_f10 run 1/1 0 100% 0% 0 6.38s 3.47s 0.2s 51.7% 1.7 KiB/s 2 msgs/s 0 Bytes/s 0 Bytes/s 66.8 KiB 116 msgs 60 msgs 0 msgs 32.3 KiB 56 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 57.79s 42.5 MiB 56.2 MiB 83.3 MiB 0.77 0.12
winnow/t01_f10 run 1/1 0 100% 0% 0 9.75s 2.53s 0.1s 51.3% 1.8 KiB/s 2 msgs/s 0 Bytes/s 0 Bytes/s 67.2 KiB 117 msgs 60 msgs 0 msgs 32.8 KiB 57 msgs 0 msgs 0 Bytes 0 Files 0 Bytes 0 Files 56.37s 42.3 MiB 55.7 MiB 83.2 MiB 0.81 0.12
Total Running Configs: 25 ( Processes: 64 missing: 0 stray: 0 )
Memory: uss:2.5 GiB rss:3.4 GiB vms:7.4 GiB
CPU Time: User:53.06s System:7.00s
Pub/Sub Received: 99 msgs/s (63.2 KiB/s), Sent: 53 msgs/s (29.3 KiB/s) Queued: 3 Retry: 523, Mean lag: 4.54s
Data Received: 18 Files/s (9.3 KiB/s), Sent: 3 Files/s (1.3 KiB/s)
fractal% sr3 --full status
La première rangée catégorise les informations pour les lignes suivantes:
Processes (Processus): Indique le nombre d’instances et si il y en manquent.
Connection (Connexion): Indique l’état de la connexion externe.
Lag (Délai): Le sévérité du délai expériencé ou la durée de vie des données par le temps que le téléchargement soit complété.
Last (Dernier): combien de temps a passé depuis le dernier transfert de fichier ou message.
Rates (Taux): La vitesse des transferts, plusieurs métriques sont communiqués.
Counters (Compteurs): La base des calculs des taux, se réinitialise à chaque interval de housekeeping.
Memory (Mémoire): L’utilisation de la mémoire des processus dans une configuration particulière.
CPU time (temps de traitement): Le temps de traitement des processus dans une configuration particulière.
Les dernières trois catégories sont seulement listés avec l’option –full est fourni.
La deuxième rangée donne des détails sur les en têtes de chacune des catégories.
Les configurations sont répertoriées sur la gauche. Pour chaque configuration, l’état. sera :
hung : les processus semblent bloqués et n’écrivent rien dans les journaux.
idle : tous les processus en cours d’exécution, mais ne transfert pas depuis trop longtemps (runStateThreshold_idle.)
lag : tous les processus en cours d’exécution, mais les messages en cours de traitement sont trop anciens ( runStateThreshold_lag )
part: certains processus sont en cours d’exécution, d’autres manquent à l’appel.
reje : tous les processus en cours d’exécution, mais un pourcentage trop élevé de messages rejetés (runStateThreshold_reject )
rtry : tous les processus en cours d’exécution, mais un grand nombre de transferts échouent, causant d’autres tentatives (runStateThreshold_retry )
run : tous les processus sont en cours d’exécution (et en transfert, et pas en retard, et pas lents… état normal.)
slow : transfert de moins que le minimum d’octets/seconde ( runStateThreshold_slow )
stby : Mode veille (Standby): tous les processus sont en cours d’exécution, mais les messages sont stockés dans la file d’attente download_retry locale.
stop : aucun processus n’est en cours d’exécution.
Les colonnes à droite donnent plus d’informations, détaillant le nombre de processus en cours d’exécution à partir du nombre attendu. Par exemple, 3/3 signifie 3 processus ou instances sont trouvés à partir des 3 attendus. Expected liste combien de processus devraient être exécutés à partir d’une configuration même si ils sont arrêtés.
La colonne Retry indique le nombre de messages de notifications stockés dans la queue Retry locale. Celle-ci indique quelles chaînes ont de la difficultés à traiter les données.
Entête |
But |
State |
Statut d’une configuration particulière: stop|run|disa|part|wVip|fore |
Run |
Nombre de processus ou instances en marche en comparaison au nombre attendu. 3/10 3 processes running of 10 expected. |
Retry |
Le nombre de messages dans la queue retry, indiquant des problèmes avec le transfert. |
msg |
Le pourcentage du temps connecté à un broker pour publier ou s’abonner à des messages. |
data |
Le pourcentage du temps connecté à une source de données. |
LagQueued |
Le nombre de messages en attente sur le courtier (serveur à distance.) |
LagMax |
La durée maximale d’un message à la reception (avant un téléchargement). |
LagAvg |
La durée moyenne d’un message à la reception (avant un téléchargement). |
Last |
Combien de temps a passé depuis le dernier téléchargement (ou message.) |
pubsub |
Le débit des messages pub/sub téléchargés en bytes/seconde. |
messages |
Le débit des messages pub/sub téléchargés en message/seconde. |
%rej |
Le pourcentage des messages téléchargés rejeté (indication du statut du filtre d’abonnement (subscription). |
RxData |
Le montant de données téléchargées (pas en format message) |
TxData |
Le montant de données envoyées (pas en format message) |
subBytes |
Compteur d’octets de messages pub/sub reçus. |
Accepted |
Compteur du nombre de messages acceptés. |
Rejected |
Compteur du nombre de messages rejetés. |
Malformed |
Compteur de messages qui ont été rejetés parce qu’ils n’ont pas pu être compris. |
pubBytes |
Compteur d’octets de messages en cours de publication. |
pubMsgs |
Compteur de messages en cours de publication. |
pubMal |
Compteur de messages dont la publication a échoué. |
rxData |
Compteur d’octets de fichiers en cours de téléchargement. |
rxFiles |
Compteur de fichiers en cours de téléchargement. |
txData |
Compteur d’octets de fichiers envoyés. |
txFiles |
Compteur de fichiers envoyés. |
Since |
Combien de secondes depuis la dernière réinitialisation du compteur (base pour les calculs de taux.) |
uss |
unique set size (utilisation de la mémoire des instances.) Mémoire physique unique réelle utilisée par les processus. |
rss |
resident set size (utilisation de la mémoire des instances) Mémoire physique réelle utilisée, y compris partagée. |
vms |
taille de la mémoire virtuelle de tous les partages et physiques et swap alloués ensemble. |
user |
temps d’utilisation CPU de l’utilisateur |
system |
temps de CPU utilisé par le système |
À la fin de la liste, nous avons la somme des valeurs mentionnées précédemment.
La ceuillette de messages
La plupart des composants Metpx Sarracenia boucle sur la ceuillette et/ou réception de messages AMQP. Habituellement, les messages d’intérêt sont dans le format d´une avis sr_post(7), annonçant la disponibilité d’un fichier en publiant l’URL pour l´accéder (ou une partie de celle-ci). Les messages AMQP sont publiés avec un exchange comme destinataire. Sur un courtier (serveur AMQP.) L’exchange délivre des messages aux files d’attente. Pour recevoir de messages, on doit fournir les informations d’identification pour se connecter au courtier (message AMQP). Une fois connecté, un consommateur doit créer une fil d’attente pour retenir les messages en attente. Le consommateur doit ensuite lier la fil d’attente à une ou plusieurs échanges de manière à ce qu’il mette dans sa fil d’attente.
Une fois les liaisons (anglais: bindings) établies, le programme peut recevoir des messages. Lorsqu’un message est reçu, un filtrage supplémentaire est possible en utilisant des expressions régulières sur les messages AMQP. Après qu’un message a passé avec succès ce processus de sélection et d’autres validations internes, le processus peut exécuter un script de plugin on_message pour traiter le message davantage de façon spécialisé. Si ce plugin retourne False comme résultat, le message est rejeté. Si c’est vrai, le traitement du message se poursuit.
Les sections suivantes expliquent toutes les options pour régler cette partie “consommateur” de les programmes de Sarracenia.
Réglage de Broker
broker [amqp|mqtt]{s}://<user>:<password>@<brokerhost>[:port]/<vhost>
Un URI AMQP est utilisé pour configurer une connexion à une pompe à messages (AMQP broker). Certains composants de Sarracenia définissent une valeur par défaut raisonnable pour cette option. Vous fournissez l’utilisateur normal, l’hôte, le port des connexions. Dans la plupart des fichiers de configuration, le mot de passe est manquant. Le mot de passe n’est normalement inclus que dans le fichier credentials.conf.
L´application Sarracenia n’a pas utilisé vhosts, donc vhost devrait toujours être /.
pour plus d’informations sur le format URI de l’AMQP : ( https://www.rabbitmq.com/uri-spec.html))
soit dans le fichier default.conf, soit dans chaque fichier de configuration spécifique. L’option courtier indique à chaque composante quel courtier contacter.
broker [amqp|mqtt]{s}://<user>:<pw>@<brokerhost>[:port]/<vhost>
- ::
(par défaut : Aucun et il est obligatoire de le définir)
Une fois connecté à un courtier AMQP, l’utilisateur doit lier une fil d’attente. à l´*exchange* et aux thèmes (topics) pour déterminer les messages intérêsseants.
Configuration de fil d´attente
Une fois connecté à un courtier AMQP, l’utilisateur doit créer une fil d’attente.
Mise en fil d’attente sur broker :
queueShare <chaine> (par défaut : ${USER}_${HOSTNAME}_${RAND8})
expire <durée> (par défaut : 5m == cinq minutes. À OUTREPASSER)
message_ttl <durée> (par défaut : Aucun)
prefetch <N> (par défaut : 1)
Habituellement, les composants devinent des valeurs par défaut raisonnables pour toutes ces valeurs et les utilisateurs n’ont pas besoin de les définir. Pour les cas moins habituels, l’utilisateur peut avoir besoin a remplacer les valeurs par défaut. La fil d’attente est l’endroit où les avis sont conservés sur le serveur pour chaque abonné.
Liasons AMQP QUEUE
Une fois qu’on a une fil d’attente, elle doit être liée à un échange (exchange.) Les utilisateurs ont presque toujours besoin de définir ces options. Une fois qu’une fil d’attente existe sur le courtier, il doit être lié (bound) à une échange. Les liaisons (bindings) définissent ce que l’on entend par les avis que le programme reçoit. La racine du thème est fixe, indiquant la version du protocole et le type de l’arborescence. (mais les développeurs peuvent l’écraser avec le topic_prefix. option.)
Ces options définissent les messages (notifications URL) que le programme reçoit :
exchange <name> (défaut: xpublic)
exchangeSuffix <name> (défaut: None)
topic_prefix <amqp pattern> (défaut: 03 – developer option)
subtopic <amqp pattern> (pas de défaut, doit apparaitre apres exchange)
subtopic <amqp pattern> (default: #)
Dans les publications d’un échange, le paramètre de sous-thème restreint la sélection de produits. Pour donner une valeur correcte au sous-thème, on a le choix de filtrer en utilisant subtopic avec seulement le wildcard limité d’AMQP et à longueur limitée à 255 octets codés, ou l’expression régulière la plus puissante basés sur les mécanismes accept/reject décrits ci-dessous. La différence étant que le Le filtrage AMQP est appliqué par le courtier lui-même, ce qui évite que les avis ne soient livrés au client du tout. Les modèles accept/reject s’appliquent aux messages envoyés par le courtier à l’abonné. En d’autres termes, accept/reject sont des filtres côté client, alors que subtopic est le filtrage côté serveur.
Il est préférable d’utiliser le filtrage côté serveur pour réduire le nombre de avis envoyées au client à un petit sur-ensemble de ce qui est pertinent, et n’effectuer qu’un réglage fin avec l’outil mécanismes côté client, économisant la bande passante et le traitement pour tous.
topic_prefix est principalement d’intérêt pendant les transitions de version de protocole, où l’on souhaite spécifier une version sans protocole par défaut des messages auxquels s’abonner, ou bien pour manipuler des rapports de disposition, au lieu d’avis.
Habituellement, l’utilisateur spécifie un échange et plusieurs options de sous-thèmes. subtopic est ce qui est normalement utilisé pour indiquer les messages d’intérêt. Pour utiliser le sous-thème pour filtrer les produits, faites correspondre la chaîne de sous-thèmes avec le chemin relatif dans l´arborescence de répertoires sur le serveur.
Par exemple, en consommant à partir de DD, pour donner une valeur correcte au sous-thème, on peut Parcourez notre site Web http://dd.weather.gc.ca et notez tous les annuaires. d’intérêt. Pour chaque arborescence de répertoires d’intérêt, écrivez un subtopic. comme suit :
subtopic directory1.*.subdirectory3.*.subdirectory5.#
ou:
* correspond a un seul nom de repertoire
# correspond à toute arborescence de répertoires restante
On peut utiliser plusieurs liaisons à plusieurs échanges comme cela:
exchange A
subtopic directory1.*.directory2.#
exchange B
subtopic *.directory4.#
Cela va déclarer deux liaisons différentes à deux échanges différents et deux arborescences de fichiers différentes. Alors que la liaison par défaut consiste à se lier à tout, certains courtiers pourraient ne pas permettre aux clients à définir des liaisons, ou on peut vouloir utiliser des liaisons existantes. On peut désactiver la liaison de fil d’attente comme cela:
subtopic None
(False, ou off marchera aussi.)
Filtrage côté client
Nous avons sélectionné nos messages via exchange, subtopic et subtopic. Le courtier met les messages correspondants dans notre fil d’attente (queue). Le composant télécharge ces messages.
Les clients Sarracenia implémentent un filtrage plus flexible côté client en utilisant les expressions régulières.
Bref introduction aux expressions régulières
Les expressions régulières sont un moyen très puissant d’exprimer les correspondances de motifs. Ils offrent une flexibilité extrême, mais dans ces exemples, nous utiliserons seulement un petit sous-ensemble : Le point (.) est un joker qui correspond à n’importe quel caractère unique. S’il est suivi d’un nombre d’occurrences, il indique le nombre de lettres qui correspondent. Le caractère * (astérisque), signifie un nombre quelconque d’occurrences. alors :
.* signifie n’importe quelle séquence de caractères de n’importe quelle longueur. En d’autres termes, faire correspondre n’importe quoi.
cap.* signifie toute séquence de caractères commençant par cap.
.*CAP.* signifie n’importe quelle séquence de caractères avec CAP quelque part dedans.
.*CAP signifie toute séquence de caractères qui se termine par CAP.
Dans le cas où plusieurs portions de la chaîne de caractères pourraient correspondre, la plus longue est sélectionnée.
.*?CAP comme ci-dessus, mais non-greedy, ce qui signifie que le match le plus court est choisi.
noter que l’implantaions de regexp en C n’inclu pas le greediness, alors certains expressions ne seront pas interpretés pareilles par les outils implanté en C: sr_cpost, sr_cpump, où libsrshim.
Veuillez consulter diverses ressources Internet pour obtenir de plus amples renseignements:
accept, reject and accept_unmatch
accept <expression régulière (regexp)> (facultatif)
reject <expression régulière (regexp)> (facultatif)
acceptUnmatched <booléen> (par défaut: True)
baseUrl_relPath <booléen> (par défaut: False)
Les options accept et reject traitent des expressions régulières (regexp). La regexp est appliquée à l’URL du message pour détecter une correspondance.
Si l’URL du message d’un fichier correspond à un motif reject, on informe le courtier que le message a été consommé et on abandonne son traitement.
Celui qui correspond à un motif accept est traité par le composant.
Dans de nombreuses configurations, les options accept et reject sont spécifiés ensembles, et avec l’option directory. Ils relient ensuite les messages acceptés à la valeur directory sous laquelle ils sont spécifiés.
Après que toutes les options accept / reject sont traitées normalement. l’accusé de réception du message tel qu’il a été consommé et ignoré. Pour outrepasser ce comportement de défaut, définissez accept_unmatch à True.
Les accept/rejet sont interprétés dans l’ordre qu´ils apparaissent dans le fichier de configuration. Chaque option est traitée en ordre de haut en bas. par exemple :
sequence #1:
reject .*\.gif
accept .*
sequence #2:
accept .*
reject .*\.gif
Dans la séquence #1, tous les fichiers se terminant par ‘gif’ sont rejetés. Dans la séquence #2, l’option accept .* (regexp qui veut dire accepte tout) est rencontré avant la déclaration de rejet, de sorte que le rejet n’a aucun effet.
Il est préférable d’utiliser le filtrage côté serveur pour réduire le nombre de avis envoyées au composant à un petit sur-ensemble de ce qui est pertinent, et n’effectuer qu’un réglage fin avec les mécanismes accept/reject côté client, économisant la bande passante et le traitement pour tous.
Plus de détails sur la façon d’appliquer les directives suivent:
Normalement, le chemin d’accès relatif (baseUrl_relPath est False, ajouté au répertoire de base) pour les fichiers téléchargés seront définis en fonction de l’en-tête relPath inclus dans le message. Toutefois, si baseUrl_relPath est défini, le relPath du message va être précédé des sous-répertoires du champ baseUrl du message.
Convention d´appellation de files d´attente
Alors que dans la plupart des cas, une bonne valeur de nom de fil d´attente (en anglais: queue) est générée par l’application, dans certains cas, c´est nécessaire de remplacer ces choix par une spécification utilisateur explicite. Pour ce faire, il faut connaître les règles de nommage des files d’attente :
les noms de fil d’attente commencent par q_.
ceci est suivi de <amqpUserName> (le propriétaire/utilisateur du nom d’utilisateur du courtier de la fil d’attente).
suivi d’un deuxième tiret de soulignement ( _ )
suivi d’une chaîne de caractères au choix de l’utilisateur.
La longueur totale du nom de la fil d’attente est limitée à 255 octets de caractères UTF-8.
PUBLICATION (POST)
Comme de nombreux composants consomment un flux de messages, de nombreux composants (souvent les mêmes) produisent également un flux de sortie de messages. Pour créer des fichiers disponible pour les abonnés, une affiche publie les annonces à un AMQP ou Serveur MQTT, également appelé broker. L’option post_broker définit toutes les informations d’identification pour se connecter au courtier de sortie AMQP.
post_broker [amqp|mqtt]{s}://<user>:<pw>@<brokerhost>[:port]/<vhost>
Une fois connecté au courtier de source AMQP, le programme génère des notifications après que le téléchargement d’un fichier a eu lieu. Pour générer la notification et l’envoyer au courtier au saut suivant, l’utilisateur définit ces options :
post_baseDir <path> (facultatif)
post_topicPrefix <pfx> (par défaut: ‘v03’)
post_exchange <name> (par défaut: xpublic)
post_baseUrl <url> (OBLIGATOIRE)
FIXME : Des exemples de ce à quoi ils servent, de ce qu’ils font…
Convention d´appellation des EXCHANGES
Les noms d’échange commencent par x
Les échanges qui se terminent par public sont accessibles (pour lecture) par tout utilisateur authentifié.
Les utilisateurs sont autorisés à créer des échanges avec le modèle: xs_<amqpUserName>_<whatever>. ces échanges ne peuvent être écrits que par cet utilisateur.
Le système (sr_audit ou administrateurs) crée l’échange de xr_<amqpUserName> comme un lieu d’envoi de rapports pour un utilisateur. Il n’est lisible que par cet utilisateur.
Les utilisateurs administratifs (rôles d’administrateur ou de feeder) peuvent publier ou s’abonner n’importe où.
Par exemple, xpublic n’a pas xs_ et un modèle de nom d’utilisateur, de sorte qu’il ne peut être publié que par les utilisateurs administrateurs ou feeder. Puisqu’il se termine en public, tout utilisateur peut s’y lier pour s’abonner aux messages publiés. Les utilisateurs peuvent créer des échanges tels que xs_<amqpUserName>_public qui peuvent être écrits par cet utilisateur (selon la règle 3), et lu par d’autres (selon la règle 2.) Une description du flux conventionnel de messages à travers les échanges sur une pompe. Les abonnés se lient généralement à l’échange xpublic pour obtenir le flux de données principal. Il s’agit de la valeur par défaut dans sr_subscribe.
Un autre exemple, un utilisateur nommé Alice aura au moins deux échanges :
xs_Alice l’exhange où Alice poste ses notifications de fichiers et signale les messages (via de nombreux outils).
xr_Alice l’échange d’où Alice lit ses messages de rapport (via sr_shovel).
Alice peut créer un nouvel échange en publiant simplement dessus (avec sr3_post ou sr_cpost) s’il répond aux règles de nommage.
Habituellement, un sr_sarra exécuté par un administrateur de pompe lira à partir d’un échange tel que xs_Alice_mydata pour récupérer les données correspondant au message post d’Alice, et les rendre disponibles sur la pompe, en le ré-annonçant sur l’échange xpublic.
SONDAGE (POLLING)
On peut faire le même travail que post, sauf que les fichiers sont sur un serveur distant. Dans le cas d’un sondage (en anglais: poll), l’URL de la publication sera générée à partir de l´option pollUrl, avec le chemin d’accès du produit (path « fichier correspondant »). Il y en a une publication par fichier. La taille du fichier est prise dans le répertoire « ls »… mais sa somme de contrôle ne peut pas être déterminée, alors la stratégie de calcul de est ¨cod¨ qui signifie que ca devrait être calculé lors du transfert.
Pour définir la fréquence de sondage, on se sert de scheduled_, tel que:
scheduled_interval 30m
pour sonder à toute les trente minutes, ou bien:
scheduled_hour 1,13,19
scheduled_minute 27
pour sonder trois fois par jour à 1h27, 13h27 et 19h27, ou bien:
scheduled_time 15:30,20:30,23:15
pour sonder à seulement 15:30, 20:30 et 23:15
Par défaut, sr_poll envoie son message de publication au courtier avec l’échange par défaut (le préfixe xs_ suivi du nom d’utilisateur du courtier). Le post_broker est obligatoire. Il peut être incomplet s’il est bien défini dans le fichier credentials.conf.
Référez sr3_post(1) - pour comprendre l’ensemble du processus de notification. Référez sr3_post(7) - pour comprendre le format complet de notification.
- Ces options définissent les fichiers pour lesquels l’utilisateur souhaite être averti et où
il sera placé, et sous quel nom.
path <path> (par défaut: .)
accept <regexp pattern> [rename=] (doit être défini)
reject <regexp pattern> (facultatif)
permDefault <integer> (par défaut: 0o400)
fileAgeMax <duration> (par défaut 30d)
fileAgeMax doit être inférieur à nodupe_ttl lors de l’utilisation de la suppression des doublons, pour éviter la réingestion de fichiers obsolètes une fois partie du cache nodupe.
L’option path définit où obtenir les fichiers sur le serveur. Combiné avec les options accept / reject, l’utilisateur peut sélectionner les fichiers d’intérêt et leurs répertoires de résidence.
Les options accept et reject utilisent des expressions régulières (regexp) pour trouver une correspondance avec l’URL. Ces options sont traitées séquentiellement. L’URL d’un fichier qui correspond à un modèle reject n’est pas publiée. Les fichiers correspondant à un modèle accept sont publiés.
Le répertoire peut avoir des modèles. Ces modèles pris en charge concernent la date/l’heure. Ils sont fixes…
${YYYY} année actuelle ${MM} mois actuel ${JJJ} julian actuelle ${YYYYMMDD} date actuelle
${YYYY-1D} année actuelle - 1 jour ${MM-1D} mois actuel - 1 jour ${JJJ-1D} julian actuelle - 1 jour ${YYYYMMDD-1D} date actuelle - 1 jour
ex. path /mylocaldirectory/myradars
path /mylocaldirectory/mygribs
path /mylocaldirectory/${YYYYMMDD}/mydailies
accept .*RADAR.*
reject .*Reg.*
accept .*GRIB.*
accept .*observations.*
L’option permDefault permet aux utilisateurs de spécifier un masque d’autorisation octal numérique de style Linux:
permDefault 040
signifie qu’un fichier ne sera pas publié à moins que le groupe ait l’autorisation de lecture (sur une sortie ls qui ressemble à : —r—–, comme une commande chmod 040 <fichier> ). Les options permDefault spécifient un masque, c’est-à-dire que les autorisations doivent être au moins ce qui est spécifié.
Comme pour tous les autres composants, l’option vip peut être utilisée pour indiquer qu’un poll doit être actif sur seulement un seul nœud d’un cluster.
Les fichiers qui sont plus vieux que fileAgeMax sont ignorés. Cela peut être modifié à n’importe quelle limite de temps spécifiée dans les configurations en utilisant l’option fileAgeMax <duration>. Par défaut, dans les composants autre que poll, cette option est désactivé en étant défini à zéro (0). Comme il s’agit d’une option de durée, les unités sont en secondes par défaut, mais il est possible de definir l’option en utilisant des minutes, heures, jours ou des semaines. Dans la composante de poll, fileAgeMax est défini à 30 jours par défaut.
Sondage avancé (Advanced Polling)
Le poll intégré liste les répertoires distants et analyse les lignes renvoyées par les structures paramiko.SFTPAttributes (similaires à os.stat) pour chaque fichier répertorié. Il existe une grande variété de personnalisations disponibles car les ressources à poller très différentes :
on peut implémenter un rappel sarracenia.flowcb avec une routine poll pour prendre en charge ces services, ce qui remplace le poll par défaut.
Certains serveurs ont des résultats non standard quand ils listent des fichiers, de sorte que l’on peut sur-classer un rappel sarracenia.flowcb.poll avec le point d’entrée on_line pour normaliser leurs réponses en utilisant quand même le flux de poll intégré.
Il existe de nombreux serveurs http qui fournissent des formats très différents quand ils listent de fichiers, donc parfois, au lieu de reformater individuellement chaque ligne ligne, il faut refaire l’analyse de la page au complet. Le point d’entrée on_html_page dans sarracenia.flowcb.poll peut être modifié en la sur-classant également.
Il existe d’autres serveurs qui fournissent des services différents qui ne sont pas inclus dans le poll par défaut. On peut implémenter une classe sarracenia.transfer supplémentaire pour mieux comprendre le poll.
La sortie d’un poll est une liste de messages créés à partir des noms de fichiers et les enregistrements SFTPAttributes, qui peuvent ensuite être filtrés par éléments après gather dans l’algorithme.
COMPOSANTS
Tous les composants effectuent une combinaison de poll, de consommation et de publication. avec des variations qui permettent soit la transmission d’annonces, ou soit aux transferts de données. Les composants appliquent tous le seul même algorithme, il suffit de commencer à partir de différents paramètres par défaut pour correspondre à un cas d’utilisation commun.
CPUMP
cpump* est une implémentation du composant shovel en C. Sur une base individuelle, il devrait être plus rapide qu’un seul téléchargeur python, avec certaines limitations.
ne télécharge pas de données, ne fait que diffuser des messages. (pelle, et non abonné)
s’exécute en tant qu’instance unique (pas d’instances multiples).
ne prend en charge aucun plugin.
ne prend pas en charge vip pour la haute disponibilité.
différentes bibliothèques d’expressions régulières : POSIX vs python.
ne supporte pas regex pour la commande strip (pas de regex non-greedy).
Cela peut donc généralement, mais pas toujours, servir de substitution à l`shovel`_ et à winnow.
L’implémentation C peut être plus facile à mettre à disposition dans des environnements spécialisés, comme l’informatique de haute performance, car il y a beaucoup moins de dépendances que la version python. Cela utilise également beaucoup moins de mémoire pour un rôle donné. Normalement la version python est recommandé, mais il y a des cas où l’utilisation de l’implémentation C est raisonnable.
sr_cpump se connecte à un broker (souvent le même que le courtier de post) et s’abonne aux notifications d’intérêt. Si _suppress_duplicates_ est actif, à la réception d’un message, il recherche le champ integity du message dans la cache. Si le message est trouvé, le fichier est déjà passé, de sorte que la notification est ignorée. Si ce n’est pas le cas, alors le fichier est nouveau, et la sum est ajoutée à la cache et la notification est publiée.
FLOW
Flow est la classe parent à partir de laquelle tous les autres composants, à l’exception de cpost et cpump, sont construits. Flow n’a pas de comportement intégré. Les paramètres peuvent le faire agir comme n’importe quel autre composant python, ou il peut être utilisé pour créer des composants définis par l’utilisateur. Généralement utilisé avec l’option flowMain pour exécuter une sous-classe de flux définie par l’utilisateur.
POLL
poll est un composant qui se connecte à un serveur distant pour vérifier divers répertoires pour certains fichiers. Lorsqu’un fichier est présent, modifié, ou créé dans le répertoire distant, le programme informe qu’il y a nouveau produit.
Le protocle de notification est défini ici sr3_post(7)
poll se connecte à un broker. À toutes les secondes de scheduled_interval (où bien à des moment spécifié par scheduled_hour et scheduled_minute), il se connecte à
une pollUrl (sftp, ftp, ftps). Pour chacun des path définis, les contenus sont listés.
Le poll est seulement destinée à être utilisée pour les fichiers récemment modifiés. L’option fileAgeMax élimine les fichiers trop anciens. Lorsqu’un fichier correspondant à un modèle donné est trouvé by accept, poll crée un message de notification pour ce produit.
Le message est ensuite verifié dans la cache dupliqué (limité en temps par l’option nodupe_ttl) pour empêcher la publication de fichiers qui ont déjà été vus.
poll peut être utilisé pour acquérir des fichiers distants en conjonction avec un sarra qui est abonné aux notifications d’un post, pour les télécharger et les republier à partir d’une pompe de données.
L’option de pollUrl spécifie ce qui est nécessaire pour se connecter au serveur distant
pollUrl protocol://<user>@<server>[:port]
- ::
(par défaut : Aucun et il est obligatoire de le définir )
La pollUrl doit être définie avec le minimum d’informations requises… sr_poll utilise le paramètre pollUrl non seulement lors du poll, mais aussi dans messages sr3_post produits.
Par exemple, l’utilisateur peut définir :
pollUrl ftp://myself@myserver
Et compléter les informations nécessaires dans le fichier d’informations d’identification (credentials) avec la ligne :
ftp://myself:mypassword@myserver:2121 passive,binary
Poll rassemble des informations sur les fichiers distants, pour créer des messages à leur sujet. La méthode gather intégrée utilise les protocoles sarracenia.transfer. Actuellement sftp, ftp et http sont implémentés.
Scans répétés et VIP
Lorsque plusieurs serveurs coopèrent pour polller un serveur distant, le paramètre vip est utilisé pour décider quel serveur il faut réellement poller. Tous les serveurs participants s’abonnent à l’endroit où poll est publié, et utilisent les résultats pour remplir la cache de suppression des doublons, afin que que si l’adresse VIP se déplace, les serveurs alternatifs ont des indications actuelles de ce qui a été affiché.
POST or WATCH
sr3_post affiche la disponibilité d’un fichier en créant une annonce. Contrairement à la plupart des autres composants de sarracenia qui agissent comme des démons, sr3_post est une invocation qui poste et se termine en une seul fois. Pour mettre les fichiers à la disposition des abonnés, sr3_post envoie les annonces à un serveur AMQP ou MQTT, également appelé broker.
Il existe de nombreuses options pour la détection des modifications dans les répertoires, pour une discussion détaillée des options dans Sarracenia, voir DetectFileReady.html
Cette page de manuel concerne principalement l’implémentation de python, mais il y a aussi une implémentation en C, qui fonctionne presque pareille. Différences:
les plugins ne sont pas pris en charge dans l’implémentation C.
L’implémentation C utilise des expressions régulières POSIX, la grammaire python3 est légèrement différente.
lorsque l’option sleep (utilisée uniquement dans l’implémentation C) est définie sur > 0, cela transforme sr_cpost en un démon qui fonctionne comme un watch.
Le composant watch est utilisé pour surveiller les répertoires à la recherche de nouveaux fichiers. Cela est équivalent à poster (ou cpost) avec l’option sleep réglée sur >0.
L’option [-pbu|–post_baseUrl url,url,…] spécifie l’emplacement a partir d’ou les abonnés pourront télécharger. Il y a généralement un message par fichier. Format de l’argument de l’option post_baseUrl
[ftp|http|sftp]://[user[:password]@]host[:port]/
or
file:
Lorsque plusieurs URL sont données sous forme de liste séparée par des virgules à post_baseUrl, les url fournies sont utilisées dans le style round-robin, pour fournir une forme d’équilibrage de charge.
L’option [-p|–path path1 path2 .. pathN] spécifie le chemin d’accès des fichiers à annoncer. Il y a généralement un message par fichier. Format de l’argument de l’option path
/absolute_path_to_the/filename
or
relative_path_to_the/filename
L’option -pipe peut être spécifiée pour que sr3_post lise les noms de chemin d’accès à partir de la norme d’entrée également.
Exemple d’invocation de sr3_post:
sr3_post -pb amqp://broker.com -pbu sftp://stanley@mysftpserver.com/ -p /data/shared/products/foo
Par défaut, sr3_post lit le fichier /data/shared/products/foo et calcule sa somme de contrôle. Il crée ensuite un message de publication, se connecte à broker.com en tant qu’utilisateur « invité » (informations d’identification par défaut) et envoie la publication aux vhost ‘/’ par défaut et à l’échange par défaut. L’échange par défaut est le préfixe xs_ suivi du nom d’utilisateur du courtier, où la valeur par défaut ‘xs_guest’. Un abonné peut télécharger le fichier /data/shared/products/foo en s’authentifiant en tant qu’utilisateur stanley sur mysftpserver.com en utilisant le protocole sftp pour broker.com en supposant qu’il dispose des informations d’identification appropriées. La sortie de la commande est la suivante
[INFO] Published xs_guest v03.data.shared.products.foo '20150813161959.854 sftp://stanley@mysftpserver.com/ /data/shared/products/foo' sum=d,82edc8eb735fd99598a1fe04541f558d parts=1,4574,1,0,0
Dans MetPX-Sarracenia, chaque article est publié sous un certain thème. La ligne du journal commence par ‘[INFO]’, suivie du topic du post. Les thèmes dans AMQP sont des champs séparés par un point. Notez que les thèmes MQTT utilisent une barre oblique (/) comme séparateur de thème. Le thème complet commence par a topicPrefix (voir option), version v03, suivi d’un sous-thème (voir option) ici la valeur par défaut, et le chemin du fichier séparé par des points data.shared.products.foo.
Le deuxième champ de la ligne du journal est l’avis de message. Il se compose d’un horodatage 20150813161959.854 et l’URL source du fichier dans les 2 derniers champs.
Le reste des informations est stocké dans des en-têtes de message AMQP, constitués de paires clé=valeur. L’en-tête sum=d,82edc8eb735fd99598a1fe04541f558d donne l’empreinte du fichier (ou somme de contrôle). Ici, d signifie la somme de contrôle md5 effectuée sur les données et 82edc8eb735fd99598a1fe04541f558d est la valeur de la somme de contrôle. Le parts=1,4574,1,0,0 indique que le fichier est disponible en 1 partie de 4574 octets (la taille du fichier.) Le 1,0,0 restant n’est pas utilisé pour les transferts de fichiers avec une seule partie.
un autre exemple:
sr3_post -pb amqp://broker.com -pbd /data/web/public_data -pbu http://dd.weather.gc.ca/ -p bulletins/alphanumeric/SACN32_CWAO_123456
Par défaut, sr3_post lit le fichier /data/web/public_data/bulletins/alphanumeric/SACN32_CWAO_123456 (concaténation du chemin d’accès post_baseDir et relatif de l’URL source pour obtenir le chemin d’accès au fichier local) et calcule sa somme de contrôle. Il crée ensuite un message de publication, se connecte à broker.com en tant qu’utilisateur « invité » (informations d’identification par défaut) et envoie la publication aux hôtes par défaut ‘/’ et échange ‘xs_guest’.
Un abonné peut télécharger le fichier http://dd.weather.gc.ca/bulletins/alphanumeric/SACN32_CWAO_123456 à l’aide de http sans authentification sur dd.weather.gc.ca.
Partitionnement de fichiers
l’utilisation de l’option blocksize n’a aucun effet dans sr3. Il est utilisé pour faire le partitionnement de fichiers, et il redeviendra efficace à l’avenir, avec la même sémantique.
SARRA
sarra est un programme qui s’abonne aux notifications de fichiers, acquiert les fichiers, et les réannonce à leurs nouveaux emplacements. Le protocole de notification est défini ici sr3_post(7)
sarra se connecte à un broker (souvent le même que le serveur de fichiers distant) et s’abonne aux notifications d’intérêt. Il utilise les informations de la notification permettant de télécharger le fichier sur le serveur local sur lequel il s’exécute. Il publie ensuite une notification pour les fichiers téléchargés sur un courtier (généralement sur le serveur local).
sarra peut être utilisé pour acquérir des fichiers auprès de sr3_post(1) ou watch ou pour reproduire un dossier accessible sur le Web (WAF), qui annoncent ses produits.
sr_sarra est un sr_subscribe(1) aves les préréglages suivants:
mirror True
Exigences spécifiques de consommation
Si les messages sont postés directement à partir d’une source l’échange utilisé est ‘xs_<brokerSourceUsername>’. Pour se protéger contre les utilisateurs malveillants, les administrateurs doivent définir sourceFromExchange à True. Ces messages ne peuvent pas contenir un champ cluster ou source d’origine ou un utilisateur malveillant peut définir les valeurs de manière incorrecte.
sourceFromExchange <booléan> (défaut: False)
À la réception, le programme définira ces valeurs dans la classe parente (ici cluster est la valeur de l’option cluster tirée de default.conf) :
msg[‘source’] = <brokerUser> msg[‘from_cluster’] = cluster
remplacer toutes les valeurs présentes dans le message. Ce paramètre doit toujours être utilisé lors de l’ingestion de données provenant d’un échange d’utilisateurs.
SENDER
sender est un composant dérivé de subscribe utilisé pour envoyer des fichiers locaux à un serveur distant à l’aide d’un protocole de transfert de fichiers, principalement SFTP. sender est un consommateur standard, utilisant tous les paramètres AMQP normaux pour les courtiers, les échanges, et toutes les files d’attente, et tout les filtres standard côté client avec accept, reject et after_accept.
Souvent, un courtier annoncera des fichiers à l’aide d’un protocole distant tel que HTTP, mais pour l’expéditeur, il s’agit en fait d’un fichier local. Dans de tels cas, on voir un message : ERROR: The file to send is not local. Un plugin after_accept convertira l’URL Web en un fichier local:
baseDir /var/httpd/www
flowcb sarracenia.flowcb.tolocalfile.ToLocalFile
Ce plugin after_accept fait partie des paramètres par défaut pour les expéditeurs, mais doit encore spécifier baseDir pour qu’il fonctionne.
Si un post_broker est défini, sender vérifie si le nom du cluster est donné par l’option to si elle se trouve dans l’un des clusters de destination du message. Si ce n’est pas le cas, le message est ignoré.
CONFIGURATION 1 : RÉPLICATION POMPE À POMPE
Pour la réplication de la pompe, mirror est défini sur True (valeur par défaut).
baseDir fournit le chemin d’accès au répertoire qui, lorsqu’il est combiné avec le chemin relatif dans la notification sélectionnée, donne le chemin absolu du fichier à envoyer. La valeur par défaut est Aucun, ce qui signifie que le chemin d’accès dans la notification est le chemin absolu.
Dans un subscriber, baseDir représente le préfixe du chemin relatif en amont, et est utilisé comme modèle pour se faire remplacer dans le répertoire de base actuellement sélectionné (à partir d’une option baseDir ou directory) dans les champs de message : ‘fileOp’, qui sont utilisés lors de la mise en miroir de liens symboliques ou de fichiers renommés.
La sendTo définit le protocole et le serveur à utiliser pour livrer les produits. Sa forme est un url partiel, par exemple : ftp://myuser@myhost. Le programme utilise le fichier ~/.conf/sarra/credentials.conf pour obtenir les détails restants (mot de passe et options de connexion). Les protocoles pris en charge sont ftp, ftps et sftp. Si l’utilisateur doit implémenter un autre mécanisme d’envoi, il fournirait le script du plugin par l’option do_send.
Sur le site distant, le post_baseDir sert à la même chose que le baseDir sur ce serveur. La valeur par défaut est None, ce qui signifie que le chemin d’accès livré est l’absolu.
Maintenant, nous sommes prêts à envoyer le produit… par exemple, si la notification sélectionnée ressemble à ceci :
20150813161959.854 http://this.pump.com/ relative/path/to/IMPORTANT_product
sr_sender effectue la pseudo-livraison suivante :
Envoie le fichier locale [baseDir]/relative/path/to/IMPORTANT_product à sendTo/[post_baseDir]/relative/path/to/IMPORTANT_product (kbytes_ps est supérieur à 0, le processus tente de respecter cette vitesse de livraison… ftp,ftps,ou sftp)
À ce stade, une configuration de pompe à pompe doit envoyer la notification à distance… (Si la post_broker n’est pas définie, il n’y aura pas d’affichage… juste la réplication des produits)
La notification sélectionnée contiennent toutes les bonnes informations (attributs de thème et d’en-tête) à l’exception du champ url dans l’avis… dans notre exemple : http://this.pump.com/
Par défaut, sr_sender place la sendTo dans ce champ. L’utilisateur peut l’écraser en spécifiant l’option post_baseUrl. Par exemple:
post_baseUrl http://remote.apache.com
L’utilisateur peut fournir un script on_post. Juste avant que le message ne soit publié sur les post_broker et post_exchange, le on_post script s’appelle… avec l’instance de classe sr_sender comme argument. Le script peut effectuer ce que vous voulez… s’il renvoie False, le message ne sera pas publié. Si la valeur est True, le programme poursuivra le traitement à partir de là.
FIXME : Exemple de configuration manquant.
CONFIGURATION DE DESTINATION 2 : DIFFUSION DE TYPE METPX-SUNDEW
Dans ce type d’utilisation, nous n’aurions généralement pas reposté… mais si le post_broker et post_exchange (url,**on_post**) sont définis, le produit sera annoncé (avec son éventuel nouvel emplacement et son nouveau nom). Réintroduisons les options dans un ordre différent avec quelques nouveaux pour faciliter l’explication.
Il y a 2 différences avec le cas précédent : les options directory et filename.
Le baseDir est le même, tout comme la sendTo et les options post_baseDir.
L’option répertoire définit un autre « chemin relatif » pour le produit à destination. Il est marqué aux options accept définies après lui. Si une autre séquence de directory/accept suit dans le fichier de configuration, le deuxième répertoire est marqué pour les acceptations suivantes et ainsi de suite.
Les modèles accept/reject s’appliquent à l’URL de notification du message comme ci-dessus. Voici un exemple, voici quelques options de configuration ordonnées :
directory /my/new/important_location
accept .*IMPORTANT.*
directory /my/new/location/for_others
accept .*
Si la notification sélectionnée est, comme ci-dessus, ceci :
20150813161959.854 http://this.pump.com/ relative/path/to/IMPORTANT_product
Il a été sélectionné par la première option accept. Le chemin relatif distant devient /my/new/important_location … et sr_sender effectue la pseudo-livraison suivante :
envoie le fichier local [baseDir]/relative/path/to/IMPORTANT_product à destination/[post_baseDir]/my/new/important_location/IMPORTANT_product
Habituellement, cette façon d’utiliser sr_sender n’exigerait pas l’affichage du produit. Mais si post_broker and post_exchange sont fournis, et url , comme ci-dessus, est défini sur http://remote.apache.com, alors sr_sender reconstruirait :
Thème: v03.my.new.important_location.IMPORTANT_product
Notice: 20150813161959.854 http://remote.apache.com/ my/new/important_location/IMPORTANT_product
SHOVEL
shovel copie les messages sur un courtier (donné par l’option broker) à un autre (donné par l’option post_broker) soumis au filtrage par (exchange, subtopic, et éventuellement, accept/reject.)
L’option topicPrefix doit être définie sur :
pour pelleter les messages sr3_post(7)
shovel est un flux avec les préréglages suivants :
no-download True suppress_duplicates off
SUBSCRIBE
Subscribe est le composant de flux de téléchargement normal, qui se connectera à un courtier, télécharger les fichiers configurés, puis transférer les messages avec une baseUrl modifiée.
WATCH
Surveille un répertoire et publie des messages lorsque les fichiers dans le répertoire changent. Ses arguments sont très similaires à sr_post <sr_post. Dans la suite MetPX-Sarracenia, l’objectif principal est d’afficher la disponibilité et modifications de ses dossiers. Les abonnés utilisent sr_subscribe pour consommer le message et télécharger les fichiers changés.
Les messages sont envoyés à un serveur AMQP, également appelé courtier, spécifié avec l’option [ -pb|–post_broker broker_url ].
The [-post_baseUrl|–pbu|–url url] option specifies the protocol, credentials, host and port to which subscribers will connect to get the file.
Format of argument to the url option:
[ftp|http|sftp]://[user[:password]@]host[:port]/
or
[ftp|http|sftp]://[user[:password]@]host[:port]/
or
file:
L’option[-p|–chemin] indique à sr_watch ce qu’il faut chercher. Si le path spécifie un répertoire, sr_watches crée un message quand un fichier dans ce répertoire qui est créé, modifié ou supprimé. Si le path spécifie un fichier, sr_watch surveille uniquement ce fichier. Dans l’avis, il est spécifié avec le chemin du produit. Il y a généralement un message par fichier.
Un exemple d’une excution de sr_watch vérifiant un fichier:
sr3 --post_baseUrl sftp://stanley@mysftpserver.com/ --path /data/shared/products/foo --post_broker amqp://broker.com start watch/myflow
Ici, sr_watch vérifie les événements sur le fichier /data/shared/products/foo. Les paramètres par défaut des rapports d’événements si le fichier le fichier est modifié ou supprimé. Lorsque le fichier est modifié, sr_watch lit le fichier /data/shared/products/foo. et calcule sa somme de contrôle. Il construit ensuite un message, se connecte à broker.com en tant qu’utilisateur’guest’ (informations d’identification par défaut). et envoie le message aux valeurs par défaut vhost ‘/’ et échange ‘xs_stanley’ (échange par défaut)
Un abonné peut télécharger le fichier /data/shared/products/foo en se connectant en tant qu’utilisateur stanley. sur mysftpserver.com en utilisant le protocole sftp à broker.com en supposant qu’il a les informations d’identification appropriées.
La sortie de la commande est la suivante:
[INFO] v03.data.shared.products.foo '20150813161959.854 sftp://stanley@mysftpserver.com/ /data/shared/products/foo'
source=guest parts=1,256,1,0,0 sum=d,fc473c7a2801babbd3818260f50859de
Dans MetPX-Sarracenia, chaque article est publié sous un certain thème. Après le ‘[INFO]’, l’information suivante donne le fBtopic* du fichier publié. Les thèmes dans AMQP sont un champ hierarchique, avec chaque sous-thème séparé par une points. Dans MetPX-Sarracénie il est constitué d’un topic_prefix par défaut : version V02, d’une action post.., suivi par subtopic par défaut : le chemin du fichier séparé par des points, ici, data.shared.products.foo.
Après la hiérarchie des thèmes vient le corps de l’avis. Il se compose d’un temps 20150813161959.854, et l’url source du fichier dans les 2 derniers champs.
La ligne restante donne des informations qui sont placées dans l’en-tête du message amqp. Ici, il se compose de source=guest, qui est l’utilisateur amqp, parts=1,256,0,0,0,1.., qui proposent de télécharger le fichier en 1 partie de 256 octets (la taille réelle du fichier), suivi de 1,0,0,0. donne le nombre de blocs, le nombre d’octets restants et le nombre d’octets actuel. bloc. sum=d,fc473c7a2801babbd3818260f50859de mentionne les informations de la somme de contrôle, ici, d signifie la somme de contrôle md5 effectuée sur les données, et fc473c7a2801babbd3818260f50859de. est la valeur de la somme de contrôle. Lorsque l’événement sur un fichier est une suppression, sum=R,0 R signifie de supprimer un fichier.
Un autre exemple avec un fichier:
sr3 --post_baseDir /data/web/public_data --post_baseUrl http://dd.weather.gc.ca/ --path bulletins/alphanumeric/SACN32_CWAO_123456 -post_broker amqp://broker.com start watch/myflow
Par défaut, sr3_watch vérifie le fichier /data/web/public_data/bulletins/alphanumériques/SACN32_CWAO_123456 (concaténer le répertoire base_dir et le chemin relatif de l’url source pour obtenir le chemin du fichier local). Si le fichier change, il calcule sa somme de contrôle. Il construit ensuite un message, se connecte à broker.com en tant qu’utilisateur’guest’. (informations d’identification par défaut) et envoie le message aux valeurs par défaut vhost’/’ et exchange’sx_guest’ (échange par défaut)
Un abonné peut télécharger le fichier http://dd.weather.gc.ca/bulletins/alphanumeric/SACN32_CWAO_CWAO_123456 en utilisant http. sans authentification sur dd.weather.gc.ca.
Un exemple de vérification d’un répertoire:
sr3 -post_baseDir /data/web/public_data -post_baseUrl http://dd.weather.gc.ca/ --path bulletins/alphanumeric --post_broker amqp://broker.com start watch/myflow
Ici, sr3_watch vérifie la création de fichiers (modification) dans /data/web/public_data/bulletins/alphanumérique. (concaténer le répertoire base_dir et le chemin relatif de l’url source pour obtenir le chemin du répertoire). Si le fichier SACN32_CWAO_123456 est créé dans ce répertoire, sr3_watch calcule sa somme de contrôle. Il construit ensuite un message, se connecte à broker.com en tant qu’utilisateur’guest’. (informations d’identification par défaut) et envoie le message à exchange’amq.topic’ (échange par défaut)
Un abonné peut télécharger le fichier créé/modifié http://dd.weather.gc.ca/bulletins/alphanumeric/SACN32_CWAO_CWAO_123456 en utilisant http. sans authentification sur dd.weather.gc.ca.
WINNOW
winnow est un programme qui s’abonne aux notifications de fichiers, et réenregistre les notifications, en supprimant les notifications redondantes.
La méthode de décider quels messages d´annonce sont redondants varient selon le cas d´usage. Normalement, les messages comprenned un champs Identity qui avec une somme de contrôle du ficher, tel que décrit dans sr_post(7) Il y bien d´autres cas d´usage discutés dans Supprimer les doublons
winnow a les options suivante forcés:
no-download True
suppress_duplicates on
accept_unmatch True
La durée de vie des suppress_duplicates peut être ajustée, mais elle est toujours active.
winnow se connecte à un broker (souvent le même que le courtier d’affichage). et souscrit aux notifications d’intérêt. Sur réception d´un avis, il cherche sa sum dans son cache. s’il est trouvé, le fichier est déjà passé, de sorte que la notification est ignorée. Si ce n’est pas le cas, le fichier est nouveau, et le sum est ajouté. dans le cache et l’avis est affiché.
winnow peut être utilisé pour couper les messages de sr3_post, sr_poll(1) ou sr_watch(1) etc….. C’est utilisé lorsqu’il y a plusieurs sources de données identiques, de sorte que les clients ne téléchargent que le fichier une seule fois, à partir de la première source qui les a publié.
winnow peut être utilisé pour couper les messages de post, sr3_post, sr3_cpost, sr3_cpump, poll ou watch etc… C’est utilisé lorsqu’il y a plusieurs sources de données identiques, de sorte que les clients ne téléchargent que le fichier une seule fois, à partir de la première source qui les a publié.
Configurations
Si on a une configuration prête à l’emploi appelée q_f71.conf, elle peut être ajoutée à la liste des noms connus avec
subscribe add q_f71.conf
Dans ce cas-ci, q_f71.conf est inclus avec les exemples fournis, donc add le trouve dans les exemples et le copie dans le répertoire des configurations actives. Chaque fichier de configuration gère les consommateurs pour une seule file d’attente sur le courtier. Pour visualiser les configurations disponibles, utilisez:
$ subscribe list
configuration examples: ( /usr/lib/python3/dist-packages/sarra/examples/subscribe )
all.conf all_but_cap.conf amis.conf aqhi.conf cap.conf cclean_f91.conf
cdnld_f21.conf cfile_f44.conf citypage.conf clean_f90.conf cmml.conf cscn22_bulletins.conf
ftp_f70.conf gdps.conf ninjo-a.conf q_f71.conf radar.conf rdps.conf
swob.conf t_f30.conf u_sftp_f60.conf
user plugins: ( /home/peter/.config/sarra/plugins )
destfn_am.py destfn_nz.py msg_tarpush.py
general: ( /home/peter/.config/sarra )
admin.conf credentials.conf default.conf
user configurations: ( /home/peter/.config/sarra/subscribe )
cclean_f91.conf cdnld_f21.conf cfile_f44.conf clean_f90.conf ftp_f70.conf q_f71.conf
t_f30.conf u_sftp_f60.conf
On peut ensuite le modifier à l’aide de
$ subscribe edit q_f71.conf
(La commande d’édition utilise la variable d’environnement EDITOR, si elle est présente. Une fois les changements complétés, on peut démarrer la configuration avec
$ subscibe foreground q_f71.conf
Que contiennent les fichiers ? Voir la section suivante :
La barre oblique (/) est utilisée comme séparateur de chemin dans les fichiers de configuration Sarracenia sur tous les systèmes d’exploitation. L’utilisation de la barre oblique inverse comme séparateur () (tel qu’utilisé dans la cmd shell de Windows) risque de ne pas fonctionner correctement. Lorsque des fichiers sont lu dans Windows, le chemin d’accès est immédiatement converti en utilisant la barre oblique. Ceci est pour s’assurer que les options reject, accept, et strip peuvent filtrer des expressions correctement. C’est pour cela qu’il est toujours important d’utiliser la barre oblique (/) quand un séparateur est nécessaire.
Example:
directory A
accept X
Place les fichiers correspondant à X dans le répertoire A.
- au lieu::
accept X directory A
Place les fichiers correspondant à X dans le répertoire de travail actuel, et le paramètre directory A ne fait rien par rapport à X.
Pour fournir une description non fonctionnelle de la configuration ou des commentaires, utilisez des lignes commençant par #. Toutes les options sont sensibles aux majuscules et minuscules. Debug n’est pas le même que debug ou DEBUG. Il s’agit de trois options différentes (dont deux n’existent pas et n’auront aucun effet, mais devrait générer une avertissement ´unknown option´).
Les options et les paramètres de ligne de commande sont équivalents. Chaque paramètre de ligne de commande a une version longue correspondante commençant par’–’. Par exemple, -u est la forme courte de –url. On peut aussi spécifier cette option dans un fichier de configuration. Pour ce faire, utilisez la forme longue sans le’–’, suivi de sa valeur séparée par un espace. Les éléments suivants sont tous équivalents :
url <url>
-u <url>
–url <url>
Les réglages sont interprétés dans l’ordre. Chaque fichier est lu de haut en bas. par exemple :
sequence #1:
reject .*\.gif
accept .*
sequence #2:
accept .*
reject .*\.gif
Dans la séquence #1, tous les fichiers se terminant par ‘gif’ sont rejetés. Dans la séquence #2, le accept .* (qui accepte tout) est lu avant la déclaration du rejet, donc le rejet n’a aucun effet. Certaines options ont une portée globale, plutôt que d’être interprété dans l’ordre. Dans ces cas, la dernière déclaration remplace celle qu’il y avait plus tôt dans le fichier..
Les options qui doivent être réutilié dans de fichier de config différents peuvent être groupés dans des fichiers include:
–include <includeConfigPath>
The includeConfigPath would normally reside under the same config dir of its master configs. If a URL is supplied as an includeConfigPATH, then a remote configuraiton will be downloaded and cached (used until an update on the server is detected.) See Remote Configurations for details.
Environment variables, and some built-in variables can also be put on the right hand side to be evaluated, surrounded by ${..} The built-in variables are:
${BROKER_USER} - le nom d’utilisateur pour l’authentification auprès du courtier (par exemple, anonyme)
${PROGRAM} - le nom du composant (subscribe, shovel, etc…)
${CONFIG} - le nom du fichier de configuration en cours d’exécution.
${HOSTNAME} - le hostname qui exécute le client.
${RANDID} - Un ID aléatoire qui va être consistant pendant la duration d’une seule invocation.
${INSTANCE} - le numéro d’instance du processus.
flowCallbacks
Sarracenia utilise largement de petits extraits de code python qui personnalisent le traitement appelé flowCallback. Flow_callbacks définit et utiliser des paramètres supplémentaires
flowCallback sarracenia.flowcb.log.Log
Il existe également une forme plus courte pour exprimer la même chose:
callback log
Quoi qu’il en soit, le module fait référence au fichier sarracenia/flowcb/msg/log.py dans le package installé. Dans ce fichier, la classe Log est celle qui a été recherchée pour le point d’entré. Le fichier log.py inclus dans le package est le suivant:
from sarracenia.flowcb import FlowCB
import logging
logger = logging.getLogger( __name__ )
class Log(Plugin):
def after_accept(self,worklist):
for msg in worklist.incoming:
logger.info( "msg/log received: %s " % msg )
return worklist
C’est une classe python normale, déclarée comme enfant de la classe sarracenia.flowcb.FlowCB. Les méthodes (noms de fonction) dans le plugin décrivent quand ces routines seront appelées. Pour plus de détails, consultez le Programmer’s Guide
Pour ajouter un traitement spécial des messages, créez un module en python et faites-le inclure des points d’entrée.
Il existe également flowCallbackPrepend qui ajoute une classe flowCallback à l’avant de la liste (qui détermine l’ordre d’exécution relatif entre les classes flowCallback.)
Options callback
les rappels livrés avec metpx-sr3 suivent la convention suivante :
ils sont placés dans l’arborescence du répertoire sarracenia/flowcb.
le nom de la classe principale est le même que le nom du fichier qui la contient.
nous fournissons donc le sucre syntaxique suivant:
callback log (is equivalent to *flowCallback sarracenia.flowcb.log.Log* )
Il y a de même un callback_prepend à remplir.
Importation d’extensions
L’option import fonctionne d’une manière familière aux développeurs Python, qui les rends disponibles pour une utilisation par le noyau Sarracenia, ou flowCallback. Les développeurs peuvent ajouter des protocoles supplémentaires pour les messages ou transfert de fichiers. Par exemple:
import torr
serait un nom raisonnable pour un protocole de transfert pour récupérer des ressources avec le protocole bittorrent. Un squelette d’une telle chose ressemblerait à ceci
import logging
logger = logging.getLogger(__name__)
import sarracenia.transfer
class torr(sarracenia.transfer.Transfer):
pass
logger.warning("loading")
Pour plus de détails sur la mise en œuvre des prolongations, consultez le Programmer’s Guide
Plugins v2 Obsolètes
Il existe également un style de plugins plus ancien (v2). Qui sont généralement précédé du nom du plugin
msg_to_clusters DDI
msg_to_clusters DD
on_message msg_to_clusters
Un paramètre ‘msg_to_clusters’ est nécessaire par le plugin msg_to_clusters référencés dans le on_message les plugins v2 sont un peu plus encombrant à écrire. Ils sont inclus ici pour être complets, mais les utilisateurs doivent utiliser la version 3 (flowCallback ou extensions) discuté ensuite) lorsque cela est possible.
Raisons d’utiliser des plugins de style plus récents:
La prise en charge de l’exécution des plugins v2 est réalisée à l’aide d’un flowcb appelé v2wrapper. Il effectue beaucoup de traitement pour conclure les structures de données v3 pour ressembler à celles de la v2, puis a pour propager les modifications. C’est un peu cher.
les extensions de style plus récentes sont des modules python ordinaires, contrairement à v2 qui nécessitent des incantations magiques mineures.
lorsqu’un module v3 (flowCallback ou importé) présente une erreur de syntaxe, tous les outils de l’interpréteur python s’appliquent, ce qui donne beaucoup plus de commentaires au codeur. Avec la v2, il dit seulement qu’il y a quelque chose qui ne va pas, beaucoup plus difficile à déboguer.
l’api v3 est strictement plus puissante que la v2, car elle fonctionne sur des groupes de messages, plutôt que sur des messages individuels.
Environment Variables
On peut aussi utiliser des variables d´environnement avec la syntax ${ENV} ou ENV est le nom d´une variable d´environnement. S´il faut définir une variable d´environnement pour une utilisation par Sarracenia, on peut l´indiquer dans un fichier de configuration:
declare env HTTP_PROXY=localhost
Fichiers journal et Suivi
- debug
L’option de déboggage debug est identique à l’utilisation de loglevel debug.
logMessageDump (défaut: off) booléen flag s’il est défini, tous les champs d’un message sont imprimés, plutôt qu’une simple référence url/chemin.
- logEvents ( défaut after_accept,after_work,on_housekeeping )
émettre des messages de journal standard aux points donnés du traitement des messages. autres valeurs : on_start, on_stop, post, gather, … etc…
- loglevel ( défaut: info )
Le niveau de journalisation exprimé par la journalisation de python. Les valeurs possibles sont : critical, error, info, warning, debug.
–logStdout ( défaut: False ) CAS D’UTILISATION EXPÉRIMENTAL POUR DOCKER
logStdout désactive la gestion des journaux. Mieux utilisé sur la ligne de commande, car il y a certains risques de créer des fichiers stub avant que les configurations ne soient complètement analysées
sr3 --logStdout start
Tous les processus lancés héritent de leurs descripteurs de fichier du parent, donc toutes les sorties sont comme une session interactive.
Cela contraste avec le cas normal, où chaque instance prend soin de ses journaux, en tournant et en purgeant périodiquement. Dans certains cas, on veut que d’autres logiciels s’occupent des logs, comme dans docker, où c’est préférable pour tous que la journalisation soie en sortie standard.
Il n’a pas été mesuré, mais il y a une probabilité raisonnable que l’utilisation de logStdout avec de grandes configurations (des dizaines d’instances/processus configurés) entraînera soit une corruption des journaux, soit limitera la vitesse d’exécution de tous les processus à écrire à stdout.
- log_reject <True|False> ( défaut: False )
afficher un ligne de journal pour chaque message rejeté. Ceci peut produire des journeaux énorme. D’habitude utilisé uniquement lors du debogage.
- log <dir> ( défaut: ~/.cache/sarra/log ) (sur Linux)
Répertoire dans lequel stocker les fichiers journaux.
- statehost <False|True> ( défaut: False )
Dans les grands centres de données, l’annuaire de base peut être partagé entre des milliers de Nœuds. Statehost ajoute le nom du nœud après le répertoire de cache pour le rendre unique à chaque nœud. Ainsi, chaque nœud a ses propres fichiers d’état et journaux. Par exemple, sur un nœud nommé goofy, ~/.cache/sarra/log/ devient ~/.cache/sarra/goofy/log.
- logRotateCount <max_logs> ( défaut: 5 )
Nombre maximal de journaux archivés.
- logRotateInterval <duration>[<time_unit>] ( défaut: 1 jour == 86,400 secondes )
La durée de l’intervalle avec une unité de temps optionnelle (c’est-à-dire 5m, 2h, 3d)
- permLog ( défaut: 0600 )
Bits d’autorisation à définir sur les fichiers journaux.
Voir le Subscriber Guide <../How2Guides/subscriber.html> pour une discussion plus détaillée sur les options de journalisations et de techniques.
IDENTIFICATION (CREDENTIALS)
Normalement, on ne spécifie pas de mots de passe dans les fichiers de configuration. Ils sont plutôt placés dans le fichier d´information d´identifcation:
edit ~/.config/sr3/credentials.conf
Pour chaque url spécifié qui nécessite un mot de passe, on place une entrée correspondante dans credentials.conf. L’option broker définit toutes les informations d’identification pour se connecter au serveur RabbitMQ.
broker amqp{s}://<user>:<pw>@<brokerhost>[:port]/<vhost>
(par défaut: amqps://anonymous:anonymous@dd.weather.gc.ca/ )
Pour tous les programmes de sarracenia, les parties confidentielles des justificatifs d’identité sont stockées uniquement dans ~/.config/sarra/credentials.conf. Cela comprend les mots de passe pour la destination et le courtier ainsi que les paramètres requis par les composants. Une entrée par ligne. Exemples :
amqp://user1:password1@host/
amqps://user2:password2@host:5671/dev
amqps://usern:passwd@host/ login_method=PLAIN
sftp://user5:password5@host
sftp://user6:password6@host:22 ssh_keyfile=/users/local/.ssh/id_dsa
ftp://user7:password7@host passive,binary
ftp://user8:password8@host:2121 active,ascii
ftps://user7:De%3Aize@host passive,binary,tls
ftps://user8:%2fdot8@host:2121 active,ascii,tls,prot_p
https://ladsweb.modaps.eosdis.nasa.gov/ bearer_token=89APCBF0-FEBE-11EA-A705-B0QR41911BF4
Dans d’autres fichiers de configuration ou sur la ligne de commande, l’url n’inclut pas le mot de passe ou spécification de clé. L’url donné dans les autres fichiers est utilisé comme clé de recherche pour credentials.conf.
Details d’Identifiants
Vous devrez peut-être spécifier des options supplémentaires pour des entrées d’informations d’identification spécifiques. Ces détails peuvent être ajoutés après la fin de l’URL, avec plusieurs détails séparés par des virgules (voir les exemples ci-dessus).
Détails pris en charge
- ``ssh_keyfile=<path>`` - (SFTP) Chemin d’accès au fichier de clés SSH
- ``passive`` - (FTP) Utiliser le mode passif
- ``active`` - (FTP) Utiliser le mode actif
- ``binary`` - (FTP) Utiliser le mode binaire
- ``ascii`` - (FTP) Utiliser le mode ASCII
- ``ssl`` - (FTP) Utiliser SSL/FTP standard
- ``tls`` - (FTP) Utiliser FTPS avec TLS
- ``prot_p`` - (FTPS) Utiliser une connexion de données sécurisée pour les connexions TLS (sinon, du texte clair est utilisé)
- ``bearer_token=<token>`` (or ``bt=<token>``) - (HTTP) Jeton de porteur pour l’authentification
- ``login_method=<PLAIN|AMQPLAIN|EXTERNAL|GSSAPI>`` - (AMQP) Par défaut, la méthode de connexion sera automatiquement déterminée. Cela peut être remplacé en spécifiant explicitement une méthode de connexion, ce qui peut être nécessaire si un courtier prend en charge plusieurs méthodes et qu’une méthode incorrecte est automatiquement sélectionnée.
Note
Les informations d’identification SFTP sont facultatives, car sarracenia cherchera dans le répertoire .ssh et utilisera les informations d’identification SSH normales qui s’y trouvent.
Ces chaînes sont codées en URL, donc si un compte a un mot de passe avec un caractère spécial, son équivalent codé par l’URL peut être fourni. Dans le dernier exemple ci-dessus, %2f signifie que le mot de passe réel est: /dot8 L’avant-dernier mot de passe est : De:olonize. ( %3a étant la valeur codée url pour un caractère deux-points. )
TRAITEMENT PÉRIODIQUE
La plupart des traitements ont lieu à la réception d’un message, mais il y a une maintenance périodique qui se produit à chaque intervalle housekeeping (la valeur par défaut est de 5 minutes.) À chaque housekeeping tous les les plugins on_housekeeping configurés sont exécutés. Par défaut, trois sont présents :
log - imprime « housekeeping » dans le journal.
nodupe - vieillit les anciennes entrées dans le cache de réception, afin de minimiser sa taille.
memory - vérifie l’utilisation de la mémoire du processus et redémarre si elle est trop grande.
Le journal contiendra des messages des trois plugins à chaque intervalle de housekeeping, et si un traitement périodique supplémentaire est nécessaire, l’utilisateur peut configurer d’autres plugins à exécuter avec l’option on_housekeeping.
sanity_log_dead <interval> (défaut: 1.5*housekeeping)
L’option sanity_log_dead définit la durée à prendre en compte avant de redémarrer un composant.
nodup_ttl <off|on|999> (défaut: off)
Le nettoyage des éléments expirés dans la store de suppression des doublons se produit à chaque housekeeping.
RÉCUPÉRATION D’ERREUR
Les outils sont conçus pour fonctionner bien sans surveillance, et donc lorsque des erreurs transitoires se produisent, ils essayent de récupérer élégamment. Il y a des délais d’attente sur toutes les opérations, et en cas de défaillance détectée, le problème est noté pour une nouvelle tentative. Des erreurs peuvent se produire à plusieurs reprises :
Établir une connexion avec le courtier.
perte d’une connexion avec le courtier
établir une connexion au serveur de fichiers pour un fichier (à télécharger).
perte d’une connexion au serveur.
pendant le transfert de données.
Initialement, les programmes essaient de télécharger (ou d’envoyer) un fichier un nombre de fois fixe (tentatives, par défaut: 3). Si les trois tentatives de traitement du fichier échouent, le fichier est placé dans “réessayer”. Le programme poursuit ensuite le traitement des nouveaux éléments. Lorsqu’il n’y a pas de nouveaux éléments, le programme recherche un fichier à traiter dans la fil d’attente de nouvelles tentatives. Il vérifie ensuite si le fichier est vieux, au-delà du retry_expire (par défaut : 2 jours). Si le fichier n’a pas expiré, alors il déclenche une nouvelle série de tentatives de traitement du fichier. Si les tentatives échouent, il revient en arrière dans la fil d’attente de nouvelles tentatives.
Cet algorithme garantit que les programmes ne restent pas bloqués sur un seul mauvais produit qui empêche le reste de la fil d’attente en cours de traitement, et permet une récupération raisonnable et progressive, permettant aux nouvelles données de circuler et en envoyant les anciennes données de manière opportuniste lorsqu’il y a des lacunes.
Bien qu’un traitement rapide de bonnes données soit très souhaitable, il est important de ralentir en cas d’erreur. Souvent, les erreurs sont liées à la charge, et une nouvelle tentative rapide ne fera qu’empirer les choses. Sarracenia utilise le back-off exponentiel à de nombreux endroits pour éviter de surcharger un serveur lorsqu’il y a des erreurs. Le back-off peut s’accumuler au point où les nouvelles tentatives peuvent être séparées d’une minute ou deux. Une fois que le serveur recommence à répondre normalement, les programmes reviendront à la vitesse normale de traitement.
Si une panne dure un certain temps, on peut arrêter le flux, configurer attempts 0 pour remplir la file d’attente de nouvelles tentatives sans faire de vaines tentatives de téléchargement ou d’envoi. À la fin de la panne, remettez attempts à la normale et la file d’attente de nouvelles tentatives sera progressivement vidée lorsqu’il y aura de la place dans le flux de données actuel.
EXEMPLES
Voici un court exemple complet de fichier de configuration
broker amqps://dd.weather.gc.ca/
subtopic model_gem_global.25km.grib2.#
accept .*
Ce fichier ci-dessus se connectera au courtier dd.weather.gc.ca, se connectant en tant qu’anonyme avec mot de passe anonyme (par défaut) pour obtenir des annonces a propos de fichiers dans le répertoire http://dd.weather.gc.ca/model_gem_global/25km/grib2. Tous les fichiers qui arrivent dans ce répertoire ou en dessous seront téléchargés dans le répertoire actif (ou simplement imprimé en sortie standard si l’option -n a été spécifié.)
Divers exemples de fichiers de configuration sont disponibles ici :
QUEUES and MULTIPLE STREAMS
Lorsqu’il est exécuté, subscribe choisit un nom de fil d’attente, ou il écrit à un fichier nommé d’après le fichier de configuration donné comme argument pour subscribe avec un suffixe .queue ( .”configfile”.queue). Si l’abonnement est arrêté, les messages publiés continuent de s’accumuler sur le broker dans la fil d’attente. Lorsque le programme est redémarré, il utilise le nom de la fil d’attente stocké dans ce fichier pour se connecter à la même fil d’attente et ne perd aucun message.
Les téléchargements de fichiers peuvent être parallélisés en exécutant plusieurs abonnements à l’aide de la même fil d’attente. Les processus partageront la fil d’attente et téléchargerons une partie de ce qui a été sélectionné. Il suffit de lancer plusieurs instances d’abonnement dans le même utilisateur/répertoire à l’aide du même fichier de configuration.
Vous pouvez également exécuter plusieurs abonnements avec différents fichiers de configuration pour avoir plusieurs flux de téléchargement dans le même répertoire, et ce flux de téléchargement peut également être multi-flux.
Note
Alors que les courtiers gardent les files d’attente disponibles pendant un certain temps, les files d’attente prennent des ressources sur les courtiers, et sont nettoyés de temps en temps. Une fil d’attente à laquelle on n’accède pas pour une longue période (dépendante de la mise en œuvre) sera détruite. Une fil d’attente qui n’est pas accédé et ayant trop de fichiers (définis par l’implémentation) en fil d’attente seront détruits. Les processus qui meurent doivent être redémarrés dans un délai raisonnable pour éviter la perte de notifications.
report et report_exchange
Pour chaque téléchargement, par défaut, un message de rapport amqp est renvoyé au broker. Cela se fait avec l’option :
report <booléen> (défaut: True)
report_exchange <report_exchangename> (défaut: xreport|xs_*username* )
Lorsqu’un rapport est généré, il est envoyé au report_exchange configuré. Les composants administratifs publient directement sur xreport, tandis que les composants d’utilisateur publient sur le leur échanges (xs_*nom d’utilisateur*). Les démons de rapport copient ensuite les messages dans xreport après validation.
Ces rapports sont utilisés pour le réglage de la livraison et pour les sources de données afin de générer des informations statistiques. Définissez cette option sur False, pour empêcher la génération de rapports.
INSTANCES
Parfois, une instance d’un composant et d’une configuration ne suffit pas pour traiter et envoyer toutes les notifications disponibles.
instances <integer> (défaut:1)
L’option d’instance permet de lancer plusieurs instances d’un composant et d’une configuration. Lors de l’exécution de sender par exemple, un certain nombre de fichiers d’exécution sont créés. Dans le répertoire ~/.cache/sarra/sender/configName
A .sender_configname.state est créé, contenant le nombre d’instances.
A .sender_configname_$instance.pid est créé, contenant le PID du processus $instance.
Dans le répertoire ~/.cache/sarra/log:
Un .sender_configname_$instance.log est créé en tant que journal du processus $instance.
Note
Un bug connu dans l’interface de gestion ‘sr <sr.8.html>_ signifie que l’instance doit toujours être dans le fichier .conf (pas un .inc) et doit toujours être un nombre (pas une variable substituée ou une autre valeur plus complexe.
Note
FIXME: indiquez également l’emplacement de Windows… fichiers dot sur Windows?
Note
Alors que les courtiers gardent les files d’attente disponibles pendant un certain temps, les files d’attente prennent des ressources sur les courtiers, et sont nettoyés de temps en temps. Une fil d’attente qui n’est pas accédé et ayant trop de fichiers en fil d’attente (définis par l’implémentation) seront détruits. Les processus qui meurent doivent être redémarrés dans un délai raisonnable pour éviter la perte de notifications. Une fil d’attente à laquelle on n’accède pas pendant une longue période (dépendant de l’implémentation) sera détruite.
vip - ACTIVE/PASSIVE OPTIONS
sr3 peut être utilisé sur un seul nœud de serveur ou sur plusieurs nœuds. pourrait partager la responsabilité. D’autres, configurés séparément, haute disponibilité présente un vip (ip virtuel) sur le serveur actif. Si le serveur tombe en panne, le vip est déplacé sur un autre serveur. Les deux serveurs fonctionneraient sr3. Les options suivants contrôle ce genre de comportement:
vip <string> (None)
Lorsque vous n’exécutez qu’un seul sr3 sur un serveur, ces options ne sont pas définies et sr3 fonctionnera en mode ‘standalone’.
Dans le cas des courtiers en grappe, vous devez définir les options pour l’option vip en mouvement.
vip 153.14.126.3
Lorsque sr3 ne trouve pas le vip, il dort pendant 5 secondes et réessaie. S´il possède le vip, il consomme et traite un message, puis revérifie le vip. lorque plus qu´une addresse est setté commen vip, la possesion de n´importe laquelle dans la liste est suffisante.
[–blocksize <value>] (default: 0 (auto))
This blocksize option controls the partitioning strategy used to post files. The value should be one of:
0 - calcul automatique d'une stratégie de partitionnement appropriée (par défaut)
1 - toujours envoyer des fichiers entiers en une seule partie.
<blocksize> - utilisation d'une taille de partition fixe (exemple : 1M)
Les fichiers peuvent être publiés en plusieurs parties. Chaque partie a une somme de contrôle séparée. Les pièces et leurs sommes de contrôle sont stockées dans le cache. Les cloisons peuvent traverser le réseau séparément, et en parallèle. Lorsque les fichiers changent, les transferts sont optimisé en n’envoyant que des portions qui ont changé.
L’option outlet permet la sortie finale d’être autre chose qu’un post. Voir sr3_cpump(1) pour plus de détails.
[-pbd|–post_baseDir <path>] (facultatif)
L’option post_baseDir fournit le chemin du répertoire qui, lorsqu’il est combiné (ou trouvé) dans le chemin d’accès donné, donne le chemin absolu local vers le fichier de données à enregistrer. La post_baseDir du chemin sera supprimée du avis. Pour sftp : url’s il peut être approprié de spécifier un chemin relatif à un compte utilisateur. Un exemple de cette utilisation serait : -pbd ~user -url sftp:user@host pour file : url’s, baseDir n’est généralement pas approprié. Pour publier un chemin absolu, omettez le paramètre -pbd, et spécifiez simplement le chemin complet en argument.
post_baseUrl <url> (OBLIGATOIRE)
L’option post_baseUrl définit comment obtenir le fichier…. il définit le protocole, hôte, port, et optionnellement, l’utilisateur. C’est une bonne pratique de ne pas inclure les mots de passe dans l´URL.
post_exchange <name> (default: xpublic)
L’option post_exchange, qui permet d’échanger la nouvelle notification. sera publié. Dans la plupart des cas, il s’agit d’un’xpublic’.
Chaque fois qu’une avis se produit pour un produit, un utilisateur peut définir de déclencher un script. L’option on_post serait utilisée pour faire une telle configuration.
post_exchangeSplit <number> (défaut: 0)
L’option post_exchangeSplit ajoute un suffixe à deux chiffres résultant d’une division entière du dernier digit de la somme de contrôle, afin de répartir les avis entre un certain nombre d’échanges, selon la valeur de leur somme de contrôle. C’est utilisé dans les pompes à trafic élevé pour permettre des instances multiples de winnow, ce qui ne peut pas être instancié de la manière normale. exemple:
post_exchangeSplit 5
post_exchange xwinnow
se traduira par l’envoi de messages à cinq échanges nommées xwinnow00, xwinnow01, xwinnow02, xwinnow03 et xwinnow04, où chaque échange ne recevra qu’un cinquième du flux total. xinnow01 recevra tous les messages dont la reste quand sa somme de contrôle est divisé par 5 est 1.
Remote Configurations
On peut spécifier des URI comme fichiers de configuration, plutôt que des fichiers locaux. Exemple :
–config http://dd.weather.gc.ca/alerts/doc/cap.conf
Au démarrage, sr3 vérifie si le fichier local cap.conf existe dans le répertoire répertoire de configuration local. Si c’est le cas, alors le fichier sera lu pour trouver une ligne comme ça :
–remote_config_url http://dd.weather.gc.ca/alerts/doc/cap.conf
Dans ce cas, il vérifiera l’URL distante et comparera le temps de modification. du fichier distant contre le fichier local. Le fichier distant n’est pas plus récent ou ne peut pas être modifié. est atteint, alors le composant continuera avec le fichier local.
Si le fichier distant est plus récent ou s’il n’y a pas de fichier local, il sera téléchargé, et la ligne remote_config_url_config_url y sera pré-pendue, de façon à ce qu’elle continue pour se mettre à jour à l’avenir.
Extensions
On peut remplacer ou ajouter des fonctionnalités avec des scripts python.
Sarracenia est livré avec une variété d’exemples de plugins, et en utilise certains pour implémenter des fonctionnalités de base, tels que la journalisation (implémentée par défaut en utilisant des plugins msg_log, file_log post_log):
$ sr3 list fcb
Provided callback classes: ( /home/peter/Sarracenia/sr3/sarracenia )
flowcb/filter/deleteflowfiles.py flowcb/filter/fdelay.py flowcb/filter/pclean_f90.py flowcb/filter/pclean_f92.py
flowcb/gather/file.py flowcb/gather/message.py flowcb/line_log.py flowcb/line_mode.py
flowcb/log.py flowcb/nodupe.py flowcb/pclean.py flowcb/post/message.py
flowcb/retry.py flowcb/sample.py flowcb/script.py flowcb/v2wrapper.py
flowcb/work/rxpipe.py
$
Les utilisateurs peuvent placer leurs propres scripts dans le sous-répertoire de script dans leur répertoire de configuration ( sur Linux, le ~/.config/sarra/plugins).
flowCallback et flowCallbackPrepend <class>
La directive flowCallback prend une classe à charger et peut analyser les points d’entrée comme argument
flowCallback sarracenia.flowcb.log.Log
Avec cette directive dans un fichier de configuration, la classe Log trouvée dans le package installé sera utilisée. Ce module enregistre les messages after_accept (après que les messages sont passé par les masques d’accept/reject) et le after_work (après le téléchargement ou l’envoi du fichier). Voici le code source pour cette classe de rappel
import json
import logging
from sarracenia.flowcb import FlowCB
logger = logging.getLogger(__name__)
class Log(FlowCB):
def __init__(self, options):
# FIXME: should a logging module have a logLevel setting?
# just put in a cookie cutter for now...
if hasattr(options, 'logLevel'):
logger.setLevel(getattr(logging, options.logLevel.upper()))
else:
logger.setLevel(logging.INFO)
def after_accept(self, worklist):
for msg in worklist.incoming:
logger.info("accepted: %s " % msg_dumps(msg) )
def after_work(self, worklist):
for msg in worklist.ok:
logger.info("worked successfully: %s " % msg.dumps() )
Si vous avez plusieurs rappels configurés, ils seront appelés dans le même ordre que dans fichier de configuration. Les composants de sr3 sont souvent différenciés par les rappels configurés. Par exemple, un watch est un flux avec la classe sarracenia.flowcb.gather.file.File qui est utilisé pour analyser les répertoires. Un besoin courant lorsqu’une source de données n’est pas facilement accessible avec les scripts python est d’utiliser le rappel de script:
flowCallbackPrepend sarracenia.flowcb.script.Script
script_gather get_weird_data.sh
En utilisant la variante _prepend de l’option flowCallback, le rappel de script aura le point d’entrée de la classe, avant le rappel de fichier… Donc, un script sera exécuté, puis le répertoire sera vérifié pour les nouveaux fichiers. Voici une partie de la classe de rappel Script
import logging
from sarracenia.flowcb import FlowCB
import subprocess
logger = logging.getLogger(__name__)
class Script(FlowCB):
.
.
.
def run_script( self, script ):
try:
subprocess.run( self.o.script_gather, check=True )
except Exception as err:
logging.error("subprocess.run failed err={}".format(err))
logging.debug("Exception details:", exc_info=True)
def gather(self ):
if hasattr( self.o, 'script_gather') and self.o.script_gather is not None :
self.run_script( self.o.script_gather )
return []
Identity
On peut utiliser la directive import pour ajouter de nouveaux algorithmes de somme de contrôle en sous-classant sarracenia.identity.Identity.
Transfer
On peut ajouter la prise en charge de méthodes supplémentaires de téléchargement de données par sous-classification sarracenia.transfer.Transfer.
Les scripts de protocole de transfert doivent être déclarés à l’aide de l’option import. sauf pour les fonctions intégrées ciblées, un module registered_as qui définit une liste des protocoles fournis par ces fonctions. Exemple:
- def registered_as(self) :
return [‘ftp’,’ftps’]
Voir le Programming Guide pour plus d’informations sur le développement d’extensions.
ROLES - feeder/admin/declare
d’intérêt que pour les administrateurs
Les options d’administration sont définies à l’aide de:
edit ~/.config/sr3/admin.conf
L’option feeder spécifie le compte utilisé par défaut pour les transferts système pour les composants tels que sr_shovel, sr_sarra et sr_sender (lors de publication).
– feeder amqp{s}://<user>:<pw>@<post_brokerhost>[:port]/<vhost> (valeur par défaut : Aucun) – admin <nom> (par défaut : Aucun)
L’utilisateur administrateur est utilisé pour effectuer des opérations de maintenance sur la pompe, telles que la définition des autres utilisateurs. La plupart des utilisateurs sont définis à l’aide de l’option declare. Le chargeur peut également être déclaré de cette manière.
declare <role> <name> (pas de défaut)
subscriber
Un subscriber (abonné) est un utilisateur qui ne peut s’abonner qu’aux données et renvoyer des messages de rapport. Les abonnés ne sont pas autorisés à injecter des données. Chaque abonné a un central xs_<user>nommé sur la pompe, où si un utilisateur est nommé Acme, l’échange correspondant sera xs_Acme. Cet échange est l’endroit où un processus sr_subscribe enverra ses messages de rapport.
Par convention/défaut, l’utilisateur anonyme est créé sur toutes les pompes pour permettre l’abonnement sans un compte spécifique.
source
Un utilisateur autorisé à s’abonner ou à générer des données. Une source ne représente pas nécessairement une personne ou un type de données, mais plutôt une organisation responsable des données produites. Donc, si une organisation recueille et met à disposition dix types de données avec un seul contact, e-mail, ou numéro de téléphone, toute question sur les données et leur disponibilité par rapport aux activités de collecte peuvent alors utiliser un seul compte “source”.
Chaque source reçoit un échange xs_<utilisateur> pour l’injection de publications de données. Cela est comme un abonné pour envoyer des messages de rapport sur le traitement et la réception des données. La source peut également avoir un échange xl_<utilisateur> où, selon les configurations de routage des rapports, les messages de rapport des consommateurs seront envoyés.
feeder
Un utilisateur autorisé à écrire à n’importe quel échange. Une sorte d’utilisateur de flux administratif, destiné à pomper des messages lorsque aucune source ou abonné ordinaire n’est approprié pour le faire. Doit être utilisé de préférence au lieu de comptes d’administrateur pour exécuter des flux.
Les informations d’identification de l’utilisateur sont placées dans le credentials.conf et sr3 –users declare mettra à jour le courtier pour accepter ce qui est spécifié dans ce fichier, tant que le mot de passe de l’administrateur est déjà correct.
FICHIERS DE CONFIGURATION
Alors qu’on peut gérer les fichiers de configuration à l’aide de la fonction add, remove, list, edit, disable, et enable actions, on peut aussi tout faire. des mêmes activités manuellement en manipulant les fichiers dans les paramètres. dans l’annuaire de l’entreprise. Les fichiers de configuration pour une configuration sr_subscribe. appelé myflow serait ici :
linux : ~/.config/sarra/subscribe/myflow.conf (selon : XDG Open Directory Specication )
Windows : %AppDir%/science.gc.ca/sarra/myflow.conf, cela pourrait être : C:UserspeterAppDataLocalscience.gc.casarrasarramyflow.conf
MAC : FIXME.
Le sommet de l’arborescence a ~/.config/sarra/default.conf qui contient les paramètres suivants sont lus par défaut pour tout composant au démarrage. Dans le même répertoire, ~/.config/sarra/credentials.conf contient des informations d’identification (mots de passe) à utiliser par sarracenia (IDENTIFICATION (CREDENTIALS) pour plus de détails. ).
On peut également définir la variable d’environnement XDG_CONFIG_HOME pour remplacer le placement par défaut, ou bien Les fichiers de configuration individuels peuvent être placés dans n’importe quel répertoire et invoqués avec la commande chemin complet. Lorsque des composants sont invoqués, le fichier fourni est interprété comme un fichier (avec un suffixe.conf conf supposé.) S’il n’est pas trouvé comme chemin d’accès au fichier, alors l’option recherchera dans le répertoire de configuration du composant ( config_dir / component) pour un fichier.conf correspondant.
S’il n’est toujours pas trouvé, il le recherchera dans le répertoire de configuration du site. (linux : /usr/share/default/sarra/component).
Enfin, si l’utilisateur a défini l’option remote_config sur True et s’il dispose de sites web configurés où l’on peut trouver des configurations (option remote_config_config_url), Le programme essaiera de télécharger le fichier nommé à partir de chaque site jusqu’à ce qu’il en trouve un. En cas de succès, le fichier est téléchargé dans config_dir/Downloads et interprété par le programme à partir de là. Il y a un processus similaire pour tous les plugins qui peuvent être interprété et exécuté à l’intérieur des composantes de la Sarracenia. Les composants chercheront en premier lieu dans le répertoire plugins dans l’arbre de configuration des utilisateurs, puis dans le site, puis dans le paquet sarracenia lui-même, et finalement il regardera à distance.
OPTIONS DE COMPATIBILITÉ SUNDEW
Pour la compatibilité avec Sundew, il existe des options de livraison supplémentaires qui peuvent être spécifiées.
destfn_script <script> (défaut:None)
Cette option définit un script à exécuter lorsque tout est prêt pour la livraison du produit. Le script reçoit une instance de la classe sender. Le script prends le parent comme argument, et par exemple, une modification de parent.msg.new_file changera le nom du fichier écrit localement.
filename <mots-clé> (défaut:None)
De MetPX Sundew, le support de cette option donne toutes sortes de possibilités pour définir le nom de fichier distant. Certains keywords sont basés sur le fait que les noms de fichiers MetPX Sundew ont cinq (à six) champs de chaîne de caractères séparés par des deux-points.
La valeur par défaut sur Sundew est NONESENDER, mais dans l’intérêt de décourager l’utilisation de la séparation par des deux-points dans les fichiers, le défaut dans Sarracenia est WHATFN.
Les mots-clés possibles sont :
- None
Aucune modification du nom de fichier (enlever toute interprétation de style Sundew) N.B. différent de NONE décrit plus loin.
- WHATFN
la première partie du nom de fichier Sundew (chaîne de caractères avant le premier : )
- HEADFN
Partie EN-TETE du nom de fichier Sundew
- SENDER
le nom de fichier Sundew peut se terminer par une chaîne SENDER=<string> dans ce cas, la <string> sera le nom de fichier distant
- NONE
livrer avec le nom du fichier Sundew complet (sans :SENDER=…)
- NONESENDER
livrer avec le nom de fichier Sundew complet (avec :SENDER=…)
- TIME
horodatage ajouté au nom de fichier. Exemple d’utilisation : WHATFN:TIME
- DESTFN=str
déclaration str direct du nom de fichier
- SATNET=1,2,3,A
Paramètres d’application satnet interne cmc
- DESTFNSCRIPT=script.py
appeler un script (identique à destfn_script) pour générer le nom du fichier à écrire
accept <regexp pattern> [<keyword>]
Keyword peut être ajouté à l’option accept. Le keyword est une des options filename. Un message qui correspond au modèle accept regexp aura son remote_file appliqué à cette option de mot-clé. Ce mot-clé a la priorité sur le précédent nom de fichier.
Le regexp pattern peut être utilisé pour définir des parties du répertoire si une partie du message est placée entre parenthèses. sender peut utiliser ces parties pour générer le nom du répertoire. Les chaînes de parenthèses entre les guillemets rst remplaceront le mot-clé ${0} dans le nom du répertoire… le second {1} $ etc.
Exemple d’utilisation
filename NONE
directory /this/first/target/directory
accept .*file.*type1.*
directory /this/target/directory
accept .*file.*type2.*
accept .*file.*type3.* DESTFN=file_of_type3
directory /this/${0}/pattern/${1}/directory
accept .*(2016....).*(RAW.*GRIB).*
Un message sélectionné par le premier accept sera remis inaltérée dans le premier répertoire.
Un message sélectionné par le deuxième accept sera remis inaltérée dans deuxième répertoire.
Un message sélectionné par le troisième accept sera renommé « fichier_de_type3 » dans le deuxième répertoire.
Un message sélectionné par le quatrième accept sera remis inaltérée à un répertoire.
Ça sera appelé /ce/20160123/modèle/RAW_MERGER_GRIB/répertoire si la notice du message ressemble à cela:
20150813161959.854 http://this.pump.com/ relative/path/to/20160123_product_RAW_MERGER_GRIB_from_CMC
Field Replacements
Dans MetPX Sundew, le format de la nomination de fichier est beaucoup plus stricte, et est spécialisée pour une utilisation aves les données du World Meteorological Organization (WMO). Notez que la convention du format des fichiers est antérieure, et n’a aucun rapport avec la convention de dénomination des fichiers de WMO actuellement approuvée, et est utilisé strictement comme format interne. Les fichiers sont séparés en six champs avec deux points. Le premier champ, DESTFN, est le “Abbreviated Header Line (AHL)” de WMO (style 386) ou les blancs sont remplacé avec des traits de soulignement
TTAAii CCCC YYGGGg BBB ...
(voir le manuel de WMO pour plus de détails) suivis de chiffres pour rendre le produit unique (cela est vrai en théorie, mais pas en pratique vu qu’il existe un grand nombre de produits qui ont les mêmes identifiants). La signification du cinquième champ est une priorité, et le dernier champ est un horodatage. La signification des autres champs varie en fonction du contexte. Exemple de nom de fichier
SACN43_CWAO_012000_AAA_41613:ncp1:CWAO:SA:3.A.I.E:3:20050201200339
Si un fichier est envoyé à Sarracenia et qu’il est nommé selon les conventions de Sundew, les champs de substitution suivants seront disponibles:
${T1} remplacer par le bulletin T1
${T2} remplacer par le bulletin T2
${A1} remplacer par le bulletin A1
${A2} remplacer par le bulletin A2
${ii} remplacer par le bulletin ii
${CCCC} remplacer par le bulletin CCCC
${YY} remplacer par le bulletin YY (obs. jour)
${GG} remplacer par le bulletin GG (obs. heure)
${Gg} remplacer par le bulletin Gg (obs. minute)
${BBB} remplacer par le bulletin bbb
${RYYYY} remplacer par l'année de réception
${RMM} remplacer par le mois de réception
${RDD} remplacer par le jour de réception
${RHH} remplacer par l'heure de réception
${RMN} remplacer par la minute de réception
${RSS} remplacer par la seconde de réception
Les champs ‘R’ proviennent du sixième champ, et les autres viennent du premier champ. Lorsque des données sont injectées dans Sarracenia à partir de Sundew, l’en-tête du message sundew_extension fournira la source de ces substitions même si ces champs ont été supprimés des fichiers livrés.