لوحة المتصدرين

حاوية لينكس هي مجموعة من العمليات المعزولة عن بقية النظام من خلال استخدام ميزات أمان نواة لينكس، مثل مساحات الأسماء ومجموعات التحكم. إنها بناء مماثل للآلة الافتراضية، و لكنه أكثر خفة منها، فإن لم يكن لديك النفقات الكافية لتشغيل أنوية إضافية أو آلات افتراضية فلا تقلق من ذلك، لأنه يمكنك بسهولة إنشاء حاويات متعددة على نفس الخادوم. على سبيل المثال، تخيل أن لديك خادوم يقوم بتشغيل مواقع ويب متعددة لعملائك. في حال التثبيت التقليدي سيكون كل موقع على شبكة الانترنت مضيفًا افتراضيًا من نفس حالة خادوم apache أو Nginx. ولكن مع حاويات لينكس يمكن لكل موقع على شبكة الإنترنت أن يثبت في حاوية خاصة به مع خادوم الويب الخاص بها. باستخدام حاويات لينكس يمكنك تجميع التطبيق الخاص بك واعتمادياته في حاوية دون التأثير على بقية النظام. يتيح لك LXD إنشاء هذه الحاويات وإدارتها. يوفر LXD خدمة مراقب الأجهزة الافتراضية لإدارة دورة الحياة الكاملة للحاويات. في هذا الدرس سوف نقوم بإعداد LXD واستخدامه لتشغيل Nginx في حاوية. وستقوم بعد ذلك بتوجيه حركة المرور إلى الحاوية من أجل جعل موقع الويب ممكن الوصول إليه من الإنترنت. المتطلبات الأساسية لإكمال هذا الدرس ستحتاج إلى ما يلي: خادوم أوبونتو 16.04 مُعَد مسبقا ، يمكنك الرجوع إلى هذه المقال لتعرف كيف تفعل ذلك: الإعداد الابتدائي لخادوم أوبنتو 14.04 مستخدم غير جذر يملك صلاحيات الجذر وجدار الحماية. اختياريًا أضف 20 جيغا أو أكثر من مساحة التخزين ، يمكنك استخدام ذلك لتخزين كافة البيانات المتعلقة بالحاويات. الخطوة 1 : إعداد LXD تم تثبيت LXD بالفعل على أوبونتو، ولكن يجب أن يتم إعداده بشكل مناسب قبل أن تتمكن من استخدامه على الخادوم. يجب عليك إعداد حساب المستخدم لإدارة الحاويات، ثم إعداد نوع قاعدة التخزين لتخزين الحاويات وإعداد الشبكة. قم بتسجيل الدخول إلى الخادوم باستخدام حساب المستخدم غير الجذر. ثم أضف المستخدم إلى مجموعة LXD بحيث يمكنك استخدامه لأداء جميع مهام إدارة الحاويات: sudo usermod --append --groups lxd Sammy قم بتسجيل الخروج من الخادوم وتسجيل الدخول مرة أخرى لكي يتم تحديث جلسة SSH الجديدة الخاصة بك مع عضوية المجموعة الجديدة. بعد تسجيل الدخول يمكنك البدء في تهيئة LXD. الآن قم بإعداد قاعدة التخزين. قاعدة التخزين الموصى بها ل LXD هو نظام ملفات ZFS، المخزنة إما في ملف مخصص مسبقًا أو باستخدام كتلة التخزين . لاستفادة من دعم ZFS في LXD حدّث قائمة الحزم الخاصة بك ثم ثبت الحزمة zfsutils-linux : sudo apt-get update sudo apt-get install zfsutils-linux يمكنك الآن إعداد LXD. ابدأ بعملية تهيئة LXD مع الأمر LXD init : sudo lxd init ستتم مطالبتك بتعيين تفاصيل قاعدة التخزين. بعد الانتهاء من هذا الإعداد يتوجب عليك إعداد الشبكة من أجل الحاويات. أولاً سوف يُقترح عليك أن تختار بشأن قاعدة التخزين، وستُخَير بين أمرين: dir أو zfs . الخيار dir يخبر LXD بتخزين الحاويات في مجلدات تابعة لنظام ملفات الخادوم. وأما الخيار zfs فيستخدم نظام الملفات zfs ونظام إدارة القرص الصلب LVM. اختر zfs. باستخدام zfs نحصل على كلٍّ من كفاءة التخزين وتحسين الاستجابة. على سبيل المثال إذا أنشأنا عشرة حاويات من نفس صورة الحاوية الأولية، فإنها جميعا تستخدم من القرص مساحةَ حاوية واحدة فقط. وبعد ذلك سيتم فقط تخزين التغييرات على صورة الحاوية الأولى في قاعدة التخزين. Name of the storage backend to use (dir or zfs) [default=zfs]: zfs بعد اختيار zfs سيُطلَب منك إنشاء تجمع (pool) zfs جديد واسم لهذا التجمع. اختر نعم لإنشاء التجمع، وسمه ب lxd : Create a new ZFS pool (yes/no) [default=yes]? yes Name of the new ZFS pool [default=lxd]: lxd ثم ستُسأل إذا كنت ترغب في استخدام عتاد التخزين الموجود: Would you like to use an existing block device (yes/no) [default=no] إذا أجبت بنعم فعليك أن تخبر LXD أين يجد هذا العتاد. إذا أجبت بلا فسوف يقوم LXD باستخدام ملف مخصص مسبقًا. مع هذا الخيار سوف تستخدم المساحة الفارغة على الخادوم نفسه. هناك حالتان يتبعان ذلك اعتمادًا على ما إذا كنت تريد استخدام ملف مخصص مسبقًا أو عتاد التخزين. اتبع الخطوة المناسبة لحالتك. بعد تحديد آلية التخزين ستعمل على تهيئة خيارات الشبكة من أجل حاوياتك. الخيار 1 : استخدام التخصيص المسبق يمكنك استخدام ملف مخصص مسبقًا إذا لم تتمكن من الوصول إلى عتاد التخزين من أجل تخزين الحاويات. اتبع هذه الخطوات لإعداد LXD لكي يستخدم ملف مخصص مسبقًا لتخزين الحاويات. أولًا، عندما يطلب منك استخدام عتاد التخزين الموجود أجب بلا : Would you like to use an existing block device (yes/no) [default=no]? no بعد ذلك، سيطلب منك تحديد حجم loop device ، الذي يستدعيه الملف المخصص مسبقًا من LXD. استخدام الحجم الافتراضي المقترح للملف المخصص مسبقًا : Size in GB of the new loop device (1GB minimum) [default=15]: 15 وكقاعدة عامة 15 جيغا هو أصغر حجم يجب عليك إنشاؤه. فأنت تريد تخصيص مساحة كافية لكي يكون لديك 10 غيغابايت على الأقل من المساحة المتبقية بعد إنشاء الحاويات الخاصة بك. بعد تهيئة الجهاز سيطلب منك إعداد الشبكة. انتقل إلى الخطوة 2 لمتابعة الإعداد. الخيار 2 : استخدام عتاد التخزين إذا كنت تريد استخدام عتاد التخزين قاعدةً للتخزين فستحتاج إلى العثور على العتاد الذي يتوافق مع حجم كتلة التخزين التي قمت بإنشائها في تهيئة LXD. انتقل إلى تبويب المجلدات في لوحة التحكم الخاصة ب DigitalOcean، ثم حدد موقع وحدة التخزين الخاصة بك، انقر فوق المزيد من القائمة المنبثقة، ثم انقر فوق تعليمات الإعداد. حدد موقع العتاد بتطبيق أمر تهيئة وحدة التخزين. بعبارة أدق ابحث عن المسار المحدد بتنفيذ الأمر sudo mkfs.ext4 -F . لا تقم بتشغيل أيٍّ من الأوامر الظاهرة في تلك الصفحة، نحن لا نريد سوى العثور على اسم الجهاز الصحيح لإعطاءه لـ LXD. يوضح الشكل التالي مثالا عن اسم الجهاز الخاص بوحدة التخزين. تحتاج فقط إلى الجزء المسطر عليه بالأحمر: يمكنك أيضا تحديد اسم الجهاز بالأمر التالي: ls -l /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 9 Sep 16 20:30 scsi-0DO_Volume_volume-fra1-01 -> ../../sda في هذه الحالة اسم الجهاز لوحدة التخزين هو /dev/disk/by-id/scsi-0D0_Volume_volume-fra1-01 وقد يختلف الأمر لديك. بعد تحديد اسم عتاد وحدة التخزين تابع مع تثبيت LXD . عندما تُسأل هل تود أن تستخدم عتاد التخزين الموجود، اختر نعم وقدّم المسار الذي وجدته سابقا: Would you like to use an existing block device (yes/no) [default=no]? yes Path to the existing block device: /dev/disk/by-id/scsi-0DO_Volume_volume-fra1-01 بعد تحديد القرص الصلب سيطلب منك إعداد خيارات الشبكة. الخطوة 2 : إعدادات الشبكة بعد تهيئة وحدة التخزين ستتم مطالبتك بتهيئة الشبكة وإعدادها. أولاً سيسألك LXD عما إذا كنت تريد جعله متاحًا عبر الشبكة. اختيار “نعم” سوف يمكّنك من إدارة LXD من جهاز الكمبيوتر المحلي الخاص بك، دون الحاجة إلى جلسة SSH للوصول إلى هذا الخادوم. اقبل القيمة الافتراضية “لا” : Output of the "lxd init" command — LXD over the network Would you like LXD to be available over the network (yes/no) [default=no]? no ثم سيطلب منك إنشاء جسر الشبكة من أجل حاويات LXD. وهذا يتيح لك الميزات التالية: كل حاوية تحصل تلقائيًا على عنوان IP خاص. يمكن للحاويات التواصل مع بعضها البعض عبر الشبكة الخاصة. يمكن لكل حاوية انشاء اتصال بالإنترنت. تبقى الحاويات التي تقوم بإنشائها غير قابلة للوصول إليها من الإنترنت. لا يمكنك إجراء اتصال من الإنترنت والوصول إلى حاوية إلا إذا قمت بتمكينه صراحة. سوف تتعلم كيفية السماح بالوصول إلى حاوية معينة في الخطوة التالية. عندما يطلب منك تكوين جسر LXD، اختر نعم : Output of the "lxd init" command — Networking for the containers Do you want to configure the LXD bridge (yes/no) [default=yes]? Yes سيتم عرض الرسالة التالية: أكّد أنك تريد إعداد جسر الشبكة. سيطلب منك تسمية الجسر. اقبل القيمة الافتراضية. سيطلب منك إجراء تهيئة الشبكة لكلٍّ من IPv4 و IPv6. في هذا الدرس سنعمل فقط مع IPv4. عندما يطلب منك إعداد شبكة فرعية IPv4 اختر نعم . سوف يتم إعلامك بأنه تم إنشاء شبكة فرعية عشوائية بالنسبة لك. اختر موافق للمتابعة. عند المطالبة بعنوان IPv4 صحيح قم بقبول القيمة الافتراضية. عندما يطلب منك قناع CIDR صحيح، اقبل القيمة الافتراضية. عند المطالبة بعنوان DHCP الأول اقبل القيمة الافتراضية. افعل الشيء نفسه مع عنوان DHCP الأخير وذلك حسب الحد الأقصى لعدد عملاء DHCP. اختر نعم عندما يطلب إلى NAT حركة مرور IPv4. عندما يطلب منك إعداد شبكة فرعية لـ IPv6 اختر “لا” . ستشاهد المخرجات التالية بعد اكتمال إعداد الشبكات: Warning: Stopping lxd.service, but it can still be activated by: lxd.socket LXD has been successfully configured. أنت مستعد الآن لإعداد حاوياتك. الخطوة 3 : إنشاء حاوية Nginx لقد نجحت في تهيئة LXD وأصبحت الآن جاهزا لإنشاء الحاوية الأولى وإدارتها. يمكنك إدارة الحاويات مع الأمر lxc. استخدم lxc list لعرض الحاويات المثبتة المتاحة: lxc list سترى الإخراج التالي: Generating a client certificate. This may take a minute... If this is your first time using LXD, you should also run: sudo lxd init To start your first container, try: lxc launch ubuntu:16.04 +------+-------+------+------+------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+-------+------+------+------+-----------+ وبما أن هذه هي المرة الأولى التي يتواصل فيها الأمر lxc مع مراقب الأجهزة الافتراضية لـ LXD تتيح لك مخرجاته معرفة أنه قام تلقائيًا بإنشاء شهادة للعميل من أجل الاتصال الآمن مع LXD، وبعض المعلومات حول كيفية تشغيل حاوية، وقائمة فارغة من الحاويات، وهو أمر متوقع لأننا لم ننشئ أي واحدة حتى الآن. دعنا ننشئ حاوية تقوم بتشغيل Nginx. للقيام بذلك سوف نستخدم الأمر lxc launch لإنشاء وبدء حاوية أوبونتو 16.04 اسمها webserver. لإنشاء الحاوية webserver ننفذ الأمر: lxc launch ubuntu:x webserver x في ubuntu:x هو اختصار للحرف الأول من Xenial ، الاسم الرمزي لأوبونتو 16.04. ubuntu: هو معرف للمستودع الذي تم تكوينه مسبقا لصور LXD . يمكنك أيضا استخدام ubuntu:16.04 لاسم الصورة. ملاحظة : يمكنك العثور على القائمة الكاملة لجميع صور ubuntu المتاحة عن طريق تشغيل الأمر: lxc image list Ubuntu: وفي التوزيعات الأخرى عن طريق تشغيل الأمر: lxc image list images: نظرًا لأن هذه هي المرة الأولى التي تقوم فيها بإنشاء حاوية ينزّل هذا الأمرُ صورةَ الحاوية من الإنترنت ويخزنها محليًا بحيث إذا أنشأت حاوية جديدة فسيتم إنشاؤها بسرعة أكبر. سترى هذه المخرجات عند إنشاء الحاوية الجديدة: Generating a client certificate. This may take a minute... If this is your first time using LXD, you should also run: sudo lxd init To start your first container, try: lxc launch ubuntu:16.04 Creating webserver Retrieving image: 100% Starting webserver الآن ..بعد تشغيل الحاوية استخدم الأمر lxc list لعرض معلومات حولها: lxc list تظهر المخرجات جدولًا يحمل اسم كل حاوية وحالتها الحالية وعنوان IP خاص بها ونوعها وما إذا كانت هناك لقطات مأخوذة. Output +-----------+---------+-----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+-----------------------+------+------------+-----------+ | webserver | RUNNING | 10.10.10.100 (eth0) | | PERSISTENT | 0 | +-----------+---------+-----------------------+------+------------+-----------+ ملاحظة: إذا قمت بتمكين IPv6 في LXD فقد يكون مخرج أمر lxc list كبيرًا جدًا عن أن تسعه الشاشة. يمكنك أن تستخدم بدلا عن ذلك الأمر lxc list –columns ns4tS الذي يظهر فقط الاسم والحالة و IPv4 والنوع وما إذا كانت هناك لقطات متاحة. لاحظ عنوان IPv4 للحاوية. ستحتاج إلى تهيئة الجدار الناري للسماح بالزيارات الواردة من العالم الخارجي. سنتابع في الدرس القادم كيفية تكوين وتوجيه وإزالة حاوية Nginx. ترجمة -وبتصرّف- للمقال How to Set Up and Use LXD on Ubuntu 16.04 لصاحبه Simos Xenitellis

