Monitoring du minage et alertes: comment détecter un downtime en quelques minutes, pas en une journée

Le downtime sur une ferme n'a presque jamais l'air dramatique. Les lumières ne s'éteignent pas, il n'y a pas de fumée. Simplement, à un moment donné, une partie des machines cesse de fournir des shares, et vous l'apprenez le matin, quand le paiement est inférieur à celui de la veille. À ce moment-là, l'argent est déjà perdu, et il n'y a aucun moyen de le récupérer: le réseau ne recalcule pas votre part rétroactivement.

Nous expliquons ci-dessous pourquoi le tableau de bord du pool convient mal comme système d'alerte, quelles métriques annoncent une panne à l'avance, et comment monter une alerte simple avec ce que vous avez déjà sous la main.

Combien coûte une heure de downtime

On calcule avec la formule que toute calculatrice de rentabilité utilise:

\`\`\`

BTC par jour = (hashrate × 86400) / (difficulté × 2^32) × 3.125

\`\`\`

Ici 86400 est le nombre de secondes dans une journée, 2^32 vient de la définition de la difficulté, et 3.125 BTC est la subvention de bloc actuelle (valeur de notre relevé du réseau au 08.09.2026).

En substituant une difficulté de 127,45 billions (mempool.space, 08.09.2026) et un taux de change de 78 349 dollars:

Le calcul est brut, avant commission du pool et électricité, et il ne prend pas en compte les frais de transaction (selon mempool.space, au 08.09.2026 ils ajoutaient 0,66% à la récompense sur une fenêtre de 4320 blocs, soit en ordre de grandeur presque rien).

Ensuite c'est de l'arithmétique simple. Une panne à une heure du matin, remarquée à treize heures. Douze heures, ferme de 10 PH/s: environ 193 dollars qui n'apparaîtront tout simplement pas dans le paiement. Une fois par mois une telle coïncidence, et sur un an cela vous coûte plus de deux mille dollars avec un équipement pourtant parfaitement fonctionnel.

Pourquoi le tableau de bord du pool ne remplace pas un monitoring

En bref: le pool n'affiche pas l'état de votre matériel, mais l'état du flux de shares qui lui est parvenu. Entre la coupure et le changement de statut sur le tableau de bord, il s'écoule des dizaines de minutes, parce que le pool doit distinguer une vraie panne d'une simple coupure de connexion. Chez AntPool c'est formalisé officiellement: un worker reçoit le statut Inactive après 20 minutes sans shares, et le statut Invalid seulement après 24 heures de silence (AntPool support, Worker Management).

Vingt minutes, c'est déjà 5,4 dollars à 10 PH/s, et c'est le meilleur des cas: le worker est tombé entièrement et le statut change effectivement. Si la machine fonctionne mais produit deux fois moins, le statut restera vert, et le pool ne vous dira rien.

Il y a aussi une seconde raison. Le hashrate sur le tableau de bord du pool n'est pas une mesure, mais une estimation basée sur le nombre de shares acceptés sur une fenêtre de moyenne. Chaque pool a sa propre fenêtre, et elle n'est pas toujours indiquée dans la documentation. Plus la fenêtre est courte, plus le graphique est nerveux; plus elle est longue, plus la réaction à une vraie baisse est tardive.

Les valeurs de délai et de seuils des autres pools sont à vérifier dans leur propre documentation: nous n'avons trouvé des chiffres officiellement confirmés que chez AntPool, et on ne peut pas les transposer à d'autres pools.

Trois niveaux d'observation

On peut observer à trois endroits, et chacun voit sa part du tableau.

Aucun niveau n'est autosuffisant. Le mineur signalera honnêtement une surchauffe, mais restera muet si votre fournisseur a coupé la route vers le pool. Le pool verra la disparition des shares, mais avec du retard et sans expliquer la cause. Le capteur d'alimentation réagira instantanément, mais ne distinguera pas une machine éteinte d'une machine plantée.

Le minimum fonctionnel, c'est le premier et le troisième niveau: données locales pour la cause, données du pool pour vérifier que le travail est bien rémunéré.

Quelles métriques annoncent une panne à l'avance

Réponse directe: la part de shares rejetés, un écart persistant entre le hashrate local et celui du pool, la température des puces et le compteur de redémarrages. Ces quatre chiffres changent avant que la machine ne s'arrête complètement, et donnent le temps d'intervenir avant que le downtime ne devienne total.

1. Shares rejetés (reject rate). Une part croissante de rejets, c'est presque toujours le réseau: perte de paquets, routeur surchargé, route défaillante vers le serveur du pool. Ne cherchez pas la norme de rejet dans les articles des autres, mais dans vos propres données sur une semaine calme: chaque combinaison matériel-fournisseur a la sienne.
2. L'écart entre hashrate local et hashrate du pool. Il y a une section à part plus bas à ce sujet, car c'est là qu'on panique le plus souvent pour rien.
3. Température des puces et vitesse des ventilateurs. Un radiateur encrassé fait monter la température progressivement. La machine réduit d'abord sa fréquence toute seule, perdant des pourcentages de rentabilité en silence, et ce n'est qu'ensuite qu'elle passe en protection. C'est précisément cette phase de dégradation silencieuse qu'un seuil de température détecte bien.
4. Compteur d'uptime. Si l'uptime de la machine se réinitialise régulièrement, vous avez des redémarrages dont le pool ne vous parlera pas: entre les redémarrages, les shares circulent, le statut est vert, mais la production totale est plus faible.
5. Nombre de hashboards en fonctionnement. Une carte tombée sur une machine à trois cartes, c'est un tiers de revenu en moins avec un worker parfaitement vivant sur le tableau de bord.

Pourquoi le pool affiche toujours moins que le mineur lui-même

Réponse directe: le mineur affiche la vitesse de calcul qu'il a lui-même comptée, et le pool affiche une estimation reconstituée à partir des shares acceptés. La seconde valeur est statistique, elle fluctue donc et se retrouve en moyenne plus basse: une partie du travail part dans des shares rejetés et retardés, une partie se perd dans l'arrondi de la fenêtre de moyenne.

La règle pratique est simple. Un écart de quelques pourcents qui monte et descend au fil de la journée, c'est une dispersion normale de l'échantillon, pas une panne. Le vrai signal se présente autrement: le hashrate du pool descend et y reste, alors que le hashrate local ne change pas. Ce tableau signifie que la machine calcule, mais que le résultat n'arrive pas au pool ou n'est pas comptabilisé.

Quelle est la norme pour votre combinaison précise, personne ne peut vous le dire à votre place. Rassemblez vos propres chiffres sur une semaine calme, calculez le rapport moyen entre le hashrate du pool et le hashrate local, et partez de là. Il faut procéder de même pour tous les seuils ci-dessous.

Comment monter une alerte sans services tiers

Il faut une machine qui tourne 24 heures sur 24 et sait faire des requêtes HTTP: un mini-serveur domestique, un routeur capable d'exécuter des scripts, un vieux portable. Ensuite, deux sources de données.

Côté mineur. L'interface web de l'ASIC fournit le hashrate actuel, les températures, les vitesses de ventilateurs, l'uptime, l'état des hashboards et les compteurs de rejets. Sur beaucoup de firmwares, les mêmes données sont accessibles de façon lisible par machine via une API locale ou un socket de gestion. Les adresses et le format exacts dépendent du fabricant et de la version du firmware; consultez la documentation de votre modèle.

Côté pool. Certains pools proposent une API de compte avec le hashrate des workers et leurs statuts, via une clé du tableau de bord personnel. La disponibilité, le format et les limites de requêtes varient d'un pool à l'autre, et cela se vérifie dans la documentation de chaque pool: il n'y a pas de norme unique ici, et nous n'avons pas confirmé d'endpoints au-delà de ce qui est décrit dans nos rapports.

La logique du script tient en une dizaine de lignes: interroger les mineurs chaque minute, interroger le pool toutes les quelques minutes, comparer les valeurs aux seuils, et en cas de dépassement envoyer un message sur une messagerie ou par e-mail. Prévoyez aussi l'inverse: si le script lui-même reste muet plus d'une demi-heure, c'est qu'il est tombé, pas la ferme. Un moniteur silencieux est le pire type de moniteur, car il crée une fausse impression de contrôle.

Quel seuil fixer pour ne pas se noyer dans les fausses alertes

Réponse directe: pas sur une seule mesure, mais sur plusieurs d'affilée. La recherche de shares est un processus aléatoire, et de brèves chutes du graphique sont inévitables même sur une ferme parfaitement saine. Le seuil doit exiger que l'écart se maintienne sur plusieurs intervalles de sondage d'affilée, sinon vous recevrez des alertes toutes les heures et cesserez très vite de les lire.

Un schéma pratique ressemble à ceci:

1. Silence total du mineur. Le sondage local ne répond pas deux fois de suite. Ce n'est déjà plus de la dispersion, il faut réagir immédiatement.
2. Chute de hashrate. Valeur inférieure à votre norme de fonctionnement et qui s'y maintient sur plusieurs mesures d'affilée. De combien en dessous et sur combien de mesures, à déterminer selon votre propre historique sur une semaine calme.
3. Température. Prenez le seuil dans la documentation du fabricant de votre modèle, et fixez l'alerte avec une marge sous la température de déclenchement de la protection, pour avoir le temps de réagir avant un arrêt d'urgence.
4. Shares rejetés. Comparez à votre propre fond calme, pas à un chiffre absolu trouvé sur internet.
5. Silence du pool. Utile, mais n'oubliez pas le délai: chez AntPool, même le statut officiel Inactive n'apparaît qu'après 20 minutes. Cette alerte arrivera toujours après l'alerte locale.

Encore une règle: chaque alerte doit avoir un temps de repos après déclenchement. Sinon, une panne à trois heures du matin se transformera en quarante messages identiques, et le matin vous passerez votre temps à trier les notifications au lieu de vous occuper de la ferme.

Décidez séparément quoi faire au moment du déclenchement. Si la ferme n'est pas chez vous, une alerte sans possibilité d'agir à distance devient un moyen de vous gâcher la nuit. C'est là que rejoint le sujet du pool de secours: une partie des pannes n'est pas une casse matérielle, mais un problème du côté du pool ou de la route qui y mène, et cela se règle par une bascule automatique, pas par un déplacement. Sur la configuration d'une adresse de secours, nous avons écrit à part.

Checklist pour une soirée

1. Calculez le coût d'une heure de downtime chez vous avec la formule ci-dessus. Un seul chiffre donne du sens à tout le reste.
2. Constituez une ligne de base: hashrate local, hashrate du pool, températures, part des rejets sur une journée calme.
3. Vérifiez si votre firmware fournit des données lisibles par machine, et notez l'adresse.
4. Vérifiez dans la documentation de votre pool s'il existe une API de compte et quelles en sont les limites.
5. Écrivez un sondage des mineurs toutes les minutes, avec enregistrement dans un fichier ou une base simple.
6. Configurez quatre alertes: absence de réponse, chute de hashrate, température, hausse des rejets.
7. Ajoutez un temps de repos après déclenchement et une protection contre un moniteur silencieux.
8. Testez tout honnêtement: débranchez le câble réseau d'une machine et chronométrez le délai avant l'arrivée du message.
9. Renseignez un second pool dans les paramètres du mineur, si ce n'est pas déjà fait.
10. Au bout d'une semaine, révisez les seuils à partir des données accumulées. Ils ne sont presque jamais bons du premier coup.

Le huitième point est celui qu'on saute le plus souvent, et c'est le seul qui prouve que le système fonctionne réellement.

À lire ensuite

• Calculateur de rentabilité de minage: entrez votre propre hashrate et voyez combien coûte une journée de downtime dans votre cas.
• Le pool est en panne: comment savoir que ce n'est pas votre ferme: comment distinguer un problème de votre côté d'un problème côté pool.
• Pool de secours: pourquoi renseigner une seconde adresse: bascule automatique en cas de panne sans votre intervention.
• Comparaison des pools de minage: commissions, schémas de paiement et seuils de retrait.

Le monitoring n'augmente pas le revenu. Il empêche simplement de perdre ce qui a déjà été gagné, et dans le minage la différence entre ces deux choses est quasiment nulle.