يفوتر PRTG لكل مستشعر، أي مقياس واحد مراقَب على جهاز واحد، وليس الجهاز نفسه. تحدد فئات Paessler نفسها النسبة العملية بنحو عشرة إلى واحد: 500 مستشعر تغطي نحو 50 جهازًا، و10,000 تغطي نحو 1,000. أضف مجموعة محولات وابدأ بمراقبة الإنتاجية لكل منفذ، فيتحرك العداد أسرع من نمو البنية. يحسب SolarWinds بطريقة مختلفة ويصل إلى النتيجة نفسها.
لشبكة يغلب عليها Windows، سأرشح بديلين مستضافين ذاتيًا لـ PRTG وSolarWinds: Zabbix، أو حزمة قائمة على Prometheus إذا كان فريقك يشغّل واحدة بالفعل. يتوقف الاختيار بينهما على ما يستطيع كل منهما رؤيته على مضيف Windows، وما يحتاجه لرؤيته.
تحفّظ واحد قبل كل شيء. إذا لم يكن لدى أحد في الفريق ساعات فائضة، يبقى PRTG وSolarWinds هما الإجابة الصحيحة. سهولة استخدامهما منتج تشتريه عن قصد، وهو يستحق ثمنه. التحول الموصوف هنا ينفق ساعات بدل رسوم الترخيص، وهذه مقايضة وليست ترقية.
الخلاصة السريعة
- الخيار الافتراضي هو Zabbix. يجمع Zabbix استطلاع SNMP ووكلاء Windows والقوالب والتنبيهات داخل منصة مراقبة واحدة. ما زلت تشغّل خادم Zabbix وقاعدة البيانات والواجهة الأمامية على الويب، لكنك لا تجمّع مكونات مراقبة منفصلة لمجرد البدء.
- الاستثناء هو فريق يشغّل Grafana وPrometheus بالفعل لمقاييس التطبيقات والمضيفين. توسيع ما تصونه بالفعل أرخص من إنشاء نظام مراقبة ثانٍ.
- لا يستطلع Prometheus أجهزة الشبكة بنفسه.
snmp_exporterيسد تلك الفجوة؛ يغطي تكوينه الافتراضي كثيرًا من المحولات والموجهات الشائعة، بينما قد تتطلب الكائنات الخاصة بالمورّد أو الاستطلاع المخصص المولّد وعملًا إضافيًا على ملفات MIB. - لا يرى الجمع بلا وكيل سوى ما يختار المضيف أو الجهاز نشره. في Zabbix، سجلات أحداث Windows وحالة الخدمات وعدادات الأداء التفصيلية هي مفاتيح عناصر خاصة بالوكيل.
- حدد حجم الخادم بالمقاييس، لا بالأجهزة. يحسب Zabbix المقياس الواحد على أنه عنصر واحد زائد مشغّل واحد زائد رسم بياني واحد، ويضع نحو 1,000 مقياس على نواتي CPU و8 GiB من الذاكرة، ونحو 10,000 على 4 أنوية و16 GiB.
ما الذي يتقاضى PRTG وSolarWinds المال مقابله
Paessler publishes its PRTG tiers publicly, priced by sensor count and billed annually, starting from a few hundred dollars a month as of September 2026. Check the current figures yourself before budgeting. There is no perpetual-licence option in the current lineup. The freeware edition stops at 100 sensors, which Paessler describes as roughly 10 devices.
يحسب SolarWinds وحدة مختلفة، والقاعدة يسهل إغفالها حتى يصل عرض التجديد. نموذج ترخيص NPM من SolarWinds ينص على أن NPM "يُرخَّص وفق أكبر عدد من أنواع عناصر الشبكة المراقَبة التالية: العُقد، الواجهات، وحدات التخزين". ليس المجموع. بل الأكبر بين الثلاثة. شبكة فيها 80 عقدة و900 منفذ محول مراقَب تُرخَّص على 900 لا على 80، والفئات تمتد من SL100 إلى SLX. يتوقف محرك الاستطلاع الواحد عند 12,000 عنصر (مجموع العقد والواجهات ووحدات التخزين، لا الأكبر بينها) بغض النظر عن الفئة، وبعدها تضيف محرك استطلاع مرخصًا آخر.
الأثر العملي للنموذجين واحد. فئة الترخيص هي التي تقرر ما يُراقَب. لا الشبكة. تبقى الواجهات التي تود مراقبتها بلا مراقبة لأن مراقبتها تتجاوز حدًا، وهذه التكلفة لا تظهر أبدًا في الفاتورة.
المساران المستضافان ذاتيًا اللذان يستحقان التشغيل
Zabbix منصة مراقبة واحدة مبنية حول خادم مركزي وقاعدة بيانات وواجهة ويب. يستطلع الخادم أجهزة SNMP، ويتلقى البيانات من وكلاء Windows، ويطبق القوالب والمشغّلات والتنبيهات داخل المنتج نفسه. مقارنةً بتجميع حزمة مراقبة شبكات قائمة على Prometheus، هناك مكونات منفصلة أقل عليك دمجها بنفسك. تثبّته، وتوجّهه إلى المضيفين، وتُرفق القوالب، وهي حزم قابلة لإعادة الاستخدام من العناصر والمشغّلات والرسوم البيانية تغطي فئة واحدة من الأجهزة.
ابدأ بالترخيص. صفحة ترخيص Zabbix تنص على أن كل إصدار بدءًا من 7.0 يصدر بموجب رخصة GNU Affero العمومية الإصدار 3، وأن كل ما سبق حتى 6.4 كان بموجب GPLv2. لا توجد رسوم ترخيص للبرنامج على أي نطاق. يبيع Zabbix الدعم الفني كاشتراك اختياري منفصل، ويطلب من المستخدمين التجاريين شراء مستوى ما منه، لكن لا شيء في المنتج محجوز خلف ذلك الشراء.
المسار الثاني هو Grafana وPrometheus وVictoriaMetrics. إنه الخيار الصحيح في حالة واحدة بالضبط: أنك تشغّل هذه الحزمة بالفعل لمقاييس التطبيقات والمضيفين، وأن أحدهم يصونها بالفعل. إذا كان هذا ينطبق عليك، فإن البناء الكامل على خادم VPS واحد مشكلة محلولة، وأنت توسّع شيئًا مألوفًا. لا أحد مضطر لتعلم نموذج بيانات جديد.
الفجوة في هذا المسار هي أجهزة الشبكة. يجمع Prometheus من نقاط نهاية HTTP؛ ولا يتحدث SNMP مباشرة. تُعالَج معدات الشبكة عادةً عبر snmp_exporter، الذي يستطلع الجهاز ويعرض النتائج ليجمعها Prometheus. يتضمن تكوينه الافتراضي وحدات مثل if_mib، لذا لا تتطلب مراقبة الواجهات القياسية على كثير من المحولات والموجهات توليد تكوين مخصص. يصبح المولّد عملًا إضافيًا عندما تحتاج إلى كائنات خاصة بالمورّد أو عمليات مسح مخصصة أو ملفات MIB غير مضمّنة افتراضيًا. لذلك يحتوي مسار Prometheus على أجزاء أكثر تحتاج إلى صيانة مقارنةً بـ Zabbix، لكن المولّد ليس إلزاميًا لكل جهاز.
LibreNMS هو الاسم الثالث في هذا المجال، وهو مبني حول الاكتشاف التلقائي: يمسح الشبكة عبر SNMP وCDP وLLDP وOSPF وBGP وARP ليجد ما فيها. إنه خيار معقول عندما يكون الاكتشاف هو الأولوية. لكنه لا يغيّر مسألة الجمع من Windows، وهناك بالضبط يُحسم هذا القرار.
كيف يرى كل مسار مضيف Windows
يمكن أن تتضمن مراقبة Windows بروتوكول SNMP أو WMI عن بُعد أو وكيلًا مثبّتًا. يعتمد المسار المطبّق على منتج المراقبة والمقياس الذي يُجمع. في Zabbix تحديدًا، تعمل فحوصات WMI المدمجة عبر وكيل Windows.
SNMP
يطلب استطلاع SNMP من الجهاز القيمة الحالية لكائن مرقّم، يُعنون بمعرّف OID، وهو موضع في ملف MIB الخاص بالجهاز. ما يعود هو ما ينشره الجهاز ولا شيء غيره. على محول مُدار أو جدار حماية أو وحدة UPS، يكفي ذلك عادةً: عدادات الواجهات، حالة المنافذ، معدلات الأخطاء، درجة الحرارة، صحة الهيكل.
على Windows الصورة أضعف. إشعار Microsoft بإهمال SNMP وموفّر WMI SNMP يؤكد أن الميزتين مهملتان، لذا سأتعامل مع SNMP في Windows كمسار توافق قديم لا كخيار افتراضي لنشر جديد. ما زال Zabbix يوفر قالب Windows by SNMP، لكن الوكيل الأصلي يمنحك رؤية أعمق بكثير داخل نظام التشغيل.
WMI
يمكن الاستعلام عن WMI عن بُعد دون تثبيت وكيل مراقبة على الهدف، ولهذا تستطيع منتجات مثل PRTG استخدامه كطريقة جمع بلا وكيل من Windows. يعمل Zabbix بطريقة مختلفة. فحوصات WMI المدمجة فيه, wmi.get و wmi.getall، هي مفاتيح عناصر خاصة بوكيل Windows، ولذلك ينفّذ وكيل Zabbix أو الوكيل 2 تلك الاستعلامات على الجهاز المراقَب.
يجلب WMI عن بُعد أيضًا متطلبات شبكة خاصة به عندما يستخدمه منتج مراقبة مباشرة. في أنظمة Windows الحالية، يبدأ RPC على منفذ TCP 135 ويتفاوض عادةً على الاتصالات عبر نطاق منافذ TCP العليا الديناميكي، عادةً من 49152 إلى 65535. يجب أن يسمح جدار الحماية وأذونات WMI على الهدف بالاتصال.
في هذه المقارنة، التمييز أهم من البروتوكول نفسه: يستطيع PRTG استخدام WMI عن بُعد دون وكيل مراقبة مثبّت، بينما يحصل Zabbix على رؤيته الخاصة بـ WMI في Windows عبر وكيله.
الوكيل الأصلي
الوكيل هو موضع العمق الخاص بـ Windows. يسرد توثيق Zabbix المفاتيح الخاصة بـ Windows: eventlog لمراقبة سجل أحداث Windows، perf_counter لأي عداد أداء في Windows، service.discovery و service.info لحالة الخدمات. وكلها مفاتيح عناصر خاصة بالوكيل.
التكلفة هي النشر. وكيل على كل خادم Windows Server وكل محطة عمل تهمك يعني حزمة يجب دفعها، وإصدارًا يجب إبقاؤه محدّثًا، وقاعدة جدار حماية يجب صيانتها. هذا التزام تشغيلي دائم، وهو الثقل الموازن لتوفير الترخيص.
الجمع بلا وكيل محدود بما يختار المضيف أو الجهاز نشره، وفي Zabbix تقع سجلات الأحداث وعدادات الأداء التفصيلية خلف مفاتيح عناصر خاصة بالوكيل.
جنبًا إلى جنب
تدور المقارنة حول أربعة أمور: هل تستطلع الأداة أجهزة الشبكة عبر SNMP أصلًا، وهل لديها وكيل Windows، وإلى أي عمق ترى داخل مضيف Windows، وكم من التجميع يفصل بينك وبين نظام يعمل. يقف الترخيص إلى جانب ذلك لأنه سبب بدء التقييم.
| الأداة | استطلاع أجهزة SNMP | مراقبة Windows | جهد الإعداد | الترخيص |
|---|---|---|---|---|
| Zabbix | مدمج | وكيل: سجلات الأحداث وحالة الخدمات وعدادات الأداء وWMI؛ حالة عامة عبر SNMP | متوسط: خادم واحد، ثم القوالب | AGPLv3، بلا رسوم ترخيص؛ الدعم يُباع منفصلًا |
Grafana + Prometheus + VictoriaMetrics (+ snmp_exporter) | غير مدمج؛ يحتاج snmp_exporter كمكوّن منفصل | لا وكيل Windows أصلي؛ مقاييس المضيفين تأتي من مصدّرات منفصلة؛ سجلات الأحداث ليست أصلية | عالٍ: مكونات متعددة؛ قد يتطلب SNMP المخصص عملًا على المولّد | مكونات مفتوحة المصدر، بلا رسوم ترخيص |
| أدوات مراقبة وقت التشغيل والحالة | لا شيء | إمكانية الوصول إلى الخدمات وزمن الاستجابة فقط | منخفض: دقائق | يختلف حسب الأداة |
إذا كان المطلب "أخبرني خلال دقيقة عندما تتوقف خدمة عن الاستجابة"، فإن أداة مراقبة وقت التشغيل هي الأداة ذات الحجم المناسب، والأداتان الأخريان مبالغ فيهما لذلك. ما لن تفعله هو استطلاع محول لمعرفة إنتاجية الواجهة أو قراءة عداد أداء في Windows، لذا فهي ليست بديلًا لـ PRTG أو SolarWinds. إنها مهمة مختلفة يُخلط بينها أحيانًا وبين المهمة نفسها.
أيهما تشغّل
شغّل Zabbix. لشبكة يغلب عليها Windows دون استثمار قائم في Prometheus، هو المسار الأقصر بفارق كبير. ما زال لديك خادم وقاعدة بيانات وواجهة ويب لتشغيلها، لكن نموذج المراقبة والقوالب والتنبيهات تعيش داخل منتج واحد بدل تجميعها من عدة مكونات مراقبة.
لنشر مراقبة طويل العمر، استخدم فرع LTS الحالي من Zabbix بدل إصدار قياسي قصير الأجل. تمنح دورة حياة LTS في Zabbix كل إصدار ثلاث سنوات من الدعم الكامل تليها سنتان من الدعم المحدود، وهذا أهم هنا من ملاحقة أحدث إصدار بميزات جديدة.
الاستثناء ضيق ومحدد. إذا كان فريقك يشغّل Grafana وPrometheus في الإنتاج بالفعل لمقاييس التطبيقات والمضيفين، وكان لتلك الحزمة مالك بالفعل، فإن snmp_exporter يكون إضافة إلى شيء مُصان وليس نظامًا ثانيًا يحتاج إلى صيانة. هذا الشرط مركّب: يجب أن يتحقق نصفاه معًا. نسخة Grafana مهجورة أعدّها شخص العام الماضي لا تُحتسب.
وإذا لم يكن لدى أحد الساعات، فجدّد. هذا ليس تحوّطًا. إنه وضع مختلف بإجابة صحيحة مختلفة. يحوّل التحول فاتورة الترخيص إلى فاتورة تشغيلية: نشر الوكلاء، والعمل على القوالب، والترقيات، وشخص يفهم النظام جيدًا بما يكفي لإصلاحه في الثانية فجرًا. الفريق الذي بلغ طاقته القصوى سيؤدي هذا العمل بشكل سيئ أو لن يؤديه أصلًا، والمراقبة غير المصانة أسوأ من المراقبة الباهظة لأنها تفشل بصمت.
الحل الهجين حقيقي: أبقِ المنتج الحالي على نواة متقلصة من الأنظمة الحرجة، وانقل كل شيء آخر إلى Zabbix، ودع فئة الترخيص تنخفض مع الوقت. إنه يعمل. لكنه يعني أيضًا تشغيل نظامي مراقبة والتوفيق بين تنبيهاتهما، لذا تعامل معه كحالة انتقالية لها تاريخ انتهاء.
ما الذي لا ينجو من الانتقال
دليل الترحيل الخاص بـ Zabbix نفسه يحتوي على قسم بعنوان "ما لا يُرحَّل"، والقائمة أطول مما توحي به كلمة "ترحيل". البيانات التاريخية وقراءات المستشعرات لا تنتقل. إشعارات PRTG المخصصة والتبعيات لا تنتقل. الخرائط ولوحات المعلومات لا تنتقل، لأن المنتجين ينمذجانها بشكل مختلف بما يكفي لأن تكون إعادة البناء أفضل من الترجمة. المستشعرات نفسها لا تنتقل، لأن Zabbix يعمل بمفهوم مختلف تمامًا.
يمكن نقل أسماء الأجهزة وعناوين IP وأنواع الواجهات. وحتى هذا يمر عبر برمجة تصدير واستيراد مخصصة على واجهتي API. يذكر الدليل صراحةً أنه لا توجد أداة رسمية للترحيل مباشرةً بين المنصتين.
وثّق فريق واحد ما يكلفه ذلك عمليًا: نحو 500 جهاز افتراضي وخادم فعلي، ونحو سبع سنوات على PRTG، أُعيد بناؤها من الصفر على مدى ستة أشهر من وقت مشروع منخفض الأولوية. تحولت مستشعرات PRTG البالغ عددها 2,500 إلى 43,000 عنصر في Zabbix، وهو ما يوضح بجلاء مدى اختلاف طريقة العدّ بين النظامين.
"ابدأ من الصفر. لا يوجد خيار 'اضغط هذا الزر ورحّل' من PRTG إلى Zabbix، وحتى لو وُجد، فإن أمرًا كهذا فرصة جيدة لعدم تكرار أخطاء التصميم السابقة."
هذه تجربة منظمة واحدة، لا معيار. البنية الأصغر لن تنتج تلك الأرقام. ما ينتقل هو افتراض التخطيط: خصص وقتًا لإعادة البناء، لا وقتًا للترحيل.
رتّب إعادة البناء وفق ما لا تستطيع الاستغناء عنه. إذا كان همّك استمرارية التنبيهات، فأعد بناء قواعد الإشعارات أولًا ودع لوحات المعلومات تتأخر. وإذا كان سجل التقارير، فصدّر ما تحتاجه قبل انتهاء الترخيص القديم. لن يأتي معك.
تحديد حجم الخادم
متطلبات Zabbix من العتاد تضع التثبيت الصغير بنحو 1,000 مقياس مراقَب على نواتي CPU و8 GiB من الذاكرة، والتثبيت المتوسط بنحو 10,000 مقياس على 4 أنوية و16 GiB. هذه هي الأرقام التي تطلب على أساسها.
الوحدة هي حيث يخطئ تحديد الحجم. يعرّف Zabbix المقياس المراقَب الواحد بأنه عنصر واحد زائد مشغّل واحد زائد رسم بياني واحد. المقياس ليس جهازًا وليس مضيفًا. يسهم خادم Windows Server واحد بعدد من المقاييس يساوي عدد العناصر التي تكوّنها له: CPU، الذاكرة، كل نظام ملفات، كل خدمة، كل عداد تأخذ عينات منه. عدد الأجهزة دليل ضعيف على الجهاز الذي تحتاجه. قد تقع بنية تبدو صغيرة في الفئة المتوسطة دون أن يفعل أحد شيئًا غير معتاد.
أمران يرفعان الرقم أسرع من عدد المضيفين. الأول تكرار الاستطلاع: تقليص فاصل التحديث إلى النصف يضاعف معدل الكتابة لكل عنصر على ذلك الفاصل. الثاني الاحتفاظ بالسجل، إذ تنمو قاعدة البيانات بقدر مدة احتفاظك بالقيم الخام. عدد الأجهزة يهم أساسًا من خلال عدد العناصر المراقَبة التي يسهم بها كل جهاز.
إذا بقيت بنيتك قريبة من مثال الـ 1,000 مقياس بفواصل تحديث عادية واحتفاظ متواضع، فالفئة الصغيرة نقطة انطلاق معقولة. أما إذا كنت تأخذ عينات من عدادات الأداء كل ثلاثين ثانية وتحتفظ بسنة من السجل الخام، فلا. يوضح Zabbix صراحةً أن أرقامه المنشورة هي "أمثلة على الحجم وتكوين العتاد للبدء بها"، ويوصي بقياس الأداء في بيئة تجريبية قبل الالتزام بعتاد الإنتاج. هذا تحفّظ المورّد نفسه. خذه حرفيًا.
يدعم Zabbix مكوّن الخادم على Linux وUNIX فقط؛ وعلى Windows يُدعم الوكيل فقط.
المقاييس ليست أجهزة، والمضاعِف بينهما هو ما يحدد حجم الجهاز.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxأين تضع خادم المراقبة
إذا كنت تحتاج إلى أن تنجو المراقبة من انقطاع يشمل الموقع كله، فأبقِ خادم Zabbix المركزي خارج نطاق فشل الموقع. عندها يمكن لفقدان وصلة الموقع أن يُخرج الشبكة المراقَبة عن الخدمة دون أن يسقط خادم المراقبة معها.
في شبكة خاصة، يمكن لـ وكيل Zabbix أن يقع داخل الموقع ويجمع من الأنظمة المحيطة به. يستطيع الوكيل معالجة فحوصات SNMP والوكلاء محليًا، وإرسال البيانات المجمّعة إلى الخادم المركزي، وتخزين بيانات المراقبة مؤقتًا أثناء انقطاع الاتصال بينهما. يتيح ذلك بقاء الخادم المركزي خارج الموقع دون أن يكون كل محول وجدار حماية ومضيف Windows خاص قابلًا للوصول مباشرةً من الإنترنت.
خادم VPS مكان عملي لتشغيل ذلك الخادم المركزي. تقدم Cloudzy خادم Zabbix كنشر بنقرة واحدة على Ubuntu Server 24.04 LTS إذا أردت تخطي التثبيت الأولي والانتقال مباشرةً إلى تكوين المضيفين والقوالب.
الأسئلة الشائعة
هل Zabbix مجاني فعلًا؟
نعم. يصدر Zabbix بموجب رخصة GNU Affero العمومية الإصدار 3 بدءًا من الإصدار 7.0، ولا توجد رسوم ترخيص للبرنامج مهما كان عدد الأجهزة أو المقاييس التي تراقبها. يبيع Zabbix الدعم الفني كاشتراك اختياري منفصل، لكن لا ميزة في المنتج محجوزة خلفه. تكلفة تشغيل Zabbix هي الخادم الذي يعمل عليه والساعات التي تقضيها في تشغيله.
هل أحتاج إلى تثبيت وكيل على كل خادم Windows Server؟
ليس على كل جهاز Windows، لكن إذا أردت عمق مراقبة Windows الأصلي في Zabbix، فخطط لتثبيت الوكيل على الخوادم التي تهمك أكثر. يمكن لـ SNMP توفير بيانات عامة بلا وكيل، رغم أن ميزة SNMP في Windows مهملة لدى Microsoft. تعمل فحوصات WMI المدمجة في Zabbix أيضًا عبر وكيل Windows، لذا فإن WMI ليس مسار جمع مباشرًا بلا وكيل في Zabbix. استخدم الوكيل لسجلات الأحداث واكتشاف الخدمات واستعلامات WMI وعدادات الأداء التفصيلية؛ واحتفظ بـ SNMP بلا وكيل أساسًا لمعدات الشبكة وحالات Windows القديمة.
هل يمكنني تشغيل خادم المراقبة على Windows؟
ليس مع Zabbix. توثيق متطلبات Zabbix يذكر أن مكوّن الخادم مدعوم على Linux ومنصات UNIX الأخرى فقط، وينص على أن "UNIX هو نظام التشغيل الوحيد القادر على تقديم الأداء وتحمل الأعطال والمرونة المطلوبة باستمرار". يشمل دعم Windows وكيل Zabbix والوكيل 2، وهما ما تثبّته على الأجهزة المراقَبة. يقع خادم المراقبة على مضيف Linux؛ وبنية Windows هي ما يراقبه.
هل يقوم Prometheus بمراقبة SNMP؟
ليس بمفرده. يجمع Prometheus من نقاط نهاية HTTP ويستخدم snmp_exporter للجمع من أجهزة SNMP. يغطي تكوينه الافتراضي كثيرًا من المحولات والموجهات الشائعة، بينما قد تتطلب الكائنات الخاصة بالمورّد أو الاستطلاع المخصص تكوين MIB إضافيًا والمولّد.
النقاش
التعليقات
سجّل الدخول للمشاركة في النقاش.