جميع نرحب القراء الأعزاء. في هذه المقالة ، سوف أخبرك عن "دراجتي" ، التي أقوم بمراقبة مختلف الأشياء دون ترك وحدة التحكم.
لقد واجهت مرة واحدة موقفًا تم فيه توليد الكثير من المشروعات والخوادم المختلفة ، ولم تصل يدي إلى إعداد المراقبة العادية.
وفي العالم الحديث ، تعني المراقبة "الصحيحة" نشر مجموعة كاملة من البرامج ، تكوين هذا الشيء برمته. تعلمون جيدا هناك ... عامل ميناء ، كومة مرنة وخارجها ذهب. بالنسبة لي كان ذلك عبء قوي. أردت واحد أو اثنين في الإنتاج.
نظرت إلى
شاشة بسيطة على ثعبان ، كان الأقرب لي بروح ، لكنها تفتقر إلى عدد غير قليل من الميزات. وفي الوقت نفسه أردت أن أتعلم Go ... حسنًا ، بشكل عام ، أنت نفسك تعرف كيف يبدأ كل شيء عادة.
لذلك أخذت
اللحام Go ، ووضعت هذه
الدراجة .
تتم كتابة Cli Monitoring في Go وهي عبارة عن مجموعة من الثنائيات ، يستقبل كل منها بيانات من stdin ، ويقوم ببعض المهام المحددة ويعرض النتيجة في stdout.
هناك أربعة أنواع من الثنائيات في المجموع:
المقاييس والمعالجات والمرشحات والمخرجات .
المقاييس ، كما يوحي الاسم ، تجمع أي بيانات وعادةً ما تدخل أولاً في السلسلة.
المعالجات في الوسط وتغيير البيانات بطريقة أو بأخرى أو أداء وظائف الأداة المساعدة الأخرى.
تشبه
المرشحات المعالجات تقريبًا ، ولكن على عكسها ، فإنها تتخطى البيانات أو لا تتخطاها ، حسب الحالة.
المخرجات موجودة عند الخروج من السلسلة وتستخدم لإرسال الإخطارات إلى مختلف الخدمات.
سلسلة الأوامر بأكملها عادة ما يكون لها الشكل:
some_metric | processor_1 | processor_2 ... | cm_p_message | output_1 | output_2 ...
أي جزء من هذه السلسلة يمكن أن يكون أي أمر Linux ، طالما أنه يتلقى البيانات في stdin ويرسلها إلى stdout دون تخزين مؤقت. لا يوجد سوى واحد صغير ولكن يتعلق بفواصل الأسطر ، ولكن المزيد عن ذلك في وقت لاحق.
يتم تشكيل اسم الثنائيات كـ
cm_ {type} _ {name} ، حيث يكون type واحدًا من ثلاثة:
m ، p ، f أو o ، والاسم هو اسم الأمر.
على سبيل المثال ، cm_m_cpu هو مقياس ينتج عنه إحصائيات على معالج بتنسيق json إلى stdout.
وملف cm_p_debounce هو معالج يتيح فقط الخروج برسالة واحدة في كل مرة في فاصل زمني محدد.
يوجد معالج
cm_p_message خاص واحد يجب أن يكون أمام الإخراج الأول. يقوم بإنشاء رسالة بالتنسيق المطلوب للمعالجة اللاحقة بواسطة مخرجاتها.
للتعامل مع json في وحدة التحكم والظروف المختلفة ، استخدمت الأداة المساعدة
jq . هذا شيء مثل sed ، فقط لجسون.
هذه هي الطريقة ، على سبيل المثال ، مراقبة وحدة المعالجة المركزية تبدو في النهاية.
cm_m_cpu | cm_p_eot2nl | jq -cM --unbuffered 'if .LoadAvg1 > 1 then .LoadAvg1 else false end' | cm_p_nl2eot | cm_f_regex -e '\d+' | cm_p_debounce -i 60 | cm_p_message -m 'Load average is {stdin}' | cm_o_telegram
ومراقبة عدد الرسائل في قائمة انتظار RabbitMQ
while true; do rabbitmqctl list_queues -p queue_name | grep -Po --line-buffered '\d+'; sleep 60; done | jq -cM '. > 10000' --unbuffered | cm_p_nl2eot | cm_f_true | cm_p_message -m 'There are more than 10000 tasks in rabbit queue' | cm_o_opsgenie
حتى تتمكن من مراقبة أنه لم تتم كتابة أي شيء في الملف خلال 10 ثوانٍ
tail -f out.log | cm_p_nl2eot | cm_p_watchdog -i 10 | cm_p_debounce -i 3600 | cm_p_message -m 'No write to out.log for 10 seconds' -s 'alert' | cm_o_telegram
لا تتعجل في إغلاق الشاشة ، والآن سنحلل ما يحدث هنا في المثال الأول.
1) يعرض
cm_m_cpu المتري مرة واحدة في الثانية (المحددة بواسطة المعلمة -i ، افتراضيًا الثانية) سلاسل بتنسيق json. على سبيل المثال ، {"LoadAvg1": 2.0332031 ، "LoadAvg2": 1.9018555 ، "LoadAvg3": 1.8623047}
2) cm_p_nl2eot هو أحد أوامر الأداة المساعدة التي تحول حرف EOT إلى حرف LF. والحقيقة هي أنه من أجل تجنب مشاكل التفاف الخط ، قررت أن أتأكد من قراءة جميع البيانات الثنائية حتى البيانات ascii EOT (نهاية الإرسال). يتيح لك ذلك نقل البيانات متعددة الخطوط بأمان بين الفرق.
لذلك ، عند استدعاء أي أوامر أخرى ، يجب أن تكون محاطة بالشكل:
cm_p_eot2nl | أي فريق آخر | cm_p_nl2eot.3) التالي هو استدعاء الأداة المساعدة jq ، والتي تتحقق من حقل LoadAvg1 وإذا كانت أكبر من 1 ، ثم تعرضها بشكل أكبر ، إذا كانت أقل ، تعرض خطأ
4) بعد ذلك ، نحن بحاجة إلى رمي الرسالة بأكملها
كاذبة من السلسلة. للقيام بذلك ، نطبق عامل تصفية
cm_f_regex ، الذي يأخذ سلسلة كمدخلات ،
ويطابقها مع تعبير منتظم ، وفي حالة وجود تطابق ، يعرضه كذلك. خلاف ذلك ، يتم تجاهل السلسلة ببساطة
يمكن استخدام grep العادي ، ولكن أولاً يقوم بتخزين المخرجات مؤقتًا ، ويصبح بناء الجملة الكامل أطول قليلاً (grep - line-buffered) ، ثانيًا cm_f_regex يجعل من السهل جدًا عرض مطابقات المجموعات. على سبيل المثال:
cm_f_regex -e '(\d+)-(\d+)' -o '{1}/{2}'
يحول السطر 123-345 إلى السطر 123/345
5) يأخذ المعالج
cm_p_debounce ، في هذه الحالة ، قيمة LoadAvg1 ويعرضها في السلسلة مرة واحدة فقط كل 60 ثانية. هذا ضروري حتى لا تزعج نفسك. يمكنك تعيين أي فاصل زمني آخر.
6) كل شيء تقريبا جاهز. يبقى فقط لتشكيل رسالة وإرسالها إلى البرقيات. يتم إنشاء الرسالة بواسطة الأمر
cm_p_message الخاص. يقبل ببساطة سلسلة كمدخلات ، ويخلق json مع درجة الخطورة ، والرسائل ، والحقول الأخرى ثم يخرجها لمعالجة المخرجات. إذا لم نقم بتمرير خيار -m إليه ، فستكون stdin هي الرسالة ، أي رقم الدخن هو LoadAvg1 لدينا. هذه ليست مفيدة للغاية.
7) يقوم فريق cm_o_telegram ببساطة بإرسال الرسالة المستلمة إلى البرق. يتم تخزين إعدادات Telegram في ملف INI.
ترتيب
يمكن تحديد جميع المعلمات التي تقبل الثنائيات في ملف ini. المعلمات المحددة بواسطة وسيطة سطر الأوامر لها الأسبقية على ملف ini.
تنسيق الملف init هو:
[global]
host_name=override host name for this machine
[telegram]
cid=....
token=....
[opsgenie]
apiToken=...
apiEndpoint=...
......
[debounce]
i=3600
يتم تحديد ملف ini نفسه بالترتيب التالي:
1) الملف cm.config.ini في دليل العمل الحالي
2) الملف / etc / cm/config.ini إذا لم يتم العثور على الملف من البند 1
إنتاج
على خادم حقيقي ، أقوم بإنشاء ملف ، على سبيل المثال ، cpu.sh ، حيث تتم كتابة كل سلسلة الأوامر الضرورية. ثم في التاج أصف شيئًا كهذا:
*/5 * * * * flock -n /etc/cm/cpu.lock /etc/cm/cpu.sh > /dev/null
إذا حدث شيء ما قبالة القطيع سوف يعيد الأمر. وهذا كل شيء! بساطتي التي لم أكن أفتقر إليها.
هذه أداة ، ربما سيجدها شخص ما مناسبًا. بالنسبة لي ، الراحة هي أنه ليست هناك حاجة لعمل الكثير من الأشياء غير الضرورية فقط لمراقبة الأشياء الضرورية. وقد تمت تهيئتها بشكل ملائم: استنسخت المستودع ، وأضفت المسار إلى الثنائيات بـ PATH $ وهذا كل شيء.
من فضلك لا تحكم بدقة. تم كتابة الأداة بنفسي ، مجموعة الأوامر ليست كبيرة بعد. لكنني سأكون سعيدًا بأي ملاحظات واقتراحات. شكرا لكم جميعا على اهتمامكم.