Points de contrôle

Cette page détaille, composant par composant, ce qu’il faut superviser et comment le contrôler. Pour savoir quels contrôles s’appliquent à votre installation, partez de Superviser une installation tout-en-un ou de Superviser une installation séparée.

Voir aussi

Sondes Nagios — Scripts de sondes Nagios cités dans cette page.

Supervision commune à toutes les machines

Système

• Utilisation CPU, mémoire, load average

• Espace disque, en particulier :

  • /var/lib/docker (images et conteneurs) ;

  • /opt/<INSTANCE_NAME> (données, dont la base de données sur infra_manager / api_manager) ;

  • /opt/traefik (configuration et certificats traefik).

• Synchronisation de l’heure (NTP/chrony) : un décalage d’horloge casse les validations TLS et les identifiants TURN éphémères.

• Démon Docker actif : systemctl is-active docker.

Cluster Docker Swarm

Sur un manager de chaque cluster :

# Tous les nœuds doivent être Ready / Active
docker node ls

# Chaque service doit avoir REPLICAS = x/x (ex. 2/2)
docker service ls

Sondes recommandées :

• Nœuds : alerte si un nœud n’est pas Ready ou n’est pas Active.

• Services : alerte si le nombre de réplicas en cours est inférieur au nombre attendu :

  docker service ls --format '{{.Name}} {{.Replicas}}' \
    | grep -v -E '_(db|logapidb|mysqlbackup) ' \
    | awk '{split($2,r,"/"); if (r[1] != r[2]) {print "KO " $0; e=1}} END {exit e}'
  

  Trois services sont exclus de ce contrôle, car il est normal qu’ils soient à 0/1 :

  • <INSTANCE_NAME>_db et <INSTANCE_NAME>_logapidb : tâches uniques de création et de mise à jour des bases de données. Elles s’exécutent à chaque déploiement, puis s’arrêtent (restart_config: condition: none). Contrôlez plutôt que leur dernière exécution s’est terminée correctement (état Complete) :

    docker service ps reemo_db --format '{{.CurrentState}} {{.Error}}' | head -1
    

  • <INSTANCE_NAME>_mysqlbackup : ancien système de sauvegarde, remplacé par <INSTANCE_NAME>_backup. Il n’est pas à superviser.

• Mises à jour bloquées : un état paused ou rollback_completed signale un déploiement en échec :

  docker service inspect reemo_api --format '{{json .UpdateStatus}}'
  

Les conteneurs Reemo embarquent un healthcheck Docker (port d’écoute interne). Un conteneur unhealthy est redémarré automatiquement par Swarm. Des redémarrages répétés restent à surveiller :

docker ps --filter health=unhealthy
docker service ps reemo_api --no-trunc   # historique des tâches et des erreurs

Journaux

