Conteneur Docker — INOWATCH

Conteneur DockerDeux cas se présentent, et ils n'appellent pas la même réponse.Cas 1 — un service HTTP : utilisez un MONITEUR, pas un heartbeatSi le conteneur expose une URL joignable (une API, un frontend), déclarez-le comme moniteur dans /inowatch/moniteurs. C'est plus simple, plus riche (temps de réponse, certificat, uptime 90 jours) et cela ne demande aucune modification du service.Ajoutez si possible un endpoint /health qui vérifie ce qui compte vraiment — base de données joignable, dépendance externe accessible — et pointez le moniteur dessus avec un mot-clé attendu dans la réponse. C'est ce qui distingue « le conteneur tourne » de « le service fonctionne ».Cas 2 — un travailleur sans HTTP : heartbeatUn consommateur de file, un cron interne, un service qui ne répond à rien : là, seul un heartbeat peut dire qu'il est vivant.Node

// Bat le heartbeat à la fin de chaque cycle de travail.
const BEAT = process.env.INOWATCH_BEAT_URL;   // https://api…/api/inowatch/beat/mon-slug
const KEY = process.env.INOWATCH_BEAT_KEY;    // INOWTC_HB_…

async function beat(failed = false) {
  if (!BEAT || !KEY) return;                  // service branché sans surveillance : on n'échoue pas

  try {
    await fetch(`${BEAT}${failed ? '?failed=1' : ''}`, {
      method: 'POST',
      headers: { 'X-Beat-Key': KEY },
      signal: AbortSignal.timeout(5000),
    });
  } catch {
    // Un battement raté ne doit JAMAIS faire échouer le travail qu'il observe.
    // Le silence sera de toute façon signalé par INOWATCH.
  }
}

// Dans la boucle de travail
try {
  await traiterLot();
  await beat();
} catch (error) {
  await beat(true);
  throw error;
}

Python

python

import os, requests

BEAT = os.environ.get("INOWATCH_BEAT_URL")
KEY = os.environ.get("INOWATCH_BEAT_KEY")

def beat(failed: bool = False) -> None:
    if not BEAT or not KEY:
        return
    try:
        requests.post(
            BEAT + ("?failed=1" if failed else ""),
            headers={"X-Beat-Key": KEY},
            timeout=5,
        )
    except Exception:
        pass  # jamais bloquant

Shell, dans un conteneurSi le service tourne sous un superviseur qui exécute un script :

bash

/app/travail.sh && curl -fsS -X POST "$INOWATCH_BEAT_URL" -H "X-Beat-Key: $INOWATCH_BEAT_KEY" >/dev/null

Variables DokployAjoutez-les dans l'onglet « Environment » de l'application :

dotenv

INOWATCH_BEAT_URL=https://messagerie.inovertix.com/api/inowatch/beat/mon-slug
INOWATCH_BEAT_KEY=INOWTC_HB_…

Le code ci-dessus ne fait rien si elles sont absentes : un service déployé ailleurs, ou en local, démarre normalement sans surveillance. C'est délibéré — une dépendance obligatoire à la supervision transforme le gardien en point de défaillance.Trois règles

Battre APRÈS le travail, pas avant. Un battement au démarrage prouve seulement que le service a démarré ; une boucle bloquée depuis six heures continuerait de battre.

Ne jamais faire échouer le travail à cause d'un battement raté. Le silence sera signalé de toute façon, et c'est bien suffisant.

Cadence attendue = intervalle réel du cycle, pas sa durée. Un travailleur qui traite un lot toutes les 5 minutes déclare 5 minutes, même si un lot prend 30 secondes.

Et les sondes d'INOWATCH elles-mêmes ?Elles n'ont rien à brancher : les mesures de disponibilité sont réalisées par INOVERTIX depuis une machine extérieure à CONTROL, et cette machine se surveille elle-même. Vous n'avez à déclarer que vos tâches.