تحياتي للجميع! أعمل مهندس نظم في
أونلانتا . في أحد مشاريعنا ، شاركت في تنفيذ وصيانة المكدس المرن. لقد انتقلنا من جمع السجلات يدويًا تقريبًا إلى عملية مركزية ومؤتمتة. لمدة عامين حتى الآن ، لم نغير عمليا بنية الحل ونخطط لاستخدام أداة مناسبة في مشاريع أخرى. أشارككم تاريخنا في تنفيذه ، بالإضافة إلى بعض نقاط القوة والضعف في هذا المنشور.
المصدرفي بداية عام 2016 ، كانت سجلات المسؤولين والمطورين لدينا ، كما يقولون ، "في متناول يدك" ، أي مهندس للعمل معهم متصلاً عبر SSH بالمضيف حيث كانت الخدمة التي كان مهتمًا بها ، كشفت المجموعة العالمية من الذيل / grep / sed / awk وأعرب عن أمله في أن يكون من الممكن العثور على البيانات اللازمة على هذا المضيف.
المصدركان لدينا أيضًا خادم منفصل ، حيث تم تحميل جميع الدلائل التي تحتوي على سجلات من جميع الخوادم عبر NFS ، والتي كان يُعتقد أحيانًا لفترة طويلة حول ما يريد الجميع القيام به مع السجلات الموجودة عليه. حسنًا ، بدت tmux مع العديد من الألواح التي تعمل على بعض السجلات التي تم تحديثها بنشاط مثيرة للإعجاب للغاية بالنسبة للغرباء على شاشة كبيرة وخلق جوًا مثيرًا من المشاركة في أسرار الإنتاج.
كل هذا نجح ، ولكن بالضبط حتى كان من الضروري معالجة كمية كبيرة من البيانات بسرعة ، وكان هذا مطلوبًا في أغلب الأحيان في اللحظات التي سقط فيها شيء ما في المنتج.
في بعض الأحيان ، استغرق التحقيق في الحوادث وقتًا غير لائق. تم إنفاق جزء كبير منه على التجميع اليدوي للسجلات ، وإطلاق
عكازات من نصوص مختلفة في Bash و Python ، في انتظار تحميل السجلات في مكان ما للتحليل ، إلخ.
باختصار ، كان كل هذا بطيئًا جدًا ، مستوحى من اليأس وألمح بشكل لا لبس فيه إلى أن الوقت قد حان للحضور إلى التخزين المركزي للسجلات.
لنكون صادقين ، لم تكن هناك عملية معقدة لاختيار المرشحين لدور المكدس التكنولوجي الذي سيضمن ذلك لنا: ثم كانت حزمة ELK شائعة بالفعل في ذلك الوقت ، ولديها وثائق جيدة ، وكان هناك عدد كبير من المقالات على الإنترنت لجميع المكونات. كان القرار فوريًا: عليك المحاولة.
المصدرتم التثبيت الأول للمكدس بعد مشاهدة البرنامج التعليمي على الويب "Logstash: 0-60 in 60" على ثلاثة أجهزة افتراضية ، أطلق كل منها مثيلًا من Elasticsearch و Logstash و Kibana.
علاوة على ذلك ، واجهنا بعض المشكلات في تسليم السجلات من المضيفين النهائيين إلى خوادم Logstash. والحقيقة هي أن Filebeat في ذلك الوقت (حل مكدس قياسي لتسليم السجلات من الملفات النصية) عمل بشكل أسوأ بكثير مع الملفات الكبيرة التي يتم تحديثها بسرعة ، والتي يتم تسريبها بانتظام في ذاكرة الوصول العشوائي وفي حالتنا ككل لا يمكنها التعامل مع مهمتها.
تمت إضافة هذا إلى الحاجة إلى إيجاد طريقة لتسليم سجلات خادم التطبيقات من الأجهزة التي تقوم بتشغيل IBM AIX: ثم تم إطلاق الجزء الأكبر من تطبيقاتنا في WebSphere Application Server ، والتي عملت على وجه التحديد في ظل نظام التشغيل هذا. Filebeat مكتوب في Go ، لم يكن هناك أكثر أو أقل كفاءة مترجم Go لـ AIX في عام 2016 ، ولم أرغب حقًا في استخدام Logstash كوكيل للتسليم.
لقد اختبرنا العديد من وكلاء تسليم السجلات: Filebeat و logstash-forwarder-java و
log-courier و python-beaver و NXLog. من الوكلاء ، توقعنا أداءً عاليًا واستهلاكًا منخفضًا لموارد النظام والتكامل السهل مع Logstash والقدرة على إجراء معالجة البيانات الأساسية مع قوى الوكيل (على سبيل المثال ، تجميع الأحداث متعددة الخطوط).
حول تجميع الأحداث متعددة الخطوط ، تجدر الإشارة بشكل منفصل. بشكل فعال ، لا يمكن تنفيذه إلا من جانب الوكيل الذي يقرأ ملفًا معينًا. على الرغم من حقيقة أن Logstash كان يحتوي على مرشح متعدد الأسطر ، ولديه الآن برنامج ترميز متعدد الأسطر ، فشلت جميع محاولاتنا لدمج موازنة الأحداث عبر العديد من خوادم Logstash مع المعالجة متعددة الخطوط. هذا التكوين يجعل موازنة الحدث الفعال يكاد يكون مستحيلاً ، وبالتالي ، بالنسبة لنا ، كان العامل الأكثر أهمية عند اختيار الوكلاء هو الدعم متعدد الخطوط.
كان الفائزون كما يلي: log-courier for machines with Linux، NXLog for machines with AIX. مع هذا التكوين ، عشنا لمدة عام تقريبًا دون أي مشاكل: تم تسليم السجلات ، ولم يسقط العملاء (جيدًا ، تقريبًا) ، كان الجميع سعداء.
في أكتوبر 2016 ، تم إصدار الإصدار الخامس من مكونات المكدس المرن ، بما في ذلك Beats 5.0. تم عمل الكثير على جميع وكلاء Beats في هذا الإصدار ، وتمكنا من استبدال ناقل السجل (الذي كان لديه في ذلك الوقت مشاكله الخاصة) مع Filebeat ، التي لا نزال نستخدمها.
عند الترحيل إلى الإصدار 5.0 ، بدأنا في جمع ليس فقط السجلات ، ولكن أيضًا بعض المقاييس: بدأ استخدام Packetbeat هنا وهناك كبديل لكتابة سجلات طلب HTTP إلى الملفات ، وجمع Metricbeat مقاييس النظام ومقاييس بعض الخدمات.
في هذه المرحلة ، أصبح عمل مهندسينا مع السجلات أكثر بساطة: الآن لم تكن هناك حاجة لمعرفة الخادم الذي يجب الذهاب إليه لمشاهدة السجل الذي تهتم به ، وتم تبسيط تبادل المعلومات التي تم العثور عليها لنقل الرابط إلى Kibana ببساطة في غرف الدردشة أو البريد ، والتقارير التي تم إنشاؤها سابقًا في غضون ساعات قليلة ، بدأ يتم إنشاؤه في بضع ثوانٍ. لا يمكن القول أن الأمر كان مجرد مسألة راحة: لقد لاحظنا تغييرات في جودة عملنا ، في كمية ونوعية المهام المغلقة ، في سرعة الاستجابة للمشاكل في مواقفنا.
في مرحلة ما ، بدأنا في استخدام الأداة المساعدة ElastAlert من Yelp لإرسال تنبيهات إلى المهندسين. ثم فكرنا: لماذا لا ندمجها مع Zabbix بحيث تكون جميع التنبيهات ذات تنسيق قياسي ويتم إرسالها مركزيًا؟ تم العثور على الحل بسرعة كبيرة: يتيح لك ElastAlert تشغيل أي أوامر بدلاً من إرسال التنبيهات ، التي استخدمناها.
الآن عند تنفيذ قواعد ElastAlert الخاصة بنا ، قم بتنفيذ برنامج نصي bash على عدة أسطر ، حيث يتم تمرير البيانات الضرورية في الوسائط من الحدث الذي أدى إلى تشغيل القاعدة ، ويتم استدعاء zabbix_sender من البرنامج النصي ، الذي يرسل البيانات إلى Zabbix للعقدة المطلوبة.
نظرًا لأن جميع المعلومات حول من أنشأ الحدث وأين تكون متاحة دائمًا في Elasticsearch ، لم تكن هناك صعوبات في التكامل. على سبيل المثال ، كان لدينا سابقًا آلية للكشف التلقائي عن خوادم تطبيقات WAS ، وفي الأحداث التي يتم إنشاؤها ، يتم دائمًا كتابة اسم الخادم أو الكتلة أو الخلية وما إلى ذلك. هذا سمح لنا باستخدام خيار query_key في قواعد ElastAlert بحيث تتم معالجة شروط القواعد لكل خادم على حدة. ثم يحصل البرنامج النصي الذي يحتوي على zabbix_sender على "إحداثيات" الخادم بالضبط ويتم إرسال البيانات إلى Zabbix للعقدة المقابلة.
الحل الآخر الذي نحبه حقًا والذي أصبح ممكنًا بفضل المجموعة المركزية من السجلات هو برنامج نصي لإنشاء المهام تلقائيًا في JIRA: مرة واحدة في اليوم ، يقوم بأخذ جميع الأخطاء من السجلات ، وإذا لم تكن هناك مهام حتى الآن ، يبدأ تشغيلها. في نفس الوقت ، من فهارس مختلفة بمعرف طلب فريد ، يتم سحب جميع المعلومات التي يمكن أن تكون مفيدة في التحقيق إلى المهمة. والنتيجة هي نوع من قطع العمل القياسية مع الحد الأدنى من المعلومات الضرورية ، والتي يمكن للمهندسين عندئذ استكمالها إذا لزم الأمر.
بالطبع ، واجهنا مشكلة مراقبة المكدس نفسه. يتم تنفيذ ذلك جزئيًا باستخدام Zabbix ، جزئيًا باستخدام نفس ElastAlert ، ونحصل على مقاييس الأداء الرئيسية لـ Elasticsearch و Logstash و Kibana باستخدام المراقبة القياسية المضمنة في المكدس (مكون المراقبة في X-Pack). أيضًا ، على الخوادم التي تحتوي على خدمات المكدس نفسها ، قمنا بتثبيت
netdata من Firehol. إنه مفيد عندما تحتاج إلى رؤية ما يحدث لعُقدة معينة في الوقت الحالي وبدقة عالية.
ذات مرة ، تم كسر وحدة مراقبة Elasticsearch قليلاً ، وجدناها ، أصلحها ، أضفنا جميع أنواع المقاييس المفيدة وقدمنا طلب سحب. حتى الآن يمكن لـ netdata مراقبة أحدث إصدارات Elasticsearch ، بما في ذلك مقاييس JVM الأساسية ، والفهرسة ، ومؤشرات أداء البحث ، وإحصاءات سجل المعاملات ، وشرائح الفهرس ، وما إلى ذلك. نحن نحب Netdata ، ويسرنا أننا تمكنا من تقديم مساهمة صغيرة لها.
اليوم ، بعد ما يقرب من ثلاث سنوات ، يبدو مرننا المكدس مثل هذا:
يعمل المهندسون مع المكدس بثلاث طرق رئيسية:
- عرض وتحليل السجلات والمقاييس في كيبانا ؛
- لوحات العدادات في جرافانا وكيبانا ؛
- استعلامات مباشرة إلى Elasticsearch باستخدام SQL أو الاستعلام المدمج DSL.
في المجموع ، يتم تخصيص جميع هذه الموارد: 146 وحدة المعالجة المركزية ، و 484 جيجابايت من ذاكرة الوصول العشوائي ، و 17 تيرابايت يتم تخصيصها لمستودع بيانات Elasticsearch.
في المجمل ، لدينا 13 جهازًا افتراضيًا تعمل كجزء من المكدس المرن: 4 أجهزة للعقد Elasticearch "الساخنة" ، و 4 للعقد "الدافئة" ، و 4 أجهزة مع Logstash وآلة موازنة واحدة. في كل عقدة ساخنة ، تدير Elasticsearch مثيل Kibana. حدث ذلك منذ البداية ، وحتى الآن لم نضطر إلى نقل كيبانا لفصل السيارات.
لكن قرار أخذ Logstash لفصل الأجهزة تبين أنه واحد من الأكثر صحة وفعالية أثناء تشغيل المكدس: أدى التنافس الشديد على وقت المعالج بين JVM Elasticsearch و Logstash إلى تأثيرات خاصة غير ممتعة للغاية أثناء رشقات الحمل. عانى جامعو القمامة أكثر من غيرها.
المصدرنقوم بتخزين البيانات لآخر 30 يومًا في المجموعة: الآن حوالي 12 مليار حدث. بشكل يومي ، تكتب العقد الساخنة إلى البيانات الجديدة على القرص سعة 400-500 جيجا بايت مع نسبة ضغط قصوى (بما في ذلك بيانات النسخ المتماثلة). تتميز مجموعة Elasticsearch الخاصة بنا بهندسة ساخنة / دافئة ، ولكننا قمنا بالتبديل إليها مؤخرًا نسبيًا ، لذا لا يزال يتم تخزين بيانات أقل على العقد "الدافئة" مقارنة بالعقد "الساخنة".
عبء العمل النموذجي لدينا:
- الفهرسة - بمتوسط 13000 rps مع قمم تصل إلى 30.000 (باستثناء الفهرسة إلى أجزاء متماثلة) ؛
- البحث - 5200 rps.
نحن نحاول الحفاظ على هامش وحدة المعالجة المركزية 40-50٪ على العقد الساخنة Elasticsearch حتى نتمكن بسهولة من مواجهة الارتفاع المفاجئ في عدد الأحداث المفهرسة والطلبات الثقيلة من كيبانا / جرافانا أو أنظمة المراقبة الخارجية. حوالي 50٪ من ذاكرة الوصول العشوائي (RAM) على الأجهزة المضيفة التي تحتوي على عُقد Elasticsearch متاحة دائمًا لذاكرة التخزين المؤقت للصفحة واحتياجات التخزين غير المباشر ل JVM.
خلال الوقت المنقضي منذ إطلاق المجموعة الأولى ، تمكنا من تحديد بعض الجوانب الإيجابية والسلبية لـ Elastic Stack كوسيلة لتجميع السجلات ومنصة البحث والتحليل.
ما نحبه بشكل خاص حول المكدس:- نظام بيئي واحد من المنتجات يتكامل بشكل جيد مع بعضها البعض ، والذي يحتوي على كل ما تحتاجه تقريبًا. لم تكن الضربات جيدة في يوم من الأيام ، ولكن ليس لدينا الآن شكاوى بشأنها.
- Logstash ، بكل ما تتسم به من بساطة ، هو معالج مرن وقوي للغاية ويسمح لك بالقيام بالكثير بالبيانات الأولية (وإذا كان هناك شيء لا يسمح بذلك ، يمكنك دائمًا كتابة مقتطف في Ruby).
- يدعم Elasticsearch مع المكونات الإضافية (ومؤخرا خارج الصندوق) SQL كلغة استعلام ، مما يبسط تكاملها مع البرامج الأخرى والأشخاص الأقرب إلى SQL كلغة استعلام.
- وثائق عالية الجودة تسمح لك بتقديم موظفين جدد إلى المشروع بسرعة. وبالتالي ، فإن تشغيل المكدس لا يصبح عملاً لشخص واحد لديه بعض الخبرة المحددة و "المعرفة السرية".
- ليست هناك حاجة إلى أن تعرف مقدمًا عن بنية البيانات المستلمة لبدء جمعها كثيرًا: يمكنك البدء في تجميع الأحداث كما هي ، وبعد ذلك ، بينما تفهم المعلومات المفيدة التي يمكنك استخراجها منها ، قم بتغيير نهج معالجتها دون فقدان "التوافق مع الإصدارات السابقة". هناك العديد من الأدوات الملائمة على المكدس لهذا: الأسماء المستعارة للحقول في الفهارس ، الحقول النصية ، إلخ.
- يتم توزيع مكونات X-Pack فقط وفقًا لنموذج الاشتراك ولا شيء آخر: إذا كان من Gold ، على سبيل المثال ، يدعم فقط تقارير RBAC أو PDF ، فسيتعين عليك الدفع مقابل كل ما يمتلكه Gold. هذا أمر محبط بشكل خاص عندما تحتاج ، على سبيل المثال ، فقط إلى رسم بياني من Platinum ، و Machine Learning ومجموعة أخرى من الوظائف الأخرى التي قد لا تحتاجها متاحة للشراء. محاولاتنا للتواصل مع قسم المبيعات المرنة حول ترخيص مكونات X-Pack الفردية قبل عام تقريبًا لم تؤد إلى أي شيء ، ولكن ربما تغير شيء ما منذ ذلك الحين.
- إصدارات متكررة إلى حد ما يتم فيها كسر التوافق العكسي بطريقة ما (في كل مرة جديدة). يجب عليك قراءة سجل التغيير بعناية فائقة والاستعداد للتحديثات مقدمًا. في كل مرة تحتاج إلى الاختيار: ابق على الإصدار القديم ، الذي يعمل بثبات ، أو حاول الترقية للحصول على ميزات جديدة ومكاسب في الأداء.
بشكل عام ، نحن سعداء جدًا بخيارنا الذي تم إجراؤه في عام 2016 ، ونخطط لنقل تجربة تشغيل نظام Stack المرن إلى مشاريعنا الأخرى: الأدوات التي توفرها المجموعة مكدسة بإحكام في سير عملنا وسيكون من الصعب جدًا رفضها الآن.
وأيضا في شركتنا عدد من الوظائف الشاغرة مفتوحة.