Monitoramento de mineração e alertas: como saber de um downtime em minutos, não em um dia

O downtime numa fazenda quase nunca parece dramático. As luzes não se apagam, não sai fumaça. Simplesmente, em algum momento, parte das máquinas para de entregar shares, e você descobre pela manhã, quando o pagamento sai menor que o de ontem. Nessa altura o dinheiro já se perdeu, e não há como recuperá-lo: a rede não recalcula sua parcela retroativamente.

A seguir explicamos por que o dashboard do pool não serve bem como sistema de alertas, quais métricas avisam de uma falha com antecedência e como montar um alerta simples com o que você já tem à mão.

Quanto custa uma hora de downtime

Calculamos com a fórmula que qualquer calculadora de rentabilidade usa:

\`\`\`

BTC por dia = (hashrate × 86400) / (dificuldade × 2^32) × 3.125

\`\`\`

Aqui 86400 são os segundos do dia, 2^32 vem da definição de dificuldade, e 3.125 BTC é o subsídio atual por bloco (valor do nosso corte de rede em 08.09.2026).

Substituindo uma dificuldade de 127,45 trilhões (mempool.space, 08.09.2026) e uma cotação de 78.349 dólares:

O cálculo é bruto, antes da taxa do pool e da eletricidade, e não considera as taxas de transação (segundo a mempool.space, em 08.09.2026 elas acrescentavam 0,66% à recompensa numa janela de 4320 blocos, ou seja, em ordem de grandeza isso quase não muda nada).

Depois é aritmética simples. Uma falha à uma da manhã, notada à uma da tarde. Doze horas, fazenda de 10 PH/s: cerca de 193 dólares que simplesmente não vão aparecer no pagamento. Uma vez por mês essa coincidência, e no ano isso custa mais de dois mil dólares com equipamento perfeitamente funcional.

Por que o dashboard do pool não substitui o monitoramento

Resumindo: o pool não mostra o estado do seu equipamento, mas o estado do fluxo de shares que chegou até ele. Entre a queda e a mudança de status no dashboard passam dezenas de minutos, porque o pool precisa distinguir uma falha real de uma simples queda de conexão. Na AntPool isso está formalizado oficialmente: um worker recebe o status Inactive após 20 minutos sem shares, e o status Invalid só depois de 24 horas de silêncio (AntPool support, Worker Management).

Vinte minutos já são 5,4 dólares a 10 PH/s, e esse é o melhor cenário: o worker caiu por completo e o status realmente muda. Se a máquina está funcionando mas entrega metade, o status continua verde, e o pool não vai lhe dizer nada.

Há ainda um segundo motivo. O hashrate no dashboard do pool não é uma medição, mas uma estimativa baseada no número de shares aceitos numa janela de média. Cada pool tem sua própria janela, e nem sempre isso está indicado na documentação. Quanto mais curta a janela, mais nervoso o gráfico; quanto mais longa, mais tarde ele reage a uma queda real.

Os valores de atraso e limites de outros pools devem ser verificados na documentação própria de cada um: números confirmados oficialmente só encontramos na AntPool, e não podem ser transpostos para outros pools.

Três níveis de observação

Dá para observar em três lugares, e cada um enxerga sua parte do quadro.

Nenhum nível é autossuficiente. O minerador vai avisar honestamente sobre um superaquecimento, mas vai ficar calado se sua operadora cortou a rota até o pool. O pool vai ver o sumiço dos shares, mas com atraso e sem explicar a causa. O sensor de energia reage instantaneamente, mas não distingue uma máquina desligada de uma travada.

O mínimo funcional é o primeiro e o terceiro nível: dados locais para a causa, dados do pool para conferir que o trabalho foi efetivamente pago.

Quais métricas avisam de uma falha com antecedência

Resposta direta: a proporção de shares rejeitados, uma divergência persistente entre o hashrate local e o do pool, a temperatura dos chips e o contador de reinicializações. Esses quatro números mudam antes de a máquina parar completamente, e dão tempo para intervir antes de o downtime se tornar total.

1. Shares rejeitados (reject rate). Uma proporção crescente de rejeições é quase sempre a rede: perda de pacotes, roteador sobrecarregado, rota ruim até o servidor do pool. Não procure a norma de rejeição em artigos de terceiros, mas nos seus próprios dados de uma semana tranquila: cada combinação de equipamento e provedor tem a sua.
2. A diferença entre hashrate local e hashrate do pool. Mais abaixo há uma seção separada sobre isso, porque é aqui que mais se entra em pânico à toa.
3. Temperatura dos chips e rotação dos ventiladores. Um radiador tomado de poeira eleva a temperatura gradualmente. A máquina primeiro reduz a frequência sozinha, perdendo rentabilidade em silêncio, e só depois entra em proteção. É justamente essa fase de degradação silenciosa que um limite de temperatura capta bem.
4. Contador de uptime. Se o uptime da máquina reinicia com regularidade, você tem reinicializações das quais o pool não vai lhe falar: entre os reinícios os shares seguem, o status fica verde, mas a produção total é menor.
5. Número de hashboards funcionando. Uma placa caída numa máquina de três placas significa um terço a menos de receita com o worker totalmente vivo no dashboard.

Por que o pool sempre mostra menos que o próprio minerador

Resposta direta: o minerador mostra a velocidade de busca que ele mesmo calculou, e o pool mostra uma estimativa reconstruída a partir dos shares aceitos. O segundo valor é estatístico, por isso oscila e em média fica menor: parte do trabalho vai para shares rejeitados e atrasados, parte se perde no arredondamento da janela de média.

A regra prática é simples. Uma divergência de alguns pontos percentuais, que sobe e desce ao longo do dia, é dispersão normal da amostra, não uma falha. O sinal real aparece diferente: o hashrate do pool cai e fica lá, enquanto o local não muda. Esse quadro significa que a máquina está calculando, mas o resultado não chega ao pool ou não está sendo contabilizado.

Quão grande é a norma para a sua combinação específica, ninguém pode dizer por você. Reúna seus próprios números numa semana tranquila, calcule a razão média entre o hashrate do pool e o local, e parta daí. O mesmo vale para todos os limites abaixo.

Como montar um alerta sem serviços de terceiros

É preciso qualquer máquina que funcione 24 horas por dia e saiba fazer requisições HTTP: um mini servidor caseiro, um roteador capaz de rodar scripts, um notebook antigo. Depois, duas fontes de dados.

Do lado do minerador. A interface web do ASIC fornece hashrate atual, temperaturas, rotações, uptime, estado dos hashboards e contadores de rejeição. Em muitos firmwares os mesmos dados estão disponíveis de forma legível por máquina via API local ou socket de gestão. Endereços e formato exatos dependem do fabricante e da versão do firmware; consulte a documentação do seu modelo.

Do lado do pool. Alguns pools têm uma API de conta com hashrate dos workers e seus status, mediante uma chave do painel pessoal. Disponibilidade, formato e limites de requisições variam de pool para pool, e isso precisa ser verificado na documentação de cada um: não há um padrão único aqui, e não confirmamos endpoints além do que está descrito em nossos relatórios.

A lógica do script cabe em umas dez linhas: consultar os mineradores a cada minuto, consultar o pool a cada alguns minutos, comparar os valores com os limites, e ao detectar uma violação enviar uma mensagem para um mensageiro ou e-mail. Preveja também o inverso: se o próprio script ficar calado por mais de meia hora, significa que ele caiu, não a fazenda. Um monitor silencioso é o pior tipo de monitor, porque cria uma falsa sensação de controle.

Qual limite definir para não se afogar em falsos alarmes

Resposta direta: não com base numa única medição, mas em várias seguidas. A busca por shares é um processo aleatório, e quedas breves no gráfico são inevitáveis mesmo numa fazenda saudável. O limite deve exigir que o desvio se mantenha por vários intervalos de consulta seguidos, caso contrário você vai receber alertas a cada hora e vai parar de lê-los muito rápido.

Um esquema prático se parece com isto:

1. Silêncio total do minerador. A consulta local não responde duas vezes seguidas. Isso já não é dispersão, é preciso reagir imediatamente.
2. Queda de hashrate. Valor abaixo da sua norma habitual e que se mantém assim por várias medições seguidas. Quanto abaixo e por quantas medições, defina com base no seu próprio histórico de uma semana tranquila.
3. Temperatura. Pegue o limite na documentação do fabricante do seu modelo, e configure o alerta com margem abaixo da temperatura de disparo da proteção, para dar tempo de reagir antes de um desligamento de emergência.
4. Shares rejeitados. Compare com seu próprio fundo habitual, não com um número absoluto tirado da internet.
5. Silêncio do pool. Útil, mas lembre-se do atraso: na AntPool até o status oficial Inactive só aparece depois de 20 minutos. Esse alerta sempre vai chegar depois do local.

Mais uma regra: cada alerta precisa ter um tempo de silêncio depois de disparar. Caso contrário, uma falha às três da manhã vira quarenta mensagens idênticas, e de manhã você vai gastar tempo organizando notificações em vez de cuidar da fazenda.

Decida à parte o que fazer no momento do disparo. Se a fazenda não fica na sua casa, um alerta sem possibilidade de agir remotamente se transforma numa forma de estragar sua noite. Aqui entra o tema do pool reserva: parte das falhas não é defeito de hardware, mas um problema do lado do pool ou da rota até ele, e isso se resolve com troca automática, não com deslocamento. Sobre configurar um endereço reserva escrevemos à parte.

Checklist para uma noite

1. Calcule seu próprio custo de uma hora de downtime com a fórmula acima. Um único número dá sentido a todo o resto do trabalho.
2. Reúna uma linha de base: hashrate local, hashrate do pool, temperaturas, proporção de rejeições num dia tranquilo.
3. Verifique se seu firmware entrega dados de forma legível por máquina, e anote o endereço.
4. Verifique na documentação do seu pool se existe uma API de conta e quais são as limitações dela.
5. Escreva uma consulta aos mineradores a cada minuto, com registro em arquivo ou banco de dados simples.
6. Configure quatro alertas: sem resposta, queda de hashrate, temperatura, aumento de rejeições.
7. Adicione um tempo de silêncio após o disparo e uma proteção contra monitor silencioso.
8. Teste tudo honestamente: desconecte o cabo de rede de uma máquina e cronometre quanto tempo até a mensagem chegar.
9. Configure um segundo pool nas definições do minerador, caso ainda não tenha feito isso.
10. Depois de uma semana, revise os limites com base nos dados acumulados. Quase nunca acertam de primeira.

O item oito é o mais pulado, e é o único que prova que o sistema realmente funciona.

O que ler a seguir

• Calculadora de rentabilidade de mineração: insira seu próprio hashrate e veja quanto custa um dia de downtime no seu caso.
• O pool está fora do ar: como saber que o problema não é da sua fazenda: como distinguir um problema do seu lado de um problema do lado do pool.
• Pool reserva: por que configurar um segundo endereço: troca automática em caso de falha sem sua participação.
• Comparação de pools de mineração: taxas, esquemas de pagamento e limites de saque.

O monitoramento não aumenta a receita. Ele apenas evita perder o que já foi ganho, e na mineração a diferença entre essas duas coisas é praticamente nula.