🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page s'adresse à quiconque veut savoir si Hydranos est en bonne santé et ce qu'il raconte. Elle couvre les points de santé et l'écran de démarrage, la page Prometheus, les sorties de journal, les onglets Journaux (Logs), Vue d'ensemble (Overview) et Performances (Benchmark), le test de ligne, la santé des trackers, le rapport d'anomalies et les diagnostics mémoire sous Linux. Pour chacun, elle indique aussi ce qui n'est pas mesuré en 4.4, pour que vous sachiez où votre supervision a des angles morts.

Le démarrage, l'arrêt, les sauvegardes et les mises à jour sont sur Exploiter Hydranos.

flowchart LR
    E["moteurs race, hoard, supplémentaires"] --> T["événements tracing"]
    W["workers, API, annonceur"] --> T
    T --> C["console : docker logs ou journald"]
    T --> F["hydranos.log à côté de default.toml<br/>tourné à 128 Mio, 4 anciens fichiers gardés"]
    T --> R["anneau en mémoire, 2000 lignes"]
    R --> LT["onglet Journaux, GET /api/logs<br/>et /api/logs/stream"]
    S["échantillonneur bench toutes les 5 s<br/>chaque moteur"] --> B["bench.db dans data_dir"]
    I["test de ligne iperf3<br/>Lancer maintenant ou interval_secs"] --> B
    B --> BT["onglet Performances et carte Records"]
    E -->|"compteurs déjà tenus"| M["GET /metrics<br/>débits, pairs, annonces, limites, mémoire"]
    M --> P["Prometheus"]
    E --> H["GET /health<br/>store et listeners"]
    E --> HS["examen de santé toutes les 5 min"]
    HS --> A["GET /api/health/anomalies<br/>et l'outil MCP health"]

{"checks":{"engines":[{"blocked":null,"held":false,"id":"race","listening":true,"online":true,"torrents":42}],"store":"ok"},"problems":[],"status":"healthy","uptime":86400.0,"version":"4.x.y"}

checks.store peut aussi valoir busy (un autre lecteur tient le store à ce moment) : ce n'est pas un problème. Un moteur tenu hors du réseau exprès (HYDRANOS_ENGINE_NET=0) n'est pas censé écouter. Un moteur bloqué par le kill switch rend l'instance degraded, jamais unhealthy, même quand tous les moteurs sont bloqués : un redémarrage ne change rien tant que la configuration ne change pas (voir WireGuard géré).

En mode de secours, /health répond le texte brut ok, pas du JSON (HTTP 200). Le mode de secours est décrit sur Exploiter Hydranos.

Le port 8199 (api_port) s'ouvre dans la première seconde, avant le chargement du catalogue ; la ligne de journal est hydra API listening (starting) (avec addr=). Un port déjà pris échoue donc tout de suite. Jusqu'à la fin du chargement, seules ces routes répondent :

