البنية الداخلية PmaControl: المكنسة الكهربائية والمستمع وDot3 و162 طاولة

162 جدولًا، وليس جدولًا واحدًا كثيرًا

PmaControl ليست لوحة تحكم بسيطة. إنه نظام موزع يقوم بجمع وتخزين وتحويل وكشف المقاييس من مئات خوادم MariaDB / MySQL في الوقت الفعلي. تحتوي قاعدة البيانات الداخلية على 162 جدولًا — لكل منها دور محدد في مسار البيانات.

توضح هذه المقالة بالتفصيل البنية الداخلية: المكونات الأربعة الرئيسية (الفراغ، المستمع، Dot3، المخطط)، وتدفق البيانات من طرف إلى طرف، والكرونات التي تنظم كل شيء، والجداول الرئيسية التي يجب معرفتها لتصحيح أخطاء النظام أو توسيعه.

الركائز الأربع

المكنسة الكهربائية: جامع البيانات

المكنسة الكهربائية هي المكون الذي يجلب المقاييس من كل خادم خاضع للإشراف. عملها بسيط ولكنه فعال:

1. يتصل بالخادم عبر SSH (نفق) ثم يفتح اتصال MySQL محلي
2. ينفذ سلسلة من الاستعلامات: SHOW GLOBAL STATUS، SHOW GLOBAL VARIABLES، SHOW SLAVE STATUS، SHOW PROCESSLIST، استعلامات على performance_schema، إلخ.
3. يكتب النتائج في جداول ts_value_* (السلاسل الزمنية) لقاعدة البيانات PmaControl

البادئة ts_ موجودة في كل مكان: وتعني السلسلة الزمنية. يتم وضع طابع زمني على كل مقياس ويتم تخزينه باستخدام معرف الخادم المصدر.

Aspirateur → SSH tunnel → MySQL local
           → SHOW GLOBAL STATUS
           → SHOW SLAVE STATUS
           → performance_schema queries
           → INSERT INTO ts_value_general_int (...)
           → INSERT INTO ts_value_general_json (...)

المكنسة الكهربائية لا تقوم بـ لا معالجة. يجمع ويكتب. إنه مبدأ تصميم أساسي: فصل المجموعة عن المعالجة حتى تتمكن من توسيع نطاقها بشكل مستقل.

المستمع: محرك ما بعد المعالجة

المستمع هو عقل PmaControl. فهو يراقب جداول السلاسل الزمنية ويطلق الإجراءات عند وصول بيانات جديدة. ترتكز آليتها على طاولة محورية: listener_main.

يحتوي الجدول listener_main على:

حلقات المستمع باستمرار. في كل تكرار، يقوم بمقارنة ts_max_date المسجل مع أحدث طابع زمني في جداول ts_value_*. إذا تم اكتشاف اختلاف، فهذا يعني أن الفراغ قد كتب بيانات جديدة - ثم يقوم المستمع بتشغيل سلسلة ما بعد المعالجة:

Listener loop:
  1. Check ts_max_date vs actual max(timestamp)
  2. If changed → trigger pipeline:
     a. updateDatabase()      — met à jour les métadonnées serveur
     b. afterUpdateVariable() — déclenche les règles conditionnelles
     c. Digest::integrate()   — agrège les métriques performance_schema
     d. Alias::updateAlias()  — rafraîchit les alias DNS

updateDatabase() يقوم بمزامنة المعلومات الأساسية: إصدار الخادم، وحالة النسخ المتماثل، وحجم قاعدة البيانات، وعدد الاتصالات النشطة.

afterUpdateVariable() هو محرك القواعد. يقوم بمقارنة القيم الجديدة مع الحدود التي تم تكوينها ويقوم بإنشاء تنبيهات إذا لزم الأمر. على سبيل المثال، إذا تجاوز Seconds_Behind_Master 60، يتم إنشاء تنبيه تحذيري.