Tous les services journalisent en syslog (unixgram:///dev/log) avec un tag <INSTANCE_NAME>_<service> (ex. reemo_api, reemo_traefik, reemo_turn1). Vous pouvez :

• centraliser ces journaux (rsyslog, ELK, Graylog…) ;

• ou activer l’envoi vers Datadog avec DATADOG_ENABLED=true.

Traefik

Traefik est le point d’entrée HTTPS sur tous les profils sauf le provisionnement.

• Service traefik : réplicas x/x (un par manager).

• Ports d’écoute sur l’hôte (mode: host) : vérification TCP depuis l’extérieur.

• Métriques Prometheus (optionnel, profils infra_manager / portal_manager) : TRAEFIK_PROMETHEUS_ENABLE=true expose /metrics sur TRAEFIK_PROMETHEUS_PORT (443 par défaut). Restreignez l’accès avec TRAEFIK_PROMETHEUS_RESTRICT_IP.

  curl -s https://portail.example.com/metrics | head
  

Certificats HTTPS d’entrée

Chaque URL publique doit faire l’objet d’une sonde qui vérifie :

• la date d’expiration (alerte conseillée à 30 jours, critique à 7 jours) ;

• la chaîne de certification complète et valide ;

• la correspondance du nom (CN/SAN) avec l’URL.

Exemple de contrôle :

echo | openssl s_client -connect portail.example.com:443 \
     -servername portail.example.com 2>/dev/null \
  | openssl x509 -noout -subject -enddate

# ou avec le plugin Nagios standard
check_http -H portail.example.com -S --sni -C 30,7

Points d’entrée à surveiller selon les options :

Point d’entrée	Port par défaut	Condition
Portail (PORTAL_URL)	443 (TRAEFIK_SSL_PORT)	Toujours (infra_manager / portal_manager)
Signal (SIGNAL_URL)	8443 (TRAEFIK_SSL_SIGNALPORT)	Toujours. Peut être partagé avec le portail si TRAEFIK_SSL_SIGNALPORT = TRAEFIK_SSL_PORT.
Portail d’administration (PORTALADMIN_URL)	443, ou PORTALADMIN_URL_PORT	PORTALADMIN_URL renseigné
Workstation	8445 (WORKSTATION_INIT_PORTALPORT)	WORKSTATION_ENABLED=true
Appliance portal	8444 (APPLIANCE_INIT_PORTALPORT)	APPLIANCE_ENABLED=true
Credential portal	8446 (CREDENTIAL_PORTAL_PORT)	CREDENTIAL_ENABLED=true
Wake-on-LAN API (WOLAPI_URL)	443	WOLAPI_ENABLE=true
API interne (API_INTERNAL_URL)	443	API_INTERNAL_ENABLED=true (mTLS)
API (profil api_manager)	443	Architecture séparée (mTLS, voir plus bas)
Relay WebSocket	443 (RELAYWS_TRAEFIK_SSL_PORT)	Profil relayws_manager

Note

Les ports Workstation, Appliance portal et Credential portal sont routés en TCP passthrough (HostSNI(`*`)). Le certificat présenté est celui du service lui-même et non celui de traefik. Surveillez-le de la même manière.

Note

Si vous utilisez Let’s Encrypt (résolveur ACME de traefik), le renouvellement est automatique. La sonde d’expiration reste indispensable pour détecter un renouvellement en échec (port 443 filtré, DNS modifié…).

Portail et portail d’administration

Healthcheck du portail

Quand HEALTHCHECK_ENABLE=true, le portail expose la route /api/healthcheck. Elle renvoie au format JSON l’état global de la plateforme : API, base de données, provision-api, provision-relay-api, fournisseurs de conteneurs, relais WebSocket et signal. L’accès est restreint aux adresses de HEALTHCHECK_RESTRICT_IP : ajoutez-y l’IP de votre serveur de supervision.

curl -fsS https://portail.example.com/api/healthcheck | jq .

Sonde : code HTTP 200, champ status global à OK et aucun sous-service dans un autre état. Le script Nagios reemo_healthcheck réalise ce contrôle. Les mêmes informations sont disponibles au format Prometheus sur la route /api/healthcheck/prometheus.

Voir aussi

Santé et monitoring — Activation de la route, format de la réponse JSON et script Nagios reemo_healthcheck.

Astuce

Si PORTAL_URL_RESTRICT_IP restreint l’accès au portail, la route de healthcheck garde sa propre liste d’autorisation (HEALTHCHECK_RESTRICT_IP).

Healthcheck du portail d’administration

Quand PORTALADMIN_URL est renseigné et HEALTHCHECK_PORTALADMIN_ENABLE=true :

curl -fsS https://admin.example.com/api/healthcheck
# si un port dédié est configuré
curl -fsS https://admin.example.com:${PORTALADMIN_URL_PORT}/api/healthcheck

L’accès est restreint par HEALTHCHECK_PORTALADMIN_RESTRICT_IP.

Signal

Signal est un service WebSocket. Une requête HTTPS classique (sans demande de passage en WebSocket) reçoit un code HTTP 426 avec le message Upgrade Required : cette réponse indique que le service fonctionne. Le contrôle passe par traefik, sur le port signal (8443 par défaut) :

curl -sS -w '\nHTTP %{http_code}\n' https://signal.example.com:8443/
# attendu :
# Upgrade Required
# HTTP 426

Sonde : code HTTP 426 et présence du texte Upgrade Required dans la réponse. Contrôler le texte permet de vérifier que la réponse vient bien de signal, et pas d’une page d’erreur ou de maintenance. En cas de signal multiple (plusieurs serveurs SIGNAL_URL_TRAEFIK), surveillez chaque URL.

API

Architecture tout-en-un (infra_manager)

L’API n’est pas exposée par traefik (traefik.enable=false). Le portail l’appelle directement sur le réseau Swarm interne (https://reemo_api:8040). La supervision repose alors sur :

• l’état du service reemo_api (réplicas x/x, conteneurs healthy) ;

• le healthcheck du portail, qui échoue si le portail est inutilisable.

Architecture séparée (api_manager + portal_manager)

Dans ce mode, l’API tourne sur un cluster distinct. Le portail y accède via un proxy haproxy nommé reemo_api (déployé sur portal_manager). Ce proxy envoie les requêtes vers les adresses API_IP, port 443 (PORTAL_HA_PORT).

Le traefik de l”api_manager exige un certificat client signé par la PKI interne (mTLS, RequireAndVerifyClientCert). Le serveur de supervision n’a pas de certificat de la PKI interne : il ne peut donc pas interroger l’API directement, et ce n’est pas nécessaire.

À superviser :

1. Healthcheck du portail : c’est le contrôle fonctionnel de l’API. La requête /api/healthcheck traverse toute la chaîne portail → proxy reemo_api → traefik de l’API (mTLS) → API. Le JSON renvoyé contient le statut de l’API (services.api.status) et de ses dépendances (base de données, provision-api, provision-relay-api). Voir Healthcheck du portail.

2. Port 443 ouvert sur chaque ``API_IP`` et mTLS exigé : sans certificat client, la connexion TLS doit être refusée par l’API. Si elle aboutit à une réponse HTTP, l’API est exposée sans authentification mutuelle et une alerte doit être levée. Voir la sonde check_reemo_api_port.

   curl -sk -o /dev/null https://<API_IP>/
   # attendu : echec TLS du type
   # "tlsv13 alert certificate required" ou "alert bad certificate"
   

3. Certificat serveur de l’API : la date d’expiration se lit sans certificat client (sonde check_reemo_cert avec VERIF_CHAINE=0, la CA interne n’étant pas connue du serveur de supervision).

4. Proxy haproxy côté portail : service reemo_api sur portal_manager (réplicas x/x), via check_reemo_swarm_services.

5. Services de l”``api_manager`` : reemo_api, reemo_proapi, reemo_prorelayapi, reemo_logapi, reemo_credentialapi, les crons, etc. Surveillez-les via check_reemo_swarm_services (NRPE) sur ce cluster.

Note

Le flux portail → API (port 443 vers chaque API_IP) doit être ouvert depuis les machines portal_manager. La sonde de port, lancée depuis le serveur de supervision, ne teste pas ce flux précis. En cas d’alerte sur le healthcheck du portail, testez-le depuis une machine portail (voir Alerte : API (architecture séparée)).

Workstation

Condition : WORKSTATION_ENABLED=true. Le service Workstation tourne sur le profil portail (infra_manager ou portal_manager).

• Point d’entrée public : port 8445 (WORKSTATION_INIT_PORTALPORT), en TCP passthrough vers le service reemo_workstation.

  • vérification TCP et TLS, avec l’expiration du certificat Workstation ;

    echo | openssl s_client -connect portail.example.com:8445 2>/dev/null \
      | openssl x509 -noout -subject -enddate
    

• Service : reemo_workstation, réplicas x/x et conteneurs healthy.

• Dépendance vers l’API :

  • en tout-en-un, Workstation appelle https://reemo_api:8040 sur le réseau interne ;

  • en architecture séparée, Workstation appelle l’API via le proxy reemo_api du portail, puis API_IP:443 en mTLS. Les contrôles de Architecture séparée (api_manager + portal_manager) couvrent donc aussi Workstation. Si WORKSTATION_API_URL est personnalisé, supervisez cette URL.

• CA Workstation : si la CA Workstation est générée par le rôle (WORKSTATION_INITCA_ENABLED=true), surveillez l’expiration de son certificat et des certificats qu’elle émet.

Appliances

Condition : APPLIANCE_ENABLED=true.

Les appliances se connectent à la plateforme via l”appliance portal (APPLIANCE_INIT_PORTALURL, soit PORTAL_URL:8444 par défaut). Deux services sont déployés :

Service	Profil	Exposition
reemo_applianceportal	infra_manager / portal_manager	Port public 8444 (APPLIANCE_INIT_PORTALPORT), en TCP passthrough via traefik vers le port 8443 du service.
reemo_applianceapi	infra_manager / api_manager	Non exposé (réseau Swarm interne, port 8160).

À superviser :

• Port 8444 ouvert sur les IP publiques du portail :

  check_tcp -H portail.example.com -p 8444 -w 2 -c 5
  

• Certificat de l’appliance portal : en passthrough, le certificat présenté est celui du service, émis par la PKI interne. Contrôlez seulement son expiration (VERIF_CHAINE=0) :

  check_reemo_cert portail.example.com 8444 portail.example.com 30 7 0
  

• Services reemo_applianceportal (cluster portail) et reemo_applianceapi (cluster API) : réplicas x/x, via check_reemo_swarm_services.

• Flux réseau : le port 8444 doit être joignable depuis les sites où sont installées les appliances, pas seulement depuis le serveur de supervision.

Credential portal

Condition : CREDENTIAL_ENABLED=true et CREDENTIALPORTAL_ENABLED=true.

Service	Profil	Exposition
reemo_credentialportal	Portail (traefik infra_manager / portal_manager)	Port public 8446 (CREDENTIAL_PORTAL_PORT), en TCP passthrough via traefik vers le port 8443 du service.
reemo_credentialapi	infra_manager / api_manager	Non exposé (réseau Swarm interne, port 8190).
reemo_vault / reemo_vault<N>	infra_manager / api_manager	Non exposé. Voir Vault.

À superviser :

• Port 8446 ouvert :

  check_tcp -H portail.example.com -p 8446 -w 2 -c 5
  

• Certificat du credential portal (passthrough, PKI interne) : contrôlez seulement son expiration :

  check_reemo_cert portail.example.com 8446 portail.example.com 30 7 0
  

• Restriction d’IP : si CREDENTIAL_PORTAL_RESTRICT_IP est renseigné, traefik coupe la connexion TCP pour toute IP non autorisée. Ajoutez l’IP du serveur de supervision à cette liste, sinon les deux sondes ci-dessus échouent en permanence :

  CREDENTIAL_PORTAL_RESTRICT_IP:
    - name: supervision
      ip: 192.0.2.50
    - name: siteA
      ip: 198.51.100.0/24
  

• Services reemo_credentialportal et reemo_credentialapi : réplicas x/x.

• Vault déverrouillé : reemo_credentialapi ne fonctionne pas tant que Vault est sealed. La sonde check_reemo_vault est indispensable dès que le credential portal est activé.

TURN

Condition : TURN_ENABLED=true.

Le serveur TURN tourne :

• sur le profil portail (infra_manager / portal_manager) en déploiement classique ;

• sur des machines dédiées turn_manager lorsque ce groupe existe dans l’inventaire.

Contrôles :

• Services reemo_turn1 (et reemo_turn2 si TURN2_NODE est renseigné) : réplicas 1/1.

• Ports publics : TURN_PORT (58200 par défaut), en TCP et UDP, sur TURN1_IP / TURN2_IP. Ces ports sont publiés en mode: host : contrôlez chaque IP individuellement, depuis l’extérieur.

  nc -vz  <TURN1_IP> 58200     # TCP
  nc -vzu <TURN1_IP> 58200     # UDP (indicatif, UDP sans réponse garantie)
  

• Test fonctionnel (recommandé) : allocation réelle avec turnutils_uclient (paquet coturn).

  • En mode TURN_AUTH_MODE=static : utilisateur TURN_USERNAME / mot de passe TURN_PASSWORD.

  • En mode TURN_AUTH_MODE=secret : identifiants éphémères calculés à partir de TURN_SECRET.

  # mode secret : identifiant = timestamp d'expiration, mot de passe = HMAC-SHA1 base64
  u=$(( $(date +%s) + 3600 )):supervision
  p=$(printf '%s' "$u" | openssl dgst -sha1 -hmac "$TURN_SECRET" -binary | base64)
  turnutils_uclient -y -u "$u" -w "$p" -p 58200 <TURN1_IP>
  

• Cohérence du secret (turn_manager) : le secret TURN est déclaré dans l’inventaire et doit être identique côté turn_manager et côté api_manager / infra_manager. Un écart se traduit par des échecs d’authentification TURN, que le test fonctionnel ci-dessus détecte.

• Profil ``turn_manager`` : traefik est aussi déployé (ports 80/443, TURN_TRAEFIK_PORT / TURN_TRAEFIK_SSL_PORT). Surveillez le service traefik et, le cas échéant, le certificat exposé.

Note

Le trafic média des sessions relayées transite par le serveur TURN. Surveillez aussi la bande passante réseau des machines TURN.

Relay WebSocket

Condition : profil relayws_manager (et RELAYS_IP renseigné côté API).

• Traefik : ports 80/443 (RELAYWS_TRAEFIK_PORT / RELAYWS_TRAEFIK_SSL_PORT), avec l’expiration du certificat public.

• Nginx (API Docker exposée à prorelayapi) : port 8443 (RELAYWS_NGINX_PORT), avec certificat client obligatoire (DN CN=reemo_prorelayapi). À vérifier :

  • la joignabilité TCP depuis les machines api_manager / infra_manager ;

  • l’état du service : systemctl is-active nginx.

• Cluster Swarm : docker node ls / docker service ls sur le relayws. Les conteneurs relais sont créés à la demande par prorelayapi.

• Côté API : service reemo_prorelayapi (réplicas x/x) et proxy reemo_relayws s’il est déployé.

• Healthcheck du portail : les entrées provision-relay-api et ws-relays du JSON indiquent si l’API joint bien les relais.

Provisionnement

Condition : profils provision_manager / provisionN_manager.

• Nginx : port 8443 (PROVISION_NGINX_PORT), avec certificat client obligatoire.

  • joignabilité TCP depuis les machines API ;

  • systemctl is-active nginx ;

  • expiration du certificat serveur nginx.

• Cluster Swarm : nœuds Ready / Active (managers et workers).

• Healthcheck du portail : les entrées provision-api et container-providers du JSON indiquent si l’API joint bien les fournisseurs de conteneurs.

• Capacité : CPU, RAM et disque des workers, qui hébergent les conteneurs utilisateurs. Surveillez aussi l’espace pris par les images (docker system df).

Base de données

MariaDB

Profils infra_manager / api_manager avec DB_DIALECT=mysql et base locale.

• Service reemo_mysql (MariaDB) : réplicas 1/1, healthy.

• Espace disque de /opt/<INSTANCE_NAME>/db.

• Ping SQL (depuis le conteneur) :

  docker exec $(docker ps -q -f name=reemo_mysql) \
    sh -c 'MYSQL_PWD=$(cat $MYSQL_ROOT_PASSWORD_FILE) mysqladmin ping -u root'
  

• Si DB_SSL_REQUIRE=true : expiration du certificat de la base.

NDB Cluster

Avec DB_DIALECT=NDBCLUSTER :

• tous les nœuds ndbd, mgmd et mysqld connectés :

  docker exec $(docker ps -q -f name=reemo_mysql-mgmd | head -1) ndb_mgm -e show
  

• mémoire de données et d’index (ndb_mgm -e "all report memory"), avec une alerte au-delà de 80 % ;

• option NDBMONITOR_ENABLED=true : service de supervision NDB dédié (reemo_ndbmonitor).

Vault

Condition : CREDENTIAL_ENABLED=true et VAULT_ENABLED=true.

• Services reemo_vault (frontal) et reemo_vault<N> (réplicas) : réplicas 1/1 chacun. Vault est fourni par OpenBao (commande bao).

• État *sealed* : après un redémarrage, Vault démarre verrouillé. En mode VAULT_UNSEAL_MODE=manual (par défaut), une intervention est nécessaire. Une alerte sur sealed=true est indispensable :

  # à exécuter pour chaque réplica reemo_vault<N>
  docker exec <conteneur_vault> bao status -format=json | grep '"sealed"'
  

• En mode raft (plusieurs réplicas) : vérifiez que tous les membres sont déverrouillés et que le cluster a un leader.

• Services dépendants : reemo_credentialapi et, si activé, reemo_credentialportal.

Sauvegardes

Condition : BACKUP_ENABLED=true.

• Fraîcheur : la sauvegarde la plus récente doit dater de moins de 24 h (alerte au-delà de 25 h, critique au-delà de 48 h).

• Taille : alerte sur une sauvegarde anormalement petite par rapport aux précédentes.

• Intégrité : un contrôle périodique peut être lancé avec --extra-vars "VERIFYBACKUP=true". Supervisez son code retour.

• Externalisation : vérifiez que la copie vers le stockage distant a réussi.

• Restauration : testez régulièrement une restauration sur un environnement de recette.

Certificats de la PKI interne

Les échanges internes (portail → API, traefik → signal, traefik → relayws, prorelayapi → relayws, base de données en TLS…) sont protégés par des certificats émis par la PKI interne (INITCA_ENABLE). Ils sont stockés sous forme de secrets Docker (reemo_*_ssl_cert).

• Surveillez la date d’expiration de la CA et de chaque certificat de service. Un certificat interne expiré provoque une coupure de service, sans erreur visible côté navigateur.

• Méthode conseillée : contrôler les fichiers de la PKI (répertoire LOCAL_PATH ou dépôt git de la PKI) depuis le poste d’administration :

  for c in pki/*.crt; do
    printf '%s ' "$c"; openssl x509 -in "$c" -noout -enddate
  done
  

• Le certificat par défaut de traefik (/opt/traefik/config/default.crt) est auto-signé et valable 824 jours. Il n’est utilisé que pour les requêtes sans SNI correspondant.

Récapitulatif des flux à contrôler

Source	Destination	Port	Condition
Utilisateurs / supervision	Portail	443 (+ 80 pour la redirection)	Toujours
Utilisateurs / supervision	Signal	8443	Toujours
Utilisateurs / supervision	Workstation	8445	WORKSTATION_ENABLED
Appliances (sites clients) / supervision	Appliance portal	8444	APPLIANCE_ENABLED
Utilisateurs autorisés / supervision	Credential portal	8446	CREDENTIALPORTAL_ENABLED
Utilisateurs / supervision	TURN	58200 TCP/UDP	TURN_ENABLED
portal_manager	api_manager (API_IP)	443 (mTLS)	Architecture séparée
api_manager / infra_manager	relayws_manager	8443 (mTLS)	Relay WebSocket
api_manager / infra_manager	provisionN_manager	8443 (mTLS)	Provisionnement
Nœuds d’un même cluster	Nœuds d’un même cluster	2377/tcp, 7946/tcp+udp, 4789/udp (ou SWARM_DATA_PATH_PORT)	Clusters multi-nœuds