• / et /static/* : l'interface web affiche un écran de démarrage (HYDRANOS, une ligne de phase telle que Restauration de l'état… (Restoring state…), Connexion au réseau… (Connecting to the network…), Ouverture de la base… (Opening the database…) ou Démarrage… (Starting…), une barre et <restored> / <total> torrents), interroge /api/startup toutes les 500 ms et laisse place en fondu à l'interface normale quand ready passe à true ;
• /health (starting), /metrics (jeu réduit), /api/startup et GET /api/setup.

Tout le reste — le reste de l'API, la connexion, le shim qBittorrent /api/v2/*, /mcp — répond 503 avec Retry-After: 5 et {"error":"Hydranos is starting (<phase>): <restored> of <total> torrents restored","startup":{…}}. La création du premier compte (POST /api/setup) est refusée aussi : le routeur de démarrage n'achemine que GET /api/setup jusqu'à la fin du chargement. Quand le chargement se termine, le journal indique hydra API ready.

phase passe par loading → connecting → opening_store → starting_workers → ready (ou rescue). total ne compte que les moteurs qui ont commencé à lire leurs enregistrements, donc la barre peut reculer une fois par moteur. Une fois prête, /api/startup continue de répondre ready: true, phase: "ready" et les torrents désormais chargés, par moteur.

Une sonde qui veut « prêt » lit le mot status de /health ou ready de /api/startup. Une sonde de vie qui ne doit pas tuer un démarrage long accepte starting.

L'image n'a pas de HEALTHCHECK ni de curl ; celui-ci utilise bash. Faites correspondre le mot d'état entier : grep -q healthy correspond aussi à "unhealthy", il laisserait donc passer un 503.

    healthcheck:
      test:
        - CMD
        - bash
        - -c
        - exec 3<>/dev/tcp/127.0.0.1/8199 && printf 'GET /health HTTP/1.0\r\n\r\n' >&3 && grep -qE '"status":"(healthy|degraded|starting)"' <&3
      interval: 60s
      timeout: 10s
      retries: 3

Il passe sur starting, healthy et degraded, et échoue sur unhealthy, le mode de secours (ok) et l'absence de réponse. Retirez degraded pour signaler un listener manquant, un blocage par le kill switch ou une retenue par start_paused. Docker marque seulement le conteneur comme non sain ; il ne le redémarre pas. Voir aussi Docker.

Vérification rapide depuis un shell :

curl -s http://localhost:8199/health | jq '{status, problems}'

GET /metrics ne demande pas de clé API et renvoie du texte Prometheus (text/plain; version=0.0.4, avec # HELP et # TYPE) : 32 familles, par moteur (moteurs supplémentaires compris) : débits, octets, pairs, torrents par état, annonces (par hôte de tracker aussi), plafonds de débit, choker, état du listener et de start_paused, pièces en vol, et mémoire jemalloc (Linux/Unix). Une collecte ne parcourt jamais le catalogue. Pendant le démarrage d'Hydranos, la page sert un jeu réduit (hydra_up, hydra_uptime_seconds, hydra_starting, hydra_startup_restored, hydra_startup_records).

La table complète des métriques, une configuration de collecte et des règles d'alerte prêtes à l'emploi sont sur Métriques Prometheus.

La page est publique : quiconque peut joindre le port 8199 peut la lire, y compris les noms d'hôte des trackers (label tracker) et vos volumes. Voir Sécurité & accès.

Tout ce qu'affichent les onglets Vue d'ensemble, Performances et Trackers vient de routes JSON qui demandent la clé API. Leurs champs sont listés sous Supervision sur API REST :

Sans Prometheus, un petit contrôle depuis cron suffit. Celui-ci sort avec un code non nul quand quelque chose mérite un coup d'œil ; branchez-le sur ce qui vous notifie (mail de cron, service de type healthchecks, votre propre script) :

#!/usr/bin/env bash
# hydranos-check.sh: run every 5 minutes from cron
HY=http://localhost:8199
KEY=YOUR_API_KEY

h=$(curl -s --max-time 10 "$HY/health") || { echo "Hydranos does not answer"; exit 2; }
st=$(jq -r '.status' <<<"$h" 2>/dev/null)
case "$st" in
  healthy|starting) ;;
  degraded) jq -r '.problems[].detail' <<<"$h"; exit 1 ;;
  *) echo "health: ${st:-not JSON (rescue mode?)}"; jq -r '.problems[]?.detail' <<<"$h" 2>/dev/null; exit 2 ;;
esac

red=$(curl -sf --max-time 60 -H "X-Api-Key: $KEY" "$HY/api/announce/health" | jq '.badges.trackers_red')
[ "${red:-0}" -gt 0 ] && { echo "$red tracker(s) red: passkey refused or missing from a peer list"; exit 1; }
exit 0

/api/announce/health parcourt chaque hôte de tracker de chaque moteur à partir des caches d'annonce en mémoire ; son coût croît avec le nombre de trackers, pas de torrents. Sous Windows, lancez les mêmes requêtes avec curl.exe depuis une tâche planifiée, ou Invoke-RestMethod dans PowerShell.

Chaque événement de journal part à trois endroits à la fois, tous filtrés par le même niveau :

Si le fichier ne peut pas être ouvert, Hydranos affiche hydranos: no log file at <path> (<error>); console only et continue de tourner.

Les horodatages de /api/logs sont en UTC au format RFC 3339, terminés par Z. L'onglet Journaux affiche la même heure UTC sans le T ni le Z et tronquée à la milliseconde, donc rien à l'écran n'indique que c'est de l'UTC : ce n'est pas votre heure locale.

Hydranos fait tourner hydranos.log lui-même, sur toutes les plateformes. Quand la ligne suivante ferait dépasser 128 Mio au fichier, il renomme hydranos.log en hydranos.log.1 (les fichiers plus anciens montent en .2, .3, .4 ; l'ancien .4 est supprimé) et commence un nouveau hydranos.log. Il existe au plus cinq fichiers, environ 640 Mio au total. Les fichiers tournés ne sont pas compressés. Le décompte de taille reprend depuis le fichier existant au démarrage, donc un redémarrage ne le remet pas à zéro.

Il n'y a rien à configurer et aucune règle logrotate n'est nécessaire. Chaque connexion entrante d'un pair écrit encore une ligne INFO ([peer] incoming … from …), donc sur une instance chargée les 640 Mio couvrent moins de temps que vous ne le pensez ; pour garder plus d'historique, baissez le niveau avec RUST_LOG (ci-dessous) ou collectez la console avec votre système de journaux.

Si HYDRANOS_LOG_STDOUT est définie avec n'importe quelle valeur (y compris 0, false ou une chaîne vide), aucun fichier n'est écrit et seuls la console et l'anneau restent. La sortie console est la même que la variable soit définie ou non.

Sous Docker, c'est généralement ce que vous voulez : docker logs conserve déjà la console, plafonnée par le bloc logging: du compose. Sans console (un lancement par double-clic sous Windows, par exemple), le fichier est votre seule trace d'un démarrage raté, alors gardez-le dans ce cas.

RUST_LOG définit le niveau des trois sorties. Quand elle n'est pas définie ou ne peut pas être analysée, le niveau est info. Elle utilise la syntaxe de filtre standard de tracing : un niveau par défaut, puis des paires target=level.

Docker : ajoutez RUST_LOG: "info,typhon_engine::peer=warn" sous environment:. systemd : Environment=RUST_LOG=info,typhon_engine::peer=warn dans une surcharge (systemctl edit hydranos). Où chaque variable est lue : Config : environnement, CLI & signaux.

Il n'y a pas de journal d'accès HTTP : les requêtes à l'API ne sont pas journalisées.

L'onglet Journaux (Logs) affiche le tampon circulaire : les 2000 dernières lignes depuis le démarrage du processus, filtrées par le serveur. Chaque ligne affiche l'heure (UTC, voir plus haut), le niveau, le module (la zone du code, sans le préfixe hydranos::, par exemple announce::runner) et le message. Les champs structurés affichés dans la console et le fichier (par exemple torrents= ou addr=) sont ajoutés au message sous la forme key=value.

2000 lignes peuvent ne couvrir que quelques minutes sur une instance chargée : pour les lignes plus anciennes, lisez hydranos.log (et ses fichiers tournés) ou la console.

Les mêmes données via l'API (clé API requise) :

curl -s -H "X-Api-Key: YOUR_API_KEY" "http://localhost:8199/api/logs?level=warn&since=1h" \
  | jq -r '.entries[] | "\(.ts) \(.level) \(.module) \(.msg)"'

GET /api/logs renvoie {"entries":[{"ts","source","level","module","msg","seq"}, …],"last_seq":N,"modules":[…]}, du plus ancien au plus récent ; source vaut toujours rust. Paramètres facultatifs : level (minimum : trace, debug, info, warn, error), module (ou source ; sous-chaîne, source=rust ignoré), q (ou contains ; texte insensible à la casse du message et des champs), since (90s, 5m, 1h, 24h, 2d ou secondes Unix), after (un seq) et limit (les N correspondances les plus récentes). Une valeur qu'il ne sait pas lire (since=1week, level=loud) répond 400 {"error":…} au lieu d'être ignorée en silence.

GET /api/logs/stream est un flux server-sent events (clé API dans l'en-tête ou ?apikey=) avec des événements nommés log, chacun portant une entrée et son seq comme identifiant d'événement. Il accepte les mêmes filtres sauf since, commence après after= (ou le Last-Event-ID du navigateur lors d'une reconnexion, sinon à partir de maintenant), et se termine de lui-même quand Hydranos s'arrête.

Les cartes Moteur Race (Race engine) / Moteur Hoard (Hoard engine) (sauf le Ratio de session (Session ratio) de la carte Race, calculé sur les octets de session de tous les moteurs) affichent les moteurs d'identifiant race et hoard. Tout autre moteur (par exemple vpn1) a sa propre carte dans la Vue d'ensemble, ses propres cartes en direct et une courbe d'envoi dans l'onglet Performances, et compte dans les Records (sauf Pic de sources actives (Peak live seeds)), les totaux de l'en-tête, la carte Stockage (Storage), la santé des trackers et /metrics.

Ce qui ne couvre encore que race et hoard : les cartes d'annonce réservées au hoard, Pic de sources actives, la comparaison A / B (ci-dessous), et la chronologie race et ses instantanés (moteur race seulement). Voir Moteurs : race & hoard.

• Envoi total (All-time upload) : le chiffre UL total en Pio, le ratio cumulé, le total téléchargé, le nombre de torrents (tous les moteurs) et la progression vers le prochain Pio entier. Ses lignes de jalons viennent de bench.db.
• Cartes Moteur Race / Moteur Hoard : Torrents, Avec des pairs (With peers), Envoi (Upload), Téléchargement (Download), Pairs (Peers), En partage (Seeding) (la taille seedée de ce moteur) et Ratio de session (depuis le démarrage du processus ; sur la carte Race, l'envoi de session de tous les moteurs ÷ la réception de session de tous les moteurs).
• Cartes Engine {id}, une par moteur supplémentaire (rafraîchies au plus toutes les 3 s) : l'étiquette est le rôle du moteur, ou <role> · n'écoute pas (not listening) ; lignes Torrents, Avec des pairs, Envoi, Téléchargement, Pairs, En partage (- avant la première passe des trackers) et Ratio de session (celui de ce moteur seul).
• Stockage : compare ce que les trackers créditent avec l'espace que cela occupe.

Le scanner de liens attend environ 3 minutes après le démarrage, puis parcourt le catalogue par lots. Un premier comptage d'une grosse bibliothèque prend longtemps ; tant qu'il n'est pas arrivé, les lignes affichent -.

• Records : pics de tous les temps calculés depuis bench.db : Pic d'envoi (Peak upload), Pic de réception (Peak download), Pic de pairs dans l'essaim (Peak swarm peers) (tous les moteurs), Meilleur jour d'envoi (Best upload day), Pic de sources actives (race + hoard seulement) et Meilleur test de ligne (Best line test) (le meilleur envoi mesuré par un test de ligne, en Gbps). Le serveur les recalcule au plus toutes les 30 minutes. Tant que rien n'est enregistré, la carte affiche Aucun record pour l'instant (No records yet).

L'onglet Performances (Benchmark) lit bench.db dans le dossier de données. Une ligne d'échantillon est écrite toutes les 5 s (avec une ligne de plus par moteur supplémentaire, dans sa propre table) ; les lignes par tracker toutes les 30 s. Les lignes de tracker de plus de 48 heures sont regroupées en tranches de 5 minutes. Les tables d'échantillons ne sont jamais purgées, donc bench.db grossit d'environ 17 000 lignes d'échantillon par jour (plus autant par moteur supplémentaire) tant qu'il existe. Si bench.db ne peut pas être ouvert, Hydranos journalise no bench database: … et l'onglet reste vide.

• Cartes en direct : Envoi Race (Upload Race), Réception Race (Download Race), Envoi Hoard (Upload Hoard), Pairs Race (Peers Race) (pairs connectés), Attente E/S (IOWait), Taux de succès ARC (ARC Hit Rate), Échecs ARC/s (ARC Miss/s), Taille ARC (ARC Size) ; puis, par moteur supplémentaire, Upload {id}, Download {id} et Pairs {id} (Peers {id}) (la rangée est masquée quand il n'y en a pas).
• Cartes d'annonce pour le moteur hoard seulement : Announces (par seconde sur 5 minutes, comparé à ce qu'exigent les intervalles), Late (échéance dépassée de plus de 5 s), In flight, Refused (429) (part des réponses 429 sur 10 s ; au-delà de 2 % l'annonceur ralentit). Fonctionnement de l'annonceur : Trackers & annonces. Pour les autres moteurs, utilisez hydra_announce_* sur Métriques Prometheus.
• Graphiques sur 15m, 1h, 6h, 24h, 7d ou 30d : Débit d'envoi (Upload Speed) (une courbe par moteur supplémentaire aussi), Total envoyé (Total Uploaded) (moteurs supplémentaires empilés sous Autres engines (Other engines)), En cours d'envoi (Currently Uploading), Announce Rate, Événements Race (Race Events), Attente E/S % (IOWait %), Échecs ARC / s (ARC Miss / sec).

Attente E/S a besoin de /proc sous Linux ; les chiffres ARC ont besoin de ZFS. Sans eux, ils affichent 0 : cela signifie « non mesuré », pas « aucune pression disque ». Sous Windows, aucun n'est mesuré.

▶ Lancer maintenant (▶ Run now) (POST /api/vpn-speedtest/run) lance iperf3 contre [vpn_speedtest] iperf3_server : l'envoi d'abord, puis la réception (-R), jamais les deux à la fois, duration_secs chacun. Le bouton affiche ⏳ En cours… (⏳ Running…) et la requête attend la fin (environ deux fois duration_secs). Le test sort par le même chemin que les moteurs : par le bind_interface du moteur dont le rôle est race (ou du premier moteur), tunnel WireGuard géré compris, avec --bind-dev (Linux) ; sans interface, par la route par défaut. Les torrents continuent de tourner ; leur débit est lu à mi-parcours de chaque sens et affiché à côté du résultat.

Le graphique Envoi / réception (Mbps), 7 derniers jours (Upload / Download (Mbps), last 7 days) montre l'historique, gardé dans bench.db (le record Meilleur test de ligne en vient). Erreurs : 400 iperf3_server not configured in [vpn_speedtest] (aussi quand enabled = false) ou the engines go out through a SOCKS5 proxy, which iperf3 cannot use ; 409 a speedtest is already running ; 502 pour un échec d'iperf3, nommé par sens : upload: … et/ou download: … joints par , (par exemple upload: cannot run iperf3: … ou download: iperf3 did not finish in 40s, la limite étant deux fois la durée du test + 20 s). Seule la sortie d'un moteur est mesurée.

iperf3 est fourni dans l'image Docker ; ailleurs, il doit être dans le PATH. Chaque test sature la ligne pendant environ deux fois duration_secs.

[vpn_speedtest]
enabled = true                      # absent = false
iperf3_server = "ping.online.net"   # absent = "" (aucun test)
# iperf3_port = 5201                # absent = 5201
# duration_secs = 10                # secondes par sens, 1-60 ; absent = 10
# interval_secs = 0                 # test automatique toutes les N s (jamais moins de 300) ; 0 ou absent = Lancer maintenant seulement

Les clés sont lues à chaque lancement, donc un changement fait dans Config s'applique au test suivant sans redémarrage. Avec interval_secs au-dessus de 0, le premier test automatique tourne un intervalle après le démarrage, et un échec journalise periodic speedtest: ….

Mise à jour : un fichier de configuration parti du default.toml de la 4.3 (ou repris de la 3.x) peut contenir interval_secs = 3600. En 4.3 la clé était ignorée ; depuis la 4.4 elle est lue, donc un tel fichier lance un test de ligne toutes les heures après la mise à jour. Mettez interval_secs = 0 (ou supprimez-la) pour garder Lancer maintenant seulement.

Comparaison A / B (A / B comparison) compare deux périodes contiguës autour d'un changement : remplissez Début de la période 1 (Start of period 1), Point médian (changement) (Middle point (change)), Fin de la période 2 (End of period 2), puis Comparer (Compare). Le tableau liste, par métrique échantillonnée, P1 moy (P1 avg), P1 max, P2 moy (P2 avg), P2 max et Δ moy (Δ avg) (relatif à P1, en vert ou en rouge selon le sens qui est meilleur), avec P1 : {p1} échantillons, P2 : {p2} échantillons (P1: {p1} samples, P2: {p2} samples). Les métriques sans nom convivial affichent leur nom de colonne (par exemple global_uploaded, open_fds). Aucune donnée sur cette plage. (No data for this range.) signifie qu'un des côtés n'a aucun échantillon.

GET /api/benchmark/compare?start=&mid=&end= (secondes Unix, start < mid < end) renvoie la même chose avec avg, max, p95 et count par côté et delta_avg_pct ; le p95 n'est pas affiché dans l'interface.

Bug connu en 4.4 : race_avg_share et hoard_session_uploaded figurent dans la comparaison mais l'échantillonneur ne les écrit jamais, donc ils valent toujours 0 et Δ 0 % — lisez les autres lignes. Les moteurs supplémentaires n'ont pas de ligne dans la comparaison : comparez leurs courbes sur le graphique Débit d'envoi, ou leurs séries /metrics.

Toutes les 5 s, pour chaque torrent du moteur d'identifiant race qui n'est pas encore complet, Hydranos enregistre un instantané avec ses dix pairs les plus rapides. La chronologie race les dessine ; GET /api/benchmark/race-snapshots/:info_hash les renvoie seuls (null quand il n'y en a pas). Ils sont supprimés avec les événements race du torrent quand il quitte le moteur. Les moteurs supplémentaires de rôle race n'ont pas d'instantanés.

Accepté mais ignoré en 4.4 : la section [bench] (enabled, retention_days, race_snapshot_retention_days, snapshot_interval_secs, prune_interval_mins, vacuum) ressemble à des réglages d'enregistrement et de rétention — le journal de démarrage avertit config: [bench] is ignored: bench recording and its retention are built in; none of these keys is read. Instead: nothing; delete the section. — pour récupérer de l'espace, arrêtez Hydranos et supprimez ou archivez bench.db ; il est recréé vide au démarrage suivant et vous perdez l'historique, les tests de ligne et les Records.

L'onglet Trackers affiche, par hôte de tracker, les erreurs d'annonce des 60 dernières minutes par classe et une sévérité rouge/orange ; le badge de l'onglet compte les trackers rouges et orange. La description complète se trouve sur Trackers & annonces.

Pour les scripts, les mêmes données sont disponibles avec la clé API :

curl -s -H "X-Api-Key: YOUR_API_KEY" http://localhost:8199/api/announce/health
curl -s -H "X-Api-Key: YOUR_API_KEY" "http://localhost:8199/api/announce/errors?host=tracker.example.org"

Les deux couvrent tous les moteurs ; un tracker en échec sur deux moteurs compte une seule fois dans le badge.

GET /api/health/anomalies (clé API requise ; c'est aussi l'outil MCP health) sert le dernier résultat d'une passe d'arrière-plan plus des compteurs en direct : l'appel lui-même ne parcourt jamais le catalogue. La passe tourne 2 minutes après le démarrage, puis toutes les 5 minutes, sur chaque moteur ; quand elle trouve quelque chose, elle journalise health scan found something (anomalies=). L'interface web n'appelle pas ce point d'accès.

Autres champs : scan (pending jusqu'à la première passe, puis done), generated_at, scan_duration_ms, scanned (par moteur, plus scanned_race / scanned_hoard), anomalies (jusqu'à 500 entrées {type, engine, info_hash, name, detail, wasted_bytes}, anomalies_truncated au-delà), wasted_bytes, efficiency (octets utiles ÷ octets téléchargés), redl_historical / redl_historical_bytes (plus de 1,2 × la taille et 50 Mio de plus), trackers ({host, severity, engines}), trackers_red, announces (late, held_engines), disks et engines (torrents et états par moteur).

disks a une ligne par système de fichiers contenant data_dir ou un chemin de sauvegarde vu à la dernière passe : path, free_bytes, total_bytes, free_pct, et low quand il reste moins de 5 Gio ou moins de 2 % de libre.

Sous Linux et les autres builds Unix, Hydranos utilise l'allocateur jemalloc et réagit à deux signaux. Aucun des deux n'existe sous Windows.

docker kill --signal=SIGUSR1 hydranos       # Docker
sudo systemctl kill -s SIGUSR2 hydranos     # systemd

La ligne jemalloc allocated=… resident=… toutes les 5 minutes, et hydra_memory_allocated_bytes / hydra_memory_resident_bytes sur /metrics, vous disent dans quel cas vous êtes : si resident suit allocated, la mémoire est réellement utilisée ; si resident est bien plus grand, SIGUSR2 en rendra la plus grande partie. L'image Docker paie en permanence un petit surcoût d'échantillonnage pour le profilage ; pour le désactiver, mettez MALLOC_CONF à une valeur vide dans le environment: de votre compose.

• Exploiter Hydranos : arrêt, redémarrage, mode de secours, sauvegardes, mises à jour.
• Trackers & annonces : l'onglet Trackers en détail.
• Dépannage : symptômes et solutions.
• Config : environnement, CLI & signaux : RUST_LOG, HYDRANOS_LOG_STDOUT, signaux.
• Docker : contrôle de santé et plafond des journaux dans compose.
• Métriques Prometheus : chaque famille de /metrics, configuration de collecte, règles d'alerte.