Digest::integrate() يعالج البيانات من performance_schema. فهو يجمع إحصائيات الاستعلام (وقت التنفيذ، والصفوف التي تم فحصها، والتكرار) ويخزنها في جداول الملخص PmaControl. هذا هو ما يدعم لوحات معلومات الأداء.

Alias::updateAlias() يحتفظ بالجدول alias_dns، الذي يربط الأسماء المألوفة بعناوين IP الحقيقية. يعد هذا الجدول واحدًا من أكبر الجداول: 1.1 مليون صف، و85 ميجابايت من البيانات. يتم استخدام الأسماء المستعارة في جميع أنحاء الواجهة لعرض الأسماء القابلة للقراءة بدلاً من عناوين IP.

Dot3: طوبولوجيا الوقت الحقيقي

Dot3 هو مكون تعيين الطوبولوجيا. يقوم بتحليل علاقات النسخ المتماثل بين الخوادم ويقوم بإنشاء رسم بياني موجه بتنسيق DOT (Graphviz).

العملية:

1. يقرأ Dot3 بيانات تعريف النسخ المتماثل لكل خادم (رئيسي/تابع، GTID، قناة)
2. يقوم بإنشاء رسم بياني للتبعية: من هو سيد من ومن هو عبد من
3. يقوم بإنشاء تمثيل مرئي بالمجموعات (مجموعات من الخوادم المرتبطة)

الجداول المعنية:

• dot3_graph: الرسم البياني الكامل بتنسيق DOT، جاهز للعرض
• dot3_cluster: مجموعات الخادم (الكتلة = مجموعة النسخ المتماثل)

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

المخطط: تصدير الهيكل

يقوم مكون المخطط بتصدير البنية الكاملة لكل قاعدة بيانات يتم مراقبتها. لكل خادم، يقوم بإنشاء شجرة ملفات:

data/model/<server_id>/databases/<db_name>/
├── schema/
│   └── tables/
│       ├── users.sql
│       ├── orders.sql
│       └── ...
├── routines/
│   ├── calculate_total.sql
│   └── ...
├── events/
│   ├── daily_cleanup.sql
│   └── ...
└── triggers/
    ├── before_insert_users.sql
    └── ...

يحتوي كل ملف على CREATE TABLE أو CREATE PROCEDURE أو CREATE EVENT أو CREATE TRIGGER المطابق. وهذا يسمح:

• لإصدار البنية في Git (الفرق بين تصديرين)
• لمقارنة الهيكل بين الإنتاج والتدريج
• للكشف عن انحراف المخطط (فهرس تمت إضافته يدويًا في الإنتاج، عمود تم تعديله بدون ترحيل)

الدبقية CLI

تم بناء PmaControl على إطار عمل Glial، الذي يوفر واجهة سطر أوامر موحدة:

./glial <controller> <action> [params]

أمثلة ملموسة:

# Vérifier l'état des démons
./glial agent check_daemon

# Forcer un cycle de collecte
./glial control service

# Exporter le schéma d'un serveur
./glial schema export 42

# Régénérer la topologie
./glial dot3 generate

يتم استخدام واجهة سطر الأوامر (CLI) يدويًا (تصحيح الأخطاء والصيانة) وعن طريق crons للتنسيق التلقائي.

الكرونز: التزامن

ثلاثة كرونات أساسية تعمل PmaControl:

1. ./glial agent check_daemon — كل دقيقة

هذا هو كرون الأكثر شيوعا. فهو يتحقق من أن جميع عمليات الوكيل نشطة ويعيد تشغيلها إذا لزم الأمر. العامل الميت يعني ثغرة في البيانات، ويضمن هذا cron استمرارية التجميع.

crontab
* * * * * cd /srv/www/pmacontrol && ./glial agent check_daemon >> /tmp/pmacontrol_agent.log 2>&1

إذا لم يستجب الوكيل بعد 3 محاولات، فسيتم إرسال تنبيه Telegram.

2. ./glial control service — كل 4 ساعات

يقوم هذا cron بمهام الصيانة الثقيلة:

• إعادة حساب المجاميع اليومية
• تنظيف البيانات منتهية الصلاحية (الاحتفاظ شكلي)
• تجديد طوبولوجيا Dot3
• مزامنة البيانات التعريفية للخادم
• التحقق من الاتساق بين الجداول

تعتبر أربع ساعات بمثابة حل وسط جيد بين الحداثة والحمل: هذه العمليات باهظة الثمن ولا تحتاج إلى أن تتم في الوقت الفعلي.

crontab
0 */4 * * * cd /srv/www/pmacontrol && ./glial control service >> /tmp/pmacontrol_control.log 2>&1

3. ./monitor_mysql.sh — كل دقيقة

هذا البرنامج النصي هو نقطة الدخول إلى المكنسة الكهربائية. يطلق دورة جمع كاملة:

crontab
* * * * * cd /srv/www/pmacontrol && ./monitor_mysql.sh >> /tmp/pmacontrol_monitor.log 2>&1

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

الجداول الرئيسية

فيما يلي أهم الجداول التي يجب معرفتها لفهم PmaControl أو تصحيح الأخطاء فيها:

mysql_server

الطاولة المركزية. يمثل كل سطر مثيلًا خاضعًا للإشراف — ليس فقط خوادم MariaDB / MySQL، ولكن أيضًا:

• خوادم MariaDB / MySQL (الحالة الرئيسية)
• الوكلاء: MaxScale، ProxySQL، HAProxy
• VIP (IP الافتراضي)

يميز العمودان is_proxy وis_vip بين الأنواع:

-- Serveurs MariaDB / MySQL uniquement
SELECT id, ip, port, name, display_name, id_environment
FROM mysql_server
WHERE is_deleted = 0 AND is_proxy = 0 AND is_vip = 0;

-- Proxies (MaxScale, ProxySQL, HAProxy)
SELECT id, ip, port, name, display_name
FROM mysql_server
WHERE is_deleted = 0 AND is_proxy = 1;

-- VIPs
SELECT id, ip, port, name, display_name
FROM mysql_server
WHERE is_deleted = 0 AND is_vip = 1;

يتم تخزين الوكلاء وكبار الشخصيات في نفس الجدول مثل خوادم MySQL لتبسيط عمليات الانضمام والهيكل. يستخدمها Dot3 لرسم الاتصالات بين طبقات الشبكة (VIP → Proxy → Master → Slave). يتم حساب العمود timeout ديناميكيًا: 11 ثانية للخوادم الوكيلة (التي تستجيب بشكل أبطأ لعمليات التحقق)، وثانية واحدة للخوادم الكلاسيكية.

تكمل الجداول المخصصة التفاصيل الخاصة بكل نوع من أنواع الوكيل:

• maxscale_server / maxscale_server__mysql_server — التكوين MaxScale وواجهاته الخلفية
• proxysql_server — التكوين ProxySQL
• haproxy_main / haproxy_main_input / haproxy_main_output / link__haproxy_main_output__mysql_server — تكوين HAProxy (المستمعون، الواجهات الأمامية، الواجهات الخلفية)
• vip_server — تفاصيل VIP

ts_variable

قاموس المقاييس. يحتوي كل متغير تم جمعه (على سبيل المثال Threads_connected، Innodb_buffer_pool_pages_data) على إدخال في هذا الجدول بمعرفه الرقمي.

SELECT id, name, source
FROM ts_variable
WHERE name LIKE 'Innodb%';

ts_value_general_int

التخزين الأساسي للمقاييس الرقمية. هذا هو أكبر جدول — فهو يتلقى آلاف الإدخالات في الثانية، ويمكن أن يصل إلى عدة مليارات من الصفوف يوميًا في أكبر عمليات تثبيت PmaControl.

SELECT server_id, variable_id, value, timestamp
FROM ts_value_general_int
WHERE server_id = 42
  AND variable_id = 107  -- Threads_connected
  AND timestamp > NOW() - INTERVAL 1 HOUR;

