Pemantauan mining dan alert: cara mengetahui downtime dalam hitungan menit, bukan sehari penuh

Downtime di farm hampir tidak pernah terlihat dramatis. Lampu tidak padam, tidak ada asap. Hanya saja, pada suatu saat sebagian mesin berhenti mengirim share, dan Anda baru mengetahuinya pada pagi hari, ketika pembayaran ternyata lebih kecil dari kemarin. Pada saat itu uangnya sudah hilang, dan tidak bisa dikembalikan: jaringan tidak menghitung ulang bagian Anda secara retroaktif.

Di bawah ini kami bahas mengapa dashboard pool kurang cocok berperan sebagai sistem peringatan, metrik apa yang memberi peringatan dini tentang kerusakan, dan bagaimana menyusun sistem peringatan sederhana dari apa yang sudah ada di tangan Anda.

Berapa biaya satu jam downtime

Kami menghitung dengan rumus yang digunakan kalkulator profitabilitas mana pun:

\`\`\`

BTC per hari = (hashrate × 86400) / (difficulty × 2^32) × 3.125

\`\`\`

Di sini 86400 adalah jumlah detik dalam sehari, 2^32 berasal dari definisi difficulty, dan 3.125 BTC adalah subsidi blok saat ini (nilai dari data jaringan kami per 08.09.2026).

Dengan memasukkan difficulty 127,45 triliun (mempool.space, 08.09.2026) dan kurs 78.349 dolar:

Perhitungan ini bersifat kotor, sebelum komisi pool dan listrik, dan tidak memperhitungkan biaya transaksi (menurut mempool.space, pada 08.09.2026 biaya tersebut menambah 0,66% pada reward dalam jendela 4320 blok, jadi secara orde besaran ini hampir tidak mengubah apa pun).

Selanjutnya aritmatika sederhana. Kegagalan terjadi jam satu dini hari, baru disadari jam satu siang. Dua belas jam, farm dengan 10 PH/s: sekitar 193 dolar yang tidak akan muncul dalam pembayaran. Jika kebetulan seperti ini terjadi sekali sebulan, dalam setahun itu merugikan Anda lebih dari dua ribu dolar meski peralatan berfungsi sepenuhnya normal.

Mengapa dashboard pool tidak menggantikan monitoring

Singkatnya: pool tidak menampilkan kondisi peralatan Anda, melainkan kondisi aliran share yang sampai ke pool. Antara terputusnya koneksi dan perubahan status di dashboard bisa berlalu puluhan menit, karena pool harus membedakan kegagalan sesungguhnya dari sekadar putusnya koneksi biasa. Di AntPool hal ini diresmikan secara resmi: worker mendapat status Inactive setelah 20 menit tanpa share, dan status Invalid baru setelah 24 jam sunyi (AntPool support, Worker Management).

Dua puluh menit itu sudah 5,4 dolar pada 10 PH/s, dan ini adalah skenario terbaik: worker jatuh sepenuhnya dan statusnya memang berubah. Jika mesin tetap bekerja tapi menghasilkan setengahnya, statusnya akan tetap hijau, dan pool tidak akan memberitahu apa pun.

Ada juga alasan kedua. Hashrate di dashboard pool bukanlah pengukuran, melainkan estimasi berdasarkan jumlah share yang diterima dalam jendela rata-rata. Setiap pool punya jendelanya sendiri, dan tidak selalu tercantum di dokumentasi. Semakin pendek jendelanya, semakin gugup grafiknya; semakin panjang, semakin lambat reaksinya terhadap penurunan sesungguhnya.

Nilai keterlambatan dan ambang batas pool lain periksalah di dokumentasi masing-masing: angka yang dikonfirmasi resmi hanya kami temukan di AntPool, dan tidak bisa diterapkan begitu saja ke pool lain.

Tiga tingkat pengamatan

Pengamatan bisa dilakukan di tiga tempat, dan masing-masing melihat bagiannya sendiri dari gambaran keseluruhan.

Tidak ada tingkat yang mandiri sepenuhnya. Miner akan jujur melaporkan overheating, tapi diam saja jika penyedia layanan Anda memutus rute ke pool. Pool akan melihat hilangnya share, tapi dengan keterlambatan dan tanpa menjelaskan penyebabnya. Sensor daya akan bereaksi seketika, tapi tidak bisa membedakan mesin yang dimatikan dari mesin yang hang.

Minimum yang berfungsi adalah tingkat pertama dan ketiga: data lokal untuk mencari penyebab, data pool untuk memastikan pekerjaan benar-benar dibayar.

Metrik apa yang memberi peringatan dini tentang kerusakan

Jawaban langsung: proporsi share yang ditolak, selisih yang persisten antara hashrate lokal dan hashrate pool, suhu chip, dan penghitung restart. Keempat angka ini berubah sebelum mesin benar-benar berhenti, dan memberi waktu untuk campur tangan sebelum downtime menjadi total.

1. Share ditolak (reject rate). Proporsi penolakan yang meningkat hampir selalu berarti masalah jaringan: kehilangan paket, router yang kelebihan beban, rute yang buruk ke server pool. Jangan mencari norma penolakan di artikel orang lain, tapi di data Anda sendiri selama seminggu yang tenang: setiap kombinasi peralatan dan penyedia layanan punya normanya sendiri.
2. Selisih antara hashrate lokal dan hashrate pool. Di bawah ada bagian tersendiri mengenai hal ini, karena di sinilah orang paling sering panik tanpa alasan.
3. Suhu chip dan putaran kipas. Radiator yang tersumbat debu menaikkan suhu secara bertahap. Mesin pertama-tama menurunkan frekuensinya sendiri, secara diam-diam kehilangan persentase profitabilitas, dan baru setelah itu masuk ke mode proteksi. Justru fase degradasi diam-diam inilah yang tertangkap baik dengan ambang batas suhu.
4. Penghitung uptime. Jika uptime mesin sering ter-reset, berarti Anda mengalami restart yang tidak akan diberitahukan oleh pool: di antara restart, share tetap masuk, status tetap hijau, tapi produksi total lebih rendah.
5. Jumlah hashboard yang berfungsi. Satu board yang jatuh pada mesin dengan tiga board berarti kehilangan sepertiga pendapatan padahal worker terlihat sepenuhnya hidup di dashboard.

Mengapa pool selalu menampilkan angka lebih rendah dari miner itu sendiri

Jawaban langsung: miner menampilkan kecepatan pencarian yang dihitung sendiri, sedangkan pool menampilkan estimasi yang direkonstruksi dari share yang diterima. Nilai yang kedua bersifat statistik, sehingga berfluktuasi dan rata-rata lebih rendah: sebagian pekerjaan hilang dalam share yang ditolak dan terlambat, sebagian lagi hilang dalam pembulatan jendela rata-rata.

Aturan praktisnya sederhana. Selisih beberapa persen yang naik turun sepanjang hari adalah dispersi sampel normal, bukan kerusakan. Sinyal sesungguhnya terlihat berbeda: hashrate pool turun dan tetap di sana, sementara hashrate lokal tidak berubah. Gambaran seperti ini berarti mesin sedang menghitung, tapi hasilnya tidak sampai ke pool atau tidak dihitung.

Seberapa besar norma untuk kombinasi spesifik Anda, tidak ada yang bisa memberi tahu Anda. Kumpulkan angka Anda sendiri selama seminggu yang tenang, hitung rasio rata-rata antara hashrate pool dan hashrate lokal, dan jadikan itu sebagai acuan. Hal yang sama berlaku untuk semua ambang batas di bawah ini.

Cara membangun sistem peringatan tanpa layanan pihak ketiga

Diperlukan mesin apa pun yang berjalan 24 jam dan bisa melakukan request HTTP: mini server rumahan, router yang bisa menjalankan skrip, laptop lama. Selanjutnya dua sumber data.

Dari sisi miner. Antarmuka web ASIC memberikan hashrate saat ini, suhu, putaran kipas, uptime, status hashboard, dan penghitung penolakan. Di banyak firmware, data yang sama juga tersedia dalam format yang bisa dibaca mesin melalui API lokal atau socket manajemen. Alamat dan format yang tepat bergantung pada produsen dan versi firmware, periksa dokumentasi model Anda.

Dari sisi pool. Sebagian pool memiliki API akun dengan hashrate worker dan statusnya, melalui kunci dari panel pribadi. Ketersediaan, format, dan batas request berbeda-beda di setiap pool, dan hal ini perlu diperiksa di dokumentasi pool masing-masing: tidak ada standar tunggal di sini, dan kami tidak mengonfirmasi endpoint di luar apa yang dijelaskan dalam laporan kami.

Logika skripnya muat dalam sepuluh baris: memeriksa miner setiap menit, memeriksa pool setiap beberapa menit, membandingkan nilai dengan ambang batas, dan saat terjadi pelanggaran mengirim pesan ke messenger atau email. Siapkan juga kebalikannya: jika skrip itu sendiri diam lebih dari setengah jam, berarti yang jatuh adalah skripnya, bukan farm-nya. Monitor yang diam adalah jenis monitor terburuk, karena menciptakan ilusi kontrol.

Ambang batas berapa yang harus dipasang agar tidak tenggelam dalam alarm palsu

Jawaban langsung: bukan berdasarkan satu pengukuran, tapi beberapa berturut-turut. Pencarian share adalah proses acak, dan penurunan grafik yang singkat tidak terhindarkan bahkan pada farm yang sepenuhnya sehat. Ambang batas harus mensyaratkan bahwa penyimpangan bertahan selama beberapa interval polling berturut-turut, jika tidak Anda akan menerima peringatan setiap jam dan sangat cepat berhenti membacanya.

Skema praktisnya seperti ini:

1. Kesunyian total miner. Polling lokal tidak merespons dua kali berturut-turut. Ini bukan lagi dispersi, harus segera bereaksi.
2. Penurunan hashrate. Nilai di bawah norma kerja Anda dan bertahan di sana selama beberapa pengukuran berturut-turut. Seberapa rendah dan berapa kali pengukuran, tentukan berdasarkan riwayat Anda sendiri selama seminggu yang tenang.
3. Suhu. Ambil ambang batas dari dokumentasi produsen model Anda, dan pasang peringatan dengan margin di bawah suhu pemicu proteksi, agar sempat bereaksi sebelum shutdown darurat.
4. Share ditolak. Bandingkan dengan baseline tenang Anda sendiri, bukan dengan angka absolut dari internet.
5. Kesunyian pool. Berguna, tapi ingat keterlambatannya: di AntPool bahkan status resmi Inactive baru muncul setelah 20 menit. Peringatan semacam ini akan selalu datang lebih lambat dari peringatan lokal.

Satu aturan lagi: setiap alert harus punya waktu tenang setelah terpicu. Jika tidak, satu kegagalan pada jam tiga dini hari akan berubah menjadi empat puluh pesan yang identik, dan di pagi hari Anda akan sibuk membereskan notifikasi alih-alih mengurus farm.

Putuskan secara terpisah apa yang harus dilakukan pada saat alert terpicu. Jika farm tidak berada di rumah Anda, peringatan tanpa kemungkinan berbuat apa pun dari jarak jauh berubah menjadi cara untuk merusak malam Anda. Di sinilah topik pool cadangan terkait: sebagian kegagalan bukan kerusakan perangkat keras, melainkan masalah di sisi pool atau rute menuju pool, dan itu diatasi dengan pengalihan otomatis, bukan dengan kunjungan langsung. Tentang pengaturan alamat cadangan sudah kami bahas secara terpisah.

Checklist untuk satu malam

1. Hitung biaya satu jam downtime Anda sendiri dengan rumus di atas. Satu angka membuat semua upaya selanjutnya jadi masuk akal.
2. Kumpulkan baseline: hashrate lokal, hashrate pool, suhu, proporsi penolakan selama satu hari yang tenang.
3. Periksa apakah firmware Anda memberikan data yang bisa dibaca mesin, dan catat alamatnya.
4. Periksa di dokumentasi pool Anda apakah ada API akun dan apa batasannya.
5. Tulis skrip yang memeriksa miner setiap menit dengan pencatatan ke file atau basis data sederhana.
6. Atur empat alert: tidak ada respons, penurunan hashrate, suhu, kenaikan penolakan.
7. Tambahkan waktu tenang setelah terpicu dan proteksi terhadap monitor yang diam.
8. Uji semuanya secara jujur: cabut kabel jaringan dari satu mesin dan ukur berapa lama pesan sampai.
9. Daftarkan pool kedua di pengaturan miner, jika belum dilakukan.
10. Setelah seminggu, tinjau ulang ambang batas berdasarkan data yang terkumpul. Hampir tidak pernah tepat pada percobaan pertama.

Poin kedelapan paling sering dilewatkan, padahal itu satu-satunya yang membuktikan bahwa sistemnya benar-benar berfungsi.

Apa yang perlu dibaca selanjutnya

• Kalkulator profitabilitas mining: masukkan hashrate Anda sendiri dan lihat berapa biaya satu hari downtime bagi Anda secara pribadi.
• Pool sedang down: cara mengetahui bahwa masalahnya bukan di farm Anda: cara membedakan masalah di sisi Anda dari masalah di sisi pool.
• Pool cadangan: mengapa perlu mendaftarkan alamat kedua: pengalihan otomatis saat terjadi kegagalan tanpa perlu campur tangan Anda.
• Perbandingan pool mining: komisi, skema pembayaran, dan ambang batas penarikan.

Monitoring tidak meningkatkan pendapatan. Ia hanya mencegah hilangnya apa yang sudah diperoleh, dan dalam mining perbedaan antara kedua hal ini nyaris tidak ada.