Scénarios nommés

Depuis la 0.0.70, regroupez la sélection des conteneurs, les ressources et les règles dans un scénario, puis lancez-le avec une commande courte.

1. Définir les scénarios

Ajoutez ces définitions dans /etc/monit-docker/monit-docker.yml. Adaptez les noms des conteneurs et utilisez un répertoire d’état persistant accessible en écriture.

scenarios:
  web-stats:
    description: Read web container CPU and memory usage
    mode: stats
    select:
      name: ['web-*']
    resources: [cpu_percent, mem_usage]
  web-guard:
    description: Restart web containers after sustained high memory usage
    mode: cron
    select:
      name: ['web-*']
    rules:
      - 'mem_percent > 90 ? restart'
    state-file: /var/lib/monit-docker/web-guard.json
    cooldown: 300
    max-restarts: 3
    trigger-after: 120
    max-gap: 90

2. Vérifier et exécuter

monit-docker scenario list
monit-docker scenario show web-guard
monit-docker check-config
monit-docker run web-stats
monit-docker run web-guard --dry-run
monit-docker run web-guard

La liste, l’affichage et la validation fonctionnent sans Docker. Les scénarios stats lisent les mesures une fois ; cron évalue les règles une fois ; serve assure une surveillance continue. Le mode par défaut est cron. La simulation n’exécute aucune action et ne construit pas de série d’observations persistante.

3. Programmer un scénario

Pour un passage chaque minute, ajoutez cette ligne à la crontab, en adaptant le chemin de l’exécutable :

* * * * * /usr/local/bin/monit-docker run web-guard

Cet exemple attend deux minutes de dépassement continu, sans intervalle supérieur à 90 secondes entre deux observations. Le premier dépassement ne déclenche donc pas immédiatement un redémarrage. Conservez le même compte et le même fichier d’état pour préserver les délais, les budgets et la maintenance.

4. Sélection et limites

Chaque scénario exige select ou all: true. Les sélecteurs globaux ne peuvent pas remplacer ceux du scénario. Chaque invocation lance un scénario ; cette version ne définit pas de succession d’étapes et ne fournit pas de planificateur intégré. Les commandes HTTP manuelles continuent d’utiliser la commande complète serve. Les messages générés et les valeurs de reason restent en anglais.

5. Essayer sur la démo

Sur le serveur de démonstration, le scénario demo-stats lit uniquement les mesures des deux conteneurs de test :

sudo docker exec monit-demo-agent monit-docker run demo-stats

Il ne déclenche aucune action. Consultez la source de référence pour les paramètres complets, les imports et les modèles de configuration.

Consultez le contrat configuration et commandes pour les priorités, les valeurs par défaut, les sélecteurs et les codes de sortie.

Par défaut, l’agent attend 60 secondes la fin d’une commande Docker exec. Réglez kwargs.exec_timeout sur l’alias de commande (1 à 86 400 secondes). Après expiration, le résultat est inconnu : vérifiez le conteneur avant de réessayer, car la commande peut encore être en cours.