تم تقسيم هذا الجدول حسب اليوم للسماح بالتنظيف السريع للبيانات القديمة (ALTER TABLE ... DROP PARTITION).

ts_value_general_json

بالنسبة للمقاييس المعقدة التي لا تتناسب مع عدد صحيح: النتائج من SHOW PROCESSLIST، والجداول من performance_schema (ملخص الاستعلام، والأقفال، وجدول الإدخال/الإخراج)، SHOW ENGINE INNODB STATUS، وما إلى ذلك. يسمح تنسيق JSON بتخزين بنيات عشوائية. تحتوي مقاييس النسخ المتماثل (SHOW SLAVE STATUS) على جداول مخصصة لها (ts_value_slave_*).

alias_dns

جدول الأسماء المستعارة لنظام أسماء النطاقات — 1.1 مليون صف، 85 ميجابايت. يقوم بتعيين عناوين IP لأسماء يمكن قراءتها بواسطة الإنسان ويتم استخدامها في جميع أنحاء الواجهة.

SELECT ip, alias, source, updated_at
FROM alias_dns
WHERE ip = '10.0.1.42';

dot3_graph و dot3_cluster

جداول الطوبولوجيا يحتوي dot3_graph على الرسم البياني DOT الكامل، وdot3_cluster المجموعات المنطقية للخوادم.

تدفق البيانات الكامل

دعونا نلخص رحلة المقياس، من المصدر إلى الشاشة:

التحجيم

بالنسبة للنشر النموذجي لـ 100 خادم MariaDB / MySQL:

• الأساس PmaControl: حوالي 15 غيغابايت من البيانات (تهيمن عليها جداول ts_value_*)
• وحدة المعالجة المركزية: 2-4 مراكز كافية (المستمع هو الأكثر تطلبًا)
• ذاكرة الوصول العشوائي: 4 جيجابايت كحد أدنى، ويوصى بـ 8 جيجابايت (للمخزن المؤقت لقاعدة PmaControl نفسها)
• القرص: SSD مطلوب — تتسبب جداول السلاسل الزمنية في الكثير من عمليات الإدخال/الإخراج العشوائية

محرك التخزين الموصى به لجداول ts_value_* هو RocksDB (عبر MyRocks): ضغط أفضل، وأداء كتابة تسلسلي أفضل، وتقسيم أصلي يوميًا.

التصحيح

عندما لا يعمل شيء ما، إليك قائمة التحقق:

1. هل يتناوب الوكلاء؟ ./glial agent check_daemon — إذا توفي الوكيل، فلن يتم جمع البيانات للخوادم التي يديرها
2. هل يدور المستمع؟ حدد ts_max_date في listener_main — إذا توقف عن الحركة، فهذا يعني أن المستمع عالق
3. هل تعمل crons؟ تحقق من /tmp/pmacontrol_*.log بحثًا عن الأخطاء
4. هل اتصال SSH جيد؟ اختبر ssh -p <port> <user>@<host> يدويًا باستخدام المفتاح الذي تم تكوينه
5. هل قاعدة البيانات PmaControl سليمة؟ تحقق من مساحة القرص والأقفال والاستعلامات البطيئة في قاعدة البيانات PmaControl نفسها

الخلاصة

تتبع بنية PmaControl نموذج ETL (الاستخراج والتحويل والتحميل) الكلاسيكي الذي تم تكييفه للمراقبة:

• استخراج: تجمع المكنسة الكهربائية دون تحويل
• التحويل: يطبق المستمع القواعد والمجاميع
• تحميل: تقوم لوحات المعلومات بقراءة البيانات المحولة

الجداول الـ 162 ليست مجرد صدفة من التعقيد - فهي تعكس ثروة البيانات التي تم جمعها على كل خادم MariaDB / MySQL. يعد فهم هذه البنية أمرًا ضروريًا لأي شخص يريد تصحيح مشكلة مجموعة، أو توسيع PmaControl بنوع جديد من المقاييس، أو تحسين أداء نظام المراقبة نفسه.