Zabbix Server

دعم التوسّع التلقائي # خبير

كيف يعمل التوسّع التلقائي في AWS مع Zabbix؟

للتعامل مع التوسّع التلقائي من Zabbix هناك ثلاث نقاط ينبغي مراعاتها:

1. إضافة النسخة الجديدة إلى Zabbix عند ظهورها. يمكن ذلك عبر التسجيل التلقائي لوكلاء Zabbix النشطين (6.4، 6.0، 4.0). وهكذا يضيفها Zabbix تلقائيًا كمضيف جديد.
2. حفظ معرّف النسخة في جرد Zabbix. عند اختفاء النسخة (scale in) نتلقّى رسالة تحمل معرّفها، لذا نحتاج إليه في جرد المضيف كي نبحث عنه ونحذفه.
3. استقبال رسائل التوسّع من AWS. عند وقوع حدث توسّع تنشر AWS رسالة SNS في موضوع تحدّده أنت. وبربط ذلك الموضوع بطابور SQS نستطيع قراءة الرسائل من Zabbix وحذف النسخ التي تغادر مجموعات التوسّع.

تهيئة العميل

تلزم خطوتان لتهيئة عملائك للتوسّع التلقائي في Zabbix: تهيئة وكيل Zabbix، وإضافة ملف بمعامل مستخدم للعنصر instance_id.

تهيئة وكيل Zabbix

إلى جانب أي تعديلات أخرى قد تحتاجها، هناك ستة أمور تُغيَّر في ملف تهيئة وكيل Zabbix المحلي، وهو عادةً /etc/zabbix/zabbix_agentd.conf:

• تعليق الخيار Server.
• إضافة ServerActive=YOUR__ZABBIX__IP__ADDRESS لضبط الخادم النشط.
• تعليق الخيار Hostname.
• ضبط الخيار StartAgents على 0.
• ضبط الخيار HostnameItem على system.hostname.
• ضبط الخيار HostMetadataItem على system.uname.

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

المعامل instance_id

افتراضيًا، حين يظهر خادم جديد من مجموعة توسّع في Zabbix يُربط بقالب خاص اسمه AWS EC2 Template يحوي عنصرًا اسمه instance_id مرتبطًا بحقل alias في الجرد. ولتغذيته أضف إلى عميل Zabbix معامل مستخدم بإنشاء الملف:

UserParameter=aws.ec2.instance_id,curl -s http://169.254.169.254/latest/meta-data/instance-id

تهيئة الخادم

بعد تهيئة العملاء، الخطوة التالية هي تهيئة الخادم لحذف النسخ المُزالة. وأسرع الطرق وأبسطها من خطوتين: إرسال رسائل التوسّع إلى طابور SQS، وتهيئة الخادم لقراءته.

إرسال رسائل التوسّع إلى طابور SQS

نريد أن تُحفظ إشعارات خدمة التوسّع التلقائي في طابور SQS، ضمانًا للمتانة والاتساع. وبما أن التوسّع التلقائي في AWS ينشر الإشعارات في موضوع SNS، نحتاج إلى:

• إنشاء موضوع SNS.
• إنشاء طابور SQS.
• تهيئة SNS لتسليم الرسائل إلى SQS.
• إنشاء مستخدم IAM يستطيع قراءة الرسائل.

ولأن هذه التهيئة معقّدة، يمكنك استخدام قالب CloudFormation لدينا لإنشاء كل العناصر في المنطقة التي تريدها. وبعد النشر ستجد في تبويب Outputs أربع قيم ينبغي تدوينها:

• SNSTopicARN: معرّف ARN لموضوع SNS المُنشأ.
• SQSQueueURL: رابط طابور SQS.
• SQSReadIAMUserAccessKey وSQSReadIAMUserSecretKey: مفتاح مستخدم IAM وسرّه.

تحتاج هذه القيم للتهيئة. حرّر الملف /etc/zabbix/zabbix_ami.yml في المقطع الشبيه بـ:

sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url:
      access_key_id:
      secret_access_key:
      region:

ولكل طابور SQS يحمل إشعارات توسّع أضف عنصرًا للمصفوفة على غرار الموجود، بالقيم التي أعطاها CloudFormation. ومزيد من المعلومات عن هذا الملف في قسم الملفات المهمة.

الملفات المهمة # خبير

تحوي صورة Zabbix عددًا من الملفات الخاصة التي ينبغي أن تعرفها.

/etc/zabbix/zabbix_ami.yml

هذا أهمها، لأنه يتحكم في تهيئة الجوانب الخاصة، مثل فحوصات التوسّع أو إشعارات SNS. وهذا مثال (ببيانات وهمية):

zabbix:
  api:
    user: autoscaler_api_user
    password: i-073672daf01037aea94
sns:
  aws:
    access_key_id: AKK4L6A3OXZZ5HE2POQRU7V
    secret_access_key: cICycAg26hSDpsJwbhZjbaaYlt4Tz3n1xqE7Oxp6X2Hf
    region: us-east-1
  topics:
    not_classified: arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    information:    arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    warning:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    average:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    high:           arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    disaster:       arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url: https://sqs.us-east-1.amazonaws.com/000000000/zabbix-pro-sqs-queue
      access_key_id: AKIA3OXZZ5HEWUR5A16CNWH
      secret_access_key: 8ttYO3Ba9K6p0C+aj3fH5cDt2eRLHmlkHbMtlrpv18S7KRbC
      region: us-east-1

يحوي هذا الملف حاليًا ثلاثة أقسام مختلفة:

• zabbix: بما أننا نحتاج إلى الاتصال بخادم Zabbix لحذف المضيفات القديمة، فنحن بحاجة إلى الوصول إلى واجهته البرمجية. ولذلك نُنشئ مستخدمًا مخصّصًا تُذكر بياناته هنا.
• sns: التهيئة اللازمة لإرسال التنبيهات عبر SNS. هنا نضبط بيانات مستخدم IAM ومواضيع SNS التي سنستخدمها.
• sqs: تهيئة التعامل مع رسائل التوسّع في AWS. هنا نحدّد كل كم يُفحص الطابور (delay_seconds) والطوابير المختلفة التي تُراجع.

/var/log/zabbix-sqs-reader/zabbix-sqs-reader.log

يسجّل هذا الملف أحداث التوسّع التلقائي المقروءة من SQS.

قبل إتمام التهيئة سترى الرسالة Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — وهذا طبيعي، وتختفي بمجرد تهيئة zabbix_ami.yml.

تحديثات الصورة # خبير

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

صورتنا لـ Zabbix هي أفضل وسيلة لتفادي هذه المشكلات، إذ نوفّر مسارًا للانتقال بين الإصدارات الرئيسية أسرع وأبسط وأأمن من المعتاد.

ملخّص التحديث

عملية تحديث صورتنا بسيطة إلى حد بعيد:

• أخذ نسخة من قاعدة البيانات الحالية.
• تشغيل صورة جديدة بأحدث إصدار مستقر.
• رفع نسخة قاعدة البيانات إلى النسخة الجديدة.
• تشغيل سكربت الترحيل لدينا.

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

خطوات التحديث

الخطوة 1: نسخ احتياطي لخادم المصدر

الخطوة الأولى هي إنشاء صورة لخادم المصدر تفاديًا لأي فقدان عرضي للبيانات. ويمكنك اتباع دليل AWS لإنشاء صورة AMI.

الخطوة 2: تفريغ قاعدة البيانات ومعرفة إصدار Zabbix

ندخل إلى النسخة عبر SSH ونتحوّل إلى root:

sudo /bin/su -

ثم نفرّغ قاعدة البيانات إلى ملف:

mysqldump zabbix > zabbix_origin_database.sql

وأخيرًا ننزّل الملف إلى جهازنا لرفعه لاحقًا إلى الخادم الجديد. ودوّن أيضًا إصدار Zabbix الحالي: تراه في واجهة الويب، ويكون رقمًا شبيهًا بـ 4.0 أو 4.2 أو 4.4 أو 5.4.

الخطوة 3: تشغيل نسخة Zabbix جديدة

الخطوة التالية هي إنشاء نسخة Zabbix جديدة بأحدث إصدار مستقر من الصورة، وتجده في صفحة البائع لدينا على AWS Marketplace. وكحد أدنى عليك استخدام الإصدار 6.0 من صورتنا.

ستكون هذه النسخة هي خادم الوجهة الذي ننقل إليه البيانات، وهي تأتي بأحدث إصدار مثبَّتًا ومحدَّثًا. وبعد إقلاعها انسخ إليها ملف قاعدة البيانات من خادم المصدر.

الخطوة 4: تحديث قاعدة البيانات

لإدخال قاعدة البيانات الحالية وترقيتها إلى الإصدار الجديد وإضافة التهيئات اللازمة، نستخدم السكربت /opt/tools/bin/zabbix-ami-upgrade.sh. يُشغَّل بالمستخدم ubuntu مع تمرير إصدار Zabbix الأصلي وملف النسخة. مثلًا عند الترحيل من Zabbix 4.0:

/opt/tools/bin/zabbix-ami-upgrade.sh 4.0 zabbix_origin_database.sql

تُعلمك العملية بكل خطوة تنفّذها، وبعد انتهائها يمكنك متابعة العمل بخادم Zabbix الجديد.

الخطوة 5: الدخول إلى واجهة الويب

بعد انتهاء الترحيل يمكنك فتح واجهة الويب ومعاينة الوضع العام للخادم. ومن المهم استخدام المستخدمين وكلمات المرور نفسها التي كانت على الخادم السابق.

الخطوة 6: ترحيل التهيئات الخاصة وتوجيه العملاء

بعد أن تصبح قاعدة البيانات جاهزة، انتبه لتهيئات أخرى ربما ثبّتها على الخادم، مثل:

• سكربتات المراقبة.
• حزم نظام إضافية.
• شهادات SSL مثبَّتة.

كما سيلزم نقل عنوان EIP الذي هيّأته لتلك النسخة، حتى لا يحتاج العملاء إلى أي تعديل.

وإن لم تكن تستخدم EIP فهذه لحظة مناسبة للبدء، وإلا فسيتعيّن تغيير عنوان الخادم الجديد في كل العملاء.