Un moniteur de job peut identifier les jobs qui pénalisent les performances système. Vous pouvez personnaliser les types de jobs sur lesquels le moniteur se concentre en spécifiant certains critères de jobs sur l'écran Job Monitors General Properties. Cette spécification peut être très générale : « tous les jobs de
Moniteurs de jobs

l’utilisateur GREG »
ou très précise : « les jobs appartenant
à GREG commençant avec « PRE* » de
type Batch ».
Le moniteur démarre et trouve
tous les jobs qui correspondent aux
critères de jobs puis, selon celles des 19 mesures actives, recherche des informations
sur ces jobs. Si un job dépasse
une mesure prédéfinie, le moniteur
se déclenche.
Le moniteur de job offre tellement
de possibilités d’automatisation qu’il
est impossible d’en donner toute la
liste. Voici quelques idées :
- Ecrire un programme capable d’accepter
des variables dont la finalité
est d’activer des commandes et des
API qui contiennent un job si la CPU
dépasse 60 % d’utilisation pendant
plus de trois minutes. Faites cela
dans le moniteur en définissant un
intervalle d’une minute et en ordonnant
au moniteur de se déclencher si
l’utilisation de la CPU pour n’importe
quel job dépasse 60 % pour
trois intervalles. Si le moniteur se déclenche,
passez les éléments suivants
au programme : &JOBNAME, &JOBNUMBER,
&JOBUSER. Sur chaque
moniteur, vous pouvez définir une
valeur à laquelle le moniteur se déclenche
et une seconde valeur à laquelle
il se réinitialise. Par exemple,
vous pourriez établir une valeur de
déclenchement de job à 60 % d’utilisation
et une valeur de réinitialisation
de 50 %. Le moniteur se déclenchera
donc quand le job dépassera 60 % d’utilisation. Quand le job descendra
au-dessous de 50 %, le trigger
se réinitialisera et recommencera à
surveiller une instance dans laquelle
l’utilisation du job dépasse à nouveau
60 %. Quand le moniteur se réinitialise,
l’administrateur peut appeler
le programme (via la commande
reset) pour qu’il libère le job parce
que sa pause a été suffisamment
longue. - S’il est urgent qu’une application
particulière finisse, il faut l’empêcher
d’être mise en attente parce qu’elle
attend la réponse à un message. Il
faut donc créer un moniteur de job
qui examine tous les jobs de cette application.
Ensuite, utilisez les paramètres
de remplacement suivants
pour signifier au moniteur quel job
est en attente d’un message dans son
journal de job, et répondre à l’application
automatiquement afin qu’elle
ne marque pas de pause. Les paramètres
que vous devez inclure sont
&JOBNAME (le nom du job qui cause
le déclenchement ou la réinitialisation
du moniteur), &JOBNUMBER
(le numéro du job), &JOBUSER (le
nom de l’utilisateur exécutant le
job), &MSGID (le numéro ID du
message causant le déclenchement
ou la réinitialisation) et &MSGSEV (la
gravité du message) et &MSGTYPE
(le type du message causant le déclenchement
ou la réinitialisation).
Téléchargez cette ressource

Rapport mondial 2025 sur la réponse à incident
Dans ce nouveau rapport, les experts de Palo Alto Networks, Unit 42 livrent la synthèse des attaques ayant le plus impacté l'activité des entreprises au niveau mondial. Quel est visage actuel de la réponse aux incidents ? Quelles sont les tendances majeures qui redessinent le champ des menaces ? Quels sont les défis auxquels doivent faire face les entreprises ? Découvrez les top priorités des équipes de sécurité en 2025.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- DSI en assurance : gardien du temple ou moteur de la transformation ?
- Ransomware : persistance des cyberattaques à l’échelle mondiale
- Cybersécurité : l’IA générative rebat les cartes du cybercrime
- Le World Cyber Ranking, 1er classement mondial de la cybersécurité des entreprises
- Comment le Quarter Plan permet d’aligner IT et Métiers pour délivrer