هناك العديد من الأسباب التي تجعل من جمع الإحصائيات حول خواديمنا، تطبيقاتنا، وحركة مرور البيانات فكرة جيدة. حيث يعطينا جمع وتنظيم البيانات الثقة في قراراتنا حول الامتداد والتّوسّع scaling، استكشاف الأخطاء troubleshooting، وتعقّب نقاط الضّعف في إعداداتنا. توجد العديد من الأدوات التي يمكن أن تستخدم لتتبُّع المقاييس على أجهزتنا، والتي غالبًا ما تُسنَد إلى جزء صغير مُحدَّد من العمليّة، بإمكاننا ضم هذه الأدوات إلى بعضها لإنشاء نظام لتجميع، تسجيل، وعرض النتائج. سنناقش في هذا الدّرس بعض التقنيات التي تسمح لنا بجمع، تخزين، وتمثيل البيانات المُولَّدة من قبل خواديمنا وتطبيقاتنا. سنتحدّث عن Graphite وهي مكتبة رسوم بيانيّة مصنوعة من عدّة مكوّنات يُمكِن استخدامها لتصيير render التمثيلات المرئيّة لبياناتنا عبر الزمن، سنقوم بإلقاء نظرة أيضًا على collectd، وهو عفريت (بالإنجليزية Daemon وهو برنامج يعمل في خلفيّة النظام) لإحصائيات النظام بإمكانه جمع معلومات في الزمن الفوري تقريبًا حول خادوم قيد التشغيل. وأخيرًا سنتحدّث عن StatsD وهو مُجمِّع إحصائيّات مرن يمكن استخدامه لجمع وتنظيم البيانات الكيفيّة arbitrary data. لماذا نتتبع البيانات؟ إنّ أول شيء نحتاج معرفته هو الأسباب التي تدفعنا لتتبّع البيانات في بيئة خادوم أو تطبيق. السبب الرئيسي بسيط للغاية فعليًّا: فكلّما ازداد عدد البيانات التي نمتلكها كلّما ازدادت قدرتنا على فهم ما يحصل في لحظة ما، يعطينا هذا قدرة ملحوظة على دعم قراراتنا في التعامل مع البيانات ونرى في وقت مبكر إذا ما كان التغيير يستهدف المُكوِّن الصحيح، يزوّدنا تتبع الإحصائيّات بمصدر إضافي للمعلومات والتي قد لا تكون موجودة في سجلّات التطبيق. معظم (ولكن ليس كل) أنظمة التسجيل غير قادرة على ربط البيانات من التطبيقات المتعددة أو على ربط الأحداث مع حالات أنظمة محدّدة لأنّها تمثل أساسًا خرْجًا لتطبيق مستقل، ممّا قد يجعل من المعقّد بناء نظرة شاملة للظروف المحيطة بحدث ما. بإمكاننا أن نتخيّل للحظة أنه لدينا حالة توقّف فيها خادوم قاعدة البيانات عن العمل، فأثناء قراءة السجلّات logs قد نلاحظ أنّه في تمام الساعة 15:35:28 UTC تمّ إنهاء خدمة MySQL لدينا بخطأ نفاذ الذاكرة (OOM (out of memory، نحن نعرف الآن أنّ استخدام الذاكرة هو المشكلة ولكن ليست لدينا أي فكرة عن السبب الذي أدى لارتفاع استهلاك الذاكرة في خادوم مستقر سابقًا. إن كنّا نتتبّع البيانات حول خادومنا وتطبيقاتنا نستطيع بوضوح البدء في جمع القطع المختلفة لبيانات النظام لتساعدنا على فهم كيف كانت تبدو البيئة تمامًا أثناء حدوث المشكلة، قد نجد أنّه كان لدينا صعود ثابت في استهلاك الذاكرة والذي قد يحدث من تسرّب ذاكرة memory leak، وإن كانت لدينا معلومات حول استخدام الذاكرة على مستوى التطبيقات فبإمكاننا بالضبط رؤية التطبيق المسؤول عن هذا، قد نرى أيضًا أنّه كان لدينا ارتفاع غير معتاد باستهلاك الذاكرة والذي قد يعني شيئًا مختلفًا تمامًا. وفي حالة مختلفة نستطيع أن نرى كيف يبدو النظام قبل وبعد نشر التّطبيق deploy، فلو قامت شيفرة جديدة بإنشاء بعض الحالات الغريبة نستطيع رؤية تأثيرها على المكونات الأخرى لدينا، ومقارنة أدائها بالشيفرة القديمة، ونتمكّن من تحديد النقاط التي تُظهِر فيها الشيفرة الجديدة تحسينًا، والأماكن التي قد ارتكبنا فيها خطأ ما. وبالجمع الذكي للبيانات نتمكّن من مشاهدة نظامنا كنظام بدلًا من مجموعة من المكوّنات غير المرتبطة. مكونات Graphite سنعود هنا قليلًا إلى الوراء ونتحدث في البداية عن Graphite، مكتبة الرسوم البيانيّة، وبعدها سنتكلّم عن بعض البرمجيات التي تستطيع Graphite استخدامها للحصول على البيانات. إنّ Graphite هي عبارة عن مكتبة رسوم بيانيّة مسؤولة عن تخزين وتصيير تمثيلات مرئيّة للبيانات، وهذا يعني أنّ Graphite تتطلب تطبيقات أخرى لجمع ونقل نقاط البيانات. مشروع Graphite بحد ذاته مكوّن من بعض المكوّنات المختلفة، وكل من هذه المكونات لديها غرض مُحدّد ومُركّز. تطبيق ويب Graphite المُكوّن الأكثر مرئية وديناميكية من تثبيت Graphite هو تطبيق ويب Graphite. وهو المكان الذي نستطيع فيه تصميم الرسوم البيانيّة التي تمثّل بياناتنا: تعطينا Graphite واجهة شديدة المرونة لتصميم الرسوم البيانيّة، نستطيع الجمع بين مختلف أنواع المقاييس، التحكم باللصيقات label، الخطوط، الألوان، وخصائص الأسطر، وبإمكاننا تغيير حجم البيانات والتعامل معها بحسب رغبتنا. الفكرة الأساسية التي يجب فهمها هنا هي أنّ Graphite تقوم بتصيير الرسوم البيانيّة بحسب نقاط البيانات التي تتلقاها والاتجاهات التي نعطيها إياها، فهي لا تقوم فقط بطباعة الرسم البياني ومن ثم تتخلص من البيانات، نستطيع تصيير البيانات بأي شكل نريده فورًا. يتيح لنا تطبيق الويب أيضًا حفظ تخطيطات layouts وخصائص الرسم البياني، بحيث نتمكن من استعادة واجهة المراقبة مع كافة الإعدادات التي نرغب بها، بإمكاننا الحصول على نوافذ عرض لوحة الرئيسية كما نريد، أي نستطيع أن نمتلك لوحة رئيسية منفصلة لكل جهاز أو تطبيق، وإن أردنا الربط بين البيانات عبر هذه اللوحات نقوم فقط بسحب وإفلات الرسوم البيانيّة لضم نافذة العرض. ولا تتوقف مرونة Graphite عند هذا الحد، فهي تسمح لنا بتصيير الرسوم البيانيّة إلى رابط مجرّد لتضمينه في واجهات أخرى، بإمكاننا أيضًا تصدير البيانات إلى تمثيلات غير رسوميّة مثل JSON أو CSV، أو خَرْج SVG مع تضمين معلومات البيانات. الآن وقد عرفنا ما الذي يمكننا فعله بالبيانات بعد أن نحصل عليها فلنتحدث حول مكونات Graphite الأخرى لمشاهدة العمليّات التي تسمح لنا بالقيام بها. Carbon إنّ Carbon هو مخزن المنتهى الخلفي Backend لإعدادات Graphite، حيث يمتلك إعداد Graphite المفرد عفريت Carbon أو أكثر مسؤول عن التعامل مع البيانات التي يتم إرسالها بواسطة العمليات الأخرى التي تجمع وتنقل الإحصائيّات (أدوات الجمع Collectors هي ليست جزءًا من Graphite). هنالك العديد من أنواع عفاريت Carbon المختلفة، كل منها يتعامل مع البيانات بطريقة مختلفة، الأساسي منها يُدعى carbon-cache.py، هذا العفريت بسيط حيث يستمع إلى البيانات على منفذ port ويكتبها إلى القرص كما وصلت بطريقة فعّالة. يخزّن البيانات كما أتت ويفرغها إلى القرص بعد فترة محدّدة مسبقًا، من الهام معرفة أنّ مكوّن Carbon يتعامل مع إجراءات إفراغ flushing واستقبال البيانات، فهو لا يتعامل مع آليات التخزين الفعليّة، والتي تُترَك للمكوّن whisper الذي سنتحدث عنه بعد قليل. يتم إخبار العفريت carbon-cache.py بالتنسيقات formats، الموافيق protocols، والمنافذ التي يعمل عليها، يتم أيضًا إخباره بسياسات الاحتفاظ بالبيانات لاستخدامها من أجل تخزين البيانات، والتي يتم إعطاؤها للمكوّن whisper، بالنسبة لمعظم الإعدادات الأساسيّة فإنّ نسخة واحدة من carbon-cache.py يكفي للتعامل مع استقبال البيانات. يمكن تشغيل عدّة نسخ منه في وقت واحد عندما يكبر حجم النظام لدينا، ويمكن موازنتها بواسطة عفريت carbon-relay.py أو carbon-aggregator.py في المقدمة. بإمكاننا استخدام العفريت carbon-relay.py لإرسال الطلبات لكافة عفاريت المنتهى الخلفي من أجل بعض التوفير، ويمكن أيضًا استخدامه لمشاركة البيانات عبر أمثال carbon-cache.py المختلفة لنشر أحمال القراءة عبر مواقع التخزين المتعددة. يمكن للعفريت carbon-aggregator.py أن يحتفظ بالبيانات مؤقتًا ومن ثمّ يلقيها إلى carbon-cache.py بعد فترة من الزمن، قد يساعد هذا في تخفيف تأثير معالجة الإحصائيات على النظام على حساب التفاصيل. Whisper إنّ Whisper هي عبارة عن مكتبة قواعد بيانات تستخدمها Graphite لتخزين المعلومات التي يتم إرسالها. هذه المكتبة مرنة جدًّا وتسمح بأن يتم تخزين البيانات المتسلسلة زمنيًّا بتفصيل رائع، تقوم بإنشاء أرشيفات مختلفة على مستويات مختلفة من التفصيل، لذا في الاستخدام العملي يتم تحويل المعلومات إلى دقة أقل عندما تتجاوز عتبات زمنيّة مُعيّنة. على سبيل المثال نستطيع تخزين نقطة بيانات واحدة كل ثانية لمقياس مُحدّد، بإمكاننا أن نطلب من whisper أن يحتفظ بهذه البيانات المفصّلة لمدّة خمس ساعات، بإمكاننا أن نمتلك أيضًا أرشيفًا لتخزين بيانات ذات دقة أقل، قد يقوم فقط بتخزين نقطة واحد كل دقيقة ويبقيها لمدّة ستة أشهر. يتم حساب كل نقطة من الأرشيف الأقل دقّة من خلال نفس البيانات المُخزّنة في الأرشيفات الأكثر دقّة، بإمكاننا أن نمتلك أرشيفات من دقات مختلفة مع معدلات احتفاظ بالبيانات كما نريد، نستطيع إعداد كيفيّة حساب whisper للبيانات للأرشيفات الأقل دقّة اعتمادًا على نوع المقياس الذي يتم تتبّعه. على سبيل المثال قد يكون المقياس هو سجل عدد المرات لحدوث بعض الأحداث خلال إطار زمني قصير، ولإنشاء نقطة لإطار زمني أطول بدقة أقل نضيف نقاط البيانات من الأرشيف ذي الدقة الأعلى لتلخيص قيم البيانات خلال الفترة الزمنية الأطول. تستطيع Whisper حساب البيانات ذات الدقة الأقل بطرق أخرى اعتمادًا على طبيعة المقاييس، على سبيل المثال يتم تعميم بعض البيانات عن طريق حساب المتوسط، بينما قد يتم تتبّع بيانات أخرى بحسب القيمة العظمى. بالنسبة للمتوسط يتم حساب القيمة الفعلية المتوسطة من نقاط ذات دقّة أعلى لإنشاء نقاط ذات دقّة أقل، وبالنسبة للقيمة العظمى يجب الإبقاء على أكبر قيمة ورمي باقي القيم للحفاظ على معنى الرقم. تقوم whisper بحساب وتسجيل البيانات ذات الدقّة الأقل في وقت استقبالها لتلك البيانات (بعد الفترة الزمنية اللازمة لجمع القيم الضروريّة)، فهي ببساطة تجمع نقاط البيانات التي تحتاجها لتنفيذ تقنية جمع البيانات (المتوسط، القيمة الكبرى، إلخ..) وبعدها تقوم بكتابتها. تستخدم Graphite أعلى دقّة للأرشيف والذي يحتوي على الفترة الزمنية المطلوبة عندما تقوم بالاستعلام عن البيانات لتصيير الرسوم البيانيّة. تجميع وتسليم الإحصائيات كما أشرنا سابقًا لا تهتم Graphite بجمع البيانات بنفسها، بل تعتمد بدلًا من ذلك على تزويدها بالمعلومات من قبل خدمات أخرى، يسمح هذا للمشروع بأن يحافظ على تركيزه وأن يتفاعل بشكل مُجزّأ مع خدمات الدخل input. سنناقش الآن الموافيق protocols التي تفهمها Graphite، وسنتحدّث بعدها عن برنامجين شائعين للجمع، وهما collectd و StatsD، والتي يمكن استخدامها لتمرير البيانات إلى Carbon من أجل المعالجة. الموافيق Protocols توجد ثلاث موافيق مختلفة نستطيع استخدامها لإرسال البيانات إلى Graphite. أولًا تقبل وتفهم Graphite النصوص المُجرّدة، وهو التنسيق الأكثر مرونة لأنّ أي تطبيق أو خدمة تقريبًا يستطيع إخراج نصوص والتي يمكن استخدامها كي نعطيها إلى Graphite أو أداة وسيطة ما. تتضمّن رسائل النصوص المُجرّدة معلومات حول اسم المقياس، القيمة المعطاة، وختم زمني لأجل تلك القيمة، يمكن إرسال تلك الرسائل مباشرة إلى Carbon على منفذ مصمّم لأجل النصوص المُجرّدة بدون أي تنسيق إضافي. ولأنّه تم إنشاء Graphite باستخدام لغة بايثون فهي تقبل أيضًا تنسيق البيانات التسلسلي "pickle"، يسمح لنا هذا التنسيق المعياري لبايثون بالاحتفاظ مؤقّتًا بقيم زمنية متعدّدة وإرسالها في تعامل واحد. تستطيع Graphite أيضًا أن تقبل البيانات باستخدام رسائل AMQP، تسمح لنا هذه بالتعامل مع أحمال كبيرة للبيانات بشكل أفضل، نستطيع مع هذا الإعداد إعطاء عدد كبير من الإحصائيات والتعامل مع انقطاعات اتصالات الشبكة بين المضيفين عن بُعد remote hosts بدون خسارة البيانات. Collectd من أبسط طرق جمع معلومات مفصّلة حول خادوم ما هي باستخدام عفريت يُدعى collectd. بإمكان collectd تجميع إحصائيّات حول العديد من المكونات المختلفة لبيئة الخادوم، فهي تسمح لنا بسهولة بتتبّع المقاييس الشائعة مثل استخدام الذاكرة، حمل المعالج CPU load، حركة مرور البيانات عبر الشبكة network traffic، إلخ..، يسمح لنا هذا بسهولة بربط الأحداث مع حالة أنظمتنا. وبغض النظر عن جمع معلومات النظام المعياريّة تمتلك collectd نظام إضافات يوسّع من وظيفتها، يعني هذا أنّه يمكننا بسهولة تتبّع البرمجيّات الشائعة مثل Apache ،Nginx ،iptables ،memcache ،MySQL ،PostgreSQL ،OpenVPN، وغيرها. تزوّدنا collectd بطريقة مبسّطة للحصول على البيانات من التطبيقات المبنيّة مسبقًا والخدمات الشائعة على خادومنا، ويجب استخدامها لتتبّع سلوك البنية التحتيّة والخدمات التي نعتمد عليها. StatsD إنّ StatsD هي عبارة عن عفريت بسيط يمكن استخدامه لإرسال البيانات الأخرى إلى Graphite، الفائدة من هذا النهج هو أنّه يصبح من البديهي بناء تتبّع إحصائيّات للتطبيقات والأنظمة التي نقوم بإنشائها. تعمل StatsD عن طريق الاستماع على الواجهة إلى رُزَم UDP البسيطة التي تمثّل نقطة بيانات مفردة، يعني هذا أنّها تقبل كميّة هائلة من المعلومات بطريقة لا تحتاج للاتصال، وبعدها تستطيع تجميع القيم التي تتلقّاها وتمررّها إلى Graphite. يسمح لنا هذا النظام بإرسال الإحصائيّات بكميّات كبيرة بدون القلق حول زيادة زمن الوصول إلى التطبيق، تجمع خدمة StatsD كافّة البيانات كما وصلتها، تجمّعها، ومن ثمّ ترسل نقاط بيانات ملخصة وجميلة إلى Graphite بالإطار الزمني المتوقّع. وبسبب هذه الميّزات فهي فعليًّا وسيط جيّد لأي نوع من البيانات المرسلة إلى Graphite، ولكن الطريقة الأساسيّة التي يمكننا الاستفادة منها بفعاليّة هي مراقبة تطبيقاتنا الخاصّة والأدوات التي نقوم بإنشائها. تكون StatsD مثاليّة لهذا لأنّها عفريت ذو غرض عام يقبل حركة مرور بيانات UDP، هناك العديد من المكتبات المختلفة التي تعمل من جهة العميل client-side في العديد من لغات البرمجة والتي بإمكانها إرسال البيانات إلى StatsD، يعني هذا أنّه يمكن للتطبيقات التي نبنيها إرسال البيانات بسهولة من أجل تتبّعها. الخاتمة يجب أن تملك الآن فهمًا جيّدًا كيف أنّه يمكن لمجموعة مختلفة من الإحصائيّات وأدوات الرسم البياني العمل معًا لإعطاء صورة كاملة عن نظامك. ترجمة -وبتصرف- للمقال An Introduction to Tracking Statistics with Graphite, StatsD, and CollectD لصاحبه Justin Ellingwood.