مراقبة التعدين والتنبيهات: كيف تعرف بتوقف العمل خلال دقائق، لا خلال يوم كامل

توقف العمل في المزرعة لا يبدو دراميًا في الغالب. لا تنطفئ الأضواء، ولا يتصاعد الدخان. ببساطة، في لحظة ما، يتوقف جزء من الأجهزة عن تقديم الـ shares، وتعرف بذلك في الصباح، عندما تكون الدفعة أقل من اليوم السابق. في هذه اللحظة يكون المال قد فُقد بالفعل، ولا يمكن استرجاعه: الشبكة لا تعيد حساب حصتك بأثر رجعي.

فيما يلي نشرح لماذا لا تصلح لوحة تحكم البول كنظام إنذار جيد، وما هي المقاييس التي تحذر من عطل مبكرًا، وكيف تبني تنبيهًا بسيطًا مما هو متاح لديك بالفعل.

كم تكلفة ساعة واحدة من التوقف

نحسب بالصيغة التي تستخدمها أي حاسبة ربحية:

\`\`\`

BTC في اليوم = (hashrate × 86400) / (difficulty × 2^32) × 3.125

\`\`\`

هنا 86400 هي ثواني اليوم، و2^32 مستمدة من تعريف الـ difficulty، و3.125 BTC هي مكافأة الكتلة الحالية (القيمة من لقطة الشبكة لدينا بتاريخ 08.09.2026).

بتعويض difficulty بقيمة 127.45 تريليون (mempool.space، 08.09.2026) وسعر صرف 78,349 دولارًا:

هذا الحساب إجمالي، قبل خصم عمولة البول والكهرباء، ولا يأخذ في الحسبان رسوم المعاملات (بحسب mempool.space، في 08.09.2026 كانت تضيف 0.66% إلى المكافأة خلال نافذة 4320 بلوكًا، أي أن هذا لا يغير شيئًا يُذكر من حيث الحجم).

بعد ذلك حساب بسيط. عطل حدث في الساعة الواحدة صباحًا، ولوحظ في الساعة الواحدة ظهرًا. اثنتا عشرة ساعة، مزرعة بقدرة 10 PH/s: نحو 193 دولارًا ببساطة لن تظهر في الدفعة. إذا تكررت هذه المصادفة مرة كل شهر، فإنها تكلفك في السنة أكثر من ألفي دولار مع معدات تعمل بشكل طبيعي تمامًا.

لماذا لا تحل لوحة تحكم البول محل المراقبة

باختصار: البول لا يعرض حالة جهازك، بل حالة تدفق الـ shares التي وصلت إليه. بين الانقطاع وتغيّر الحالة في لوحة التحكم تمر عشرات الدقائق، لأن البول يجب أن يميّز بين عطل حقيقي وانقطاع اتصال عادي. في AntPool هذا موثّق رسميًا: يحصل الـ worker على حالة Inactive بعد 20 دقيقة بدون shares، وحالة Invalid فقط بعد 24 ساعة من الصمت (AntPool support, Worker Management).

عشرون دقيقة تعني بالفعل 5.4 دولار عند 10 PH/s، وهذه أفضل حالة: الـ worker سقط بالكامل والحالة تتغير فعليًا. إذا كان الجهاز يعمل لكن يعطي نصف الإنتاج، ستبقى الحالة خضراء، ولن يخبرك البول بشيء.

هناك سبب ثانٍ أيضًا. الـ hashrate في لوحة تحكم البول ليس قياسًا، بل تقديرًا مبنيًا على عدد الـ shares المقبولة خلال نافذة متوسط. لكل بول نافذته الخاصة، وهذا لا يُذكر دائمًا في التوثيق. كلما كانت النافذة أقصر، كان الرسم البياني أكثر تذبذبًا؛ وكلما طالت، تأخر رد فعله على الانخفاض الحقيقي.

قيم التأخير والحدود لدى بولات أخرى تحقق منها في توثيقها الخاص: الأرقام المؤكدة رسميًا وجدناها فقط لدى AntPool، ولا يمكن نقلها إلى بولات أخرى.

ثلاثة مستويات للمراقبة

يمكن المراقبة في ثلاثة أماكن، وكل منها يرى جزءًا من الصورة.

لا يوجد مستوى مكتفٍ ذاتيًا. الماينر سيخبرك بصدق عن ارتفاع الحرارة، لكنه سيصمت إذا قطع مزود خدمتك المسار إلى البول. البول سيرى اختفاء الـ shares، لكن بتأخير وبدون تفسير السبب. حساس الطاقة سيتفاعل فورًا، لكنه لن يميّز بين جهاز مطفأ وجهاز متجمّد.

الحد الأدنى العملي هو المستوى الأول والثالث: بيانات محلية لمعرفة السبب، وبيانات البول للتأكد من أن العمل قد دُفع بالفعل.

ما هي المقاييس التي تحذر من عطل مبكرًا

إجابة مباشرة: نسبة الـ shares المرفوضة، وفجوة مستمرة بين الـ hashrate المحلي وحشرات البول، ودرجة حرارة الشرائح، وعداد إعادة التشغيل. هذه الأرقام الأربعة تتغير قبل أن يتوقف الجهاز تمامًا، وتمنح وقتًا للتدخل قبل أن يصبح التوقف كاملًا.

1. الـ shares المرفوضة (reject rate). نسبة الرفض المتزايدة تكون في الغالب مشكلة شبكة: فقدان حزم، راوتر محمّل زيادة عن طاقته، مسار سيئ إلى خادم البول. لا تبحث عن معدل الرفض الطبيعي في مقالات الآخرين، بل في بياناتك الخاصة خلال أسبوع هادئ: لكل توليفة من الجهاز ومزود الخدمة معدلها الخاص.
2. الفجوة بين الـ hashrate المحلي والبولي. يوجد قسم منفصل عن هذا أدناه، لأن هذا هو المكان الذي يحدث فيه الذعر بلا مبرر في أغلب الأحيان.
3. درجة حرارة الشرائح ودوران المراوح. المبرد المغطى بالغبار يرفع درجة الحرارة تدريجيًا. يقلل الجهاز أولًا من التردد بنفسه، فيخسر نسبة من الربحية بصمت، وبعد ذلك فقط يدخل في وضع الحماية. هذه المرحلة من التدهور الصامت بالذات يمكن رصدها جيدًا بحد للحرارة.
4. عداد الـ uptime. إذا كان الـ uptime للجهاز يُعاد تصفيره بانتظام، فلديك عمليات إعادة تشغيل لن يخبرك البول عنها: بين إعادات التشغيل تسير الـ shares، والحالة خضراء، لكن الإنتاج الإجمالي أقل.
5. عدد الـ hashboards العاملة. سقوط لوحة واحدة في جهاز بثلاث لوحات يعني خسارة ثلث الدخل بينما يبدو الـ worker حيًا تمامًا في لوحة التحكم.

لماذا يُظهر البول دائمًا رقمًا أقل من الماينر نفسه

إجابة مباشرة: الماينر يعرض سرعة البحث التي حسبها بنفسه، بينما يعرض البول تقديرًا يُعاد بناؤه من الـ shares المقبولة. القيمة الثانية إحصائية، لذلك تتذبذب وتكون في المتوسط أقل: جزء من العمل يذهب إلى shares مرفوضة ومتأخرة، وجزء يُفقد في تقريب نافذة المتوسط.

القاعدة العملية بسيطة. فجوة بضع نقاط مئوية تتحرك صعودًا وهبوطًا خلال اليوم هي تشتت عينة طبيعي، وليست عطلًا. الإشارة الحقيقية تبدو مختلفة: الـ hashrate البولي ينخفض ويبقى منخفضًا، بينما المحلي لا يتغير. مثل هذه الصورة تعني أن الجهاز يحسب، لكن النتيجة لا تصل إلى البول أو لا تُحتسب.

لا أحد يستطيع أن يخبرك بحجم المعدل الطبيعي لتوليفتك المحددة. اجمع أرقامك الخاصة خلال أسبوع هادئ، احسب متوسط النسبة بين الـ hashrate البولي والمحلي، واستند إليها. وينبغي فعل الشيء نفسه مع كل الحدود أدناه.

كيف تبني تنبيهًا بدون خدمات طرف ثالث

تحتاج إلى أي جهاز يعمل على مدار الساعة ويعرف كيف يقوم بطلبات HTTP: خادم منزلي صغير، أو راوتر قادر على تشغيل السكريبتات، أو لابتوب قديم. بعد ذلك مصدران للبيانات.

من جهة الماينر. واجهة الويب لجهاز ASIC توفر الـ hashrate الحالي، درجات الحرارة، دورات المراوح، الـ uptime، حالة الـ hashboards، وعدادات الرفض. في كثير من الـ firmware، تتوفر نفس البيانات بصيغة قابلة للقراءة الآلية عبر API محلي أو socket إدارة. العناوين والصيغة الدقيقة تعتمد على الشركة المصنعة وإصدار الـ firmware، راجع توثيق طرازك.

من جهة البول. بعض البولات لديها API حساب يعرض الـ hashrate الخاص بالـ workers وحالاتها، عبر مفتاح من لوحة الحساب الشخصي. التوفر والصيغة وحدود الطلبات تختلف من بول لآخر، ويجب التحقق من ذلك في توثيق كل بول على حدة: لا يوجد معيار موحد هنا، ولم نؤكد أي endpoints خارج ما هو موصوف في تقاريرنا.

منطق السكريبت يتسع في عشرة أسطر: استعلام عن الماينرز كل دقيقة، استعلام عن البول كل عدة دقائق، مقارنة القيم بالحدود، وعند حدوث مخالفة إرسال رسالة إلى تطبيق مراسلة أو بريد إلكتروني. توقّع أيضًا الحالة العكسية: إذا صمت السكريبت نفسه لأكثر من نصف ساعة، فهذا يعني أنه هو من تعطل، لا المزرعة. المراقب الصامت هو أسوأ نوع من المراقبين، لأنه يخلق شعورًا زائفًا بالسيطرة.

ما هو الحد الذي يجب وضعه لتجنب الغرق في الإنذارات الكاذبة

إجابة مباشرة: ليس بناءً على قياس واحد، بل على عدة قياسات متتالية. البحث عن الـ shares عملية عشوائية، والانخفاضات القصيرة في الرسم البياني حتمية حتى في مزرعة سليمة تمامًا. يجب أن يتطلب الحد استمرار الانحراف على عدة فترات استعلام متتالية، وإلا فستتلقى تنبيهات كل ساعة وستتوقف عن قراءتها بسرعة كبيرة.

مخطط عملي يبدو كالتالي:

1. صمت تام للماينر. الاستعلام المحلي لا يستجيب مرتين متتاليتين. هذا لم يعد تشتتًا، يجب التفاعل فورًا.
2. انخفاض الـ hashrate. قيمة أدنى من معدلك المعتاد وتبقى كذلك لعدة قياسات متتالية. مقدار الانخفاض وعدد القياسات، حددهما بناءً على تاريخك الخاص خلال أسبوع هادئ.
3. درجة الحرارة. خذ الحد من توثيق الشركة المصنعة لطرازك، واضبط التنبيه بهامش أقل من درجة تفعيل الحماية، لإتاحة وقت للتفاعل قبل الإيقاف الطارئ.
4. الـ shares المرفوضة. قارن بخلفيتك الهادئة الخاصة، لا برقم مطلق مأخوذ من الإنترنت.
5. صمت البول. مفيد، لكن تذكّر التأخير: حتى في AntPool تظهر حالة Inactive الرسمية فقط بعد 20 دقيقة. مثل هذا التنبيه سيصل دائمًا بعد التنبيه المحلي.

قاعدة أخرى: يجب أن يكون لكل تنبيه فترة هدوء بعد تفعيله. وإلا فإن عطلًا واحدًا في الساعة الثالثة فجرًا سيتحول إلى أربعين رسالة متطابقة، وفي الصباح ستقضي وقتك في ترتيب الإشعارات بدلًا من الاهتمام بالمزرعة.

قرر بشكل منفصل ماذا تفعل لحظة التفعيل. إذا لم تكن المزرعة في منزلك، فإن تنبيهًا بدون إمكانية التصرف عن بعد يتحول إلى وسيلة لإفساد ليلتك. هنا يرتبط موضوع البول الاحتياطي: بعض الأعطال ليست عطلًا في الجهاز، بل مشكلة في طرف البول أو المسار إليه، وتُحل بالتبديل التلقائي، لا بالتنقل الفعلي. عن إعداد عنوان احتياطي كتبنا بشكل منفصل.

قائمة تحقق لأمسية واحدة

1. احسب تكلفتك الخاصة لساعة واحدة من التوقف بالصيغة أعلاه. رقم واحد يجعل كل الجهد اللاحق ذا معنى.
2. اجمع خط أساس: الـ hashrate المحلي، الـ hashrate البولي، درجات الحرارة، نسبة الرفض خلال يوم هادئ.
3. تحقق مما إذا كان الـ firmware الخاص بك يوفر بيانات قابلة للقراءة الآلية، ودوّن العنوان.
4. تحقق في توثيق بولك مما إذا كانت هناك API حساب وما هي حدودها.
5. اكتب استعلامًا للماينرز كل دقيقة مع التسجيل في ملف أو قاعدة بيانات بسيطة.
6. اضبط أربعة تنبيهات: عدم استجابة، انخفاض hashrate، درجة حرارة، ارتفاع الرفض.
7. أضف فترة هدوء بعد التفعيل وحماية ضد مراقب صامت.
8. اختبر كل شيء بصدق: افصل كابل الشبكة عن جهاز واحد وقس كم من الوقت تستغرق الرسالة للوصول.
9. أدخل بولًا احتياطيًا في إعدادات الماينر، إن لم يكن ذلك قد تم بعد.
10. بعد أسبوع، راجع الحدود بناءً على البيانات المتراكمة. نادرًا ما تكون دقيقة من المرة الأولى.

النقطة الثامنة هي الأكثر إغفالًا، وهي الوحيدة التي تثبت أن النظام يعمل فعلًا.

ماذا تقرأ بعد ذلك

• حاسبة ربحية التعدين: أدخل الـ hashrate الخاص بك وشاهد كم تكلفك يوم واحد من التوقف شخصيًا.
• البول متوقف: كيف تعرف أن المشكلة ليست في مزرعتك: كيف تميّز بين مشكلة من جانبك ومشكلة من جانب البول.
• البول الاحتياطي: لماذا تسجّل عنوانًا ثانيًا: التبديل التلقائي عند حدوث عطل بدون تدخل منك.
• مقارنة بولات التعدين: العمولات، أنظمة الدفع، وحدود السحب.

المراقبة لا تزيد الدخل. هي فقط تمنعك من خسارة ما كسبته بالفعل، وفي التعدين يكون الفرق بين هذين الأمرين ضئيلًا للغاية.