يتم عرض عدد كبير من أنظمة تسجيل الدخول في السوق - سواء المفتوحة أو المملوكة. كل واحد منهم لديه وظائفه الخاصة ، ومزاياه وعيوبه.
قررنا اليوم مشاركة تجربتنا في اختيار نظام تسجيل وإخبارنا عن سبب توقفنا في ELK في
1cloud .
/ Pixabay / picupyourphoto / PDنظرية الدقائق
عند التحول إلى الإنتاج ، تتحول التطبيقات إلى نوع من "الصناديق السوداء". يحتاج عملهم إلى المراقبة المستمرة لمنع حالات الطوارئ المحتملة والاستجابة لها ، لاكتشاف الاختناقات.
أنظمة التسجيل هي أداة لا غنى عنها ولا يمكن تجنبها في هذه العملية. من خلال إجراء تحليل مفصل للبيانات التي تم جمعها ، من الممكن تحديد "التدخلات" في الشبكة ، وتحديد المعدات التي تم تكوينها بشكل غير صحيح ، واتخاذ إجراءات فورية. أيضًا ، يعد التسجيل شرطًا إلزاميًا عند اجتياز أنواع مختلفة من الشهادات ، مثل PCI DSS.
هناك أطر عمل خاصة لأتمتة عمليات التسجيل: log4j و log4net و Retrace و Logback و Logstash وغيرها - هناك الكثير منها. أدوات التسجيل لديها أدوات تطوير منفصلة ، على سبيل المثال JDK -
هناك java.util.logging . بالطبع ، تختلف وظائف أدوات التسجيل المختلفة ، ويجب تحديد المجموعة اللازمة من الوظائف بناءً على متطلبات العمل. ومع ذلك ، هناك عدد من النقاط العامة التي يجب ملاحظتها عند اختيار نظام لتحليل السجلات.
سهولة الاستخدام وحجم المجتمع
البساطة هي أحد المكونات الرئيسية عند اختيار نظام تسجيل. يعمل جميع المطورين في الفريق مع أطر عمل السجل ، لذلك يجب أن تكون تجربة استخدام هذه الأداة إيجابية ولا تحول تحليل السجل إلى كابوس. يجب أن تكون واجهة برمجة تطبيقات إطار العمل بديهية بحيث يمكن لأي شخص لم يعمل مع النظام من قبل معرفة كيفية تنظيمه وتكوينه بسرعة.
إذا أخذنا في الاعتبار نظام تسجيل المصدر المفتوح ، فمن المنطقي تقييم المجتمع الذي تشكل حوله. للقيام بذلك ، يمكنك دراسة عدد المرات التي يتم ذكرها على الأنظمة الأساسية المتخصصة (
Stack Overflow ) ، وكذلك في سلاسل الرسائل المتخصصة ،
على سبيل المثال ، على Reddit . كخيار ، انظر إلى شعبية المشروع على GitHub (عدد النجوم) وشاهد عدد مرات إدخاله في مجموعات مختلفة من الأدوات على الشبكة (
مثل هذه ). من الواضح أنه كلما كان المجتمع أكبر ، كلما زاد احتمال حصولك على مساعدة في حالة وجود صعوبات غير متوقعة.
فيما يتعلق باختيار أنظمة تسجيل الملكية ، هنا أولاً وقبل كل شيء ، يجدر النظر في سرعة الإجابات وكفاية خدمة الدعم للحل المختار ، وكذلك سعره.
القدرة على جمع سجلات "متنوعة"
ليست كل منصات التسجيل قادرة على معالجة كمية كبيرة من البيانات وتقديم معلومات كاملة حول الأنظمة المستخدمة.
قبل اختيار الحل ، يجدر تحديد السجلات التي تخطط لجمعها: سجلات HTTP (ستساعد في فهم سلوك المستخدمين على الموقع) ، وسجلات API (ستجعل من الممكن تقييم الخدمات التي تطلبها غالبًا واجهة برمجة التطبيقات) ، وسجلات الأخطاء ، وتسجيل التغييرات ببساطة إلى النظام (حدد الاختناقات ، إن وجدت).
قابلية التوسع
يجب أن تقوم أداة التسجيل بجمع السجلات من كل مكون من مكونات النظام وتوفير الوصول إليها في مكان واحد. إذا كان النظام غير مناسب للتحجيم ، فسوف تنخفض جودة تحليل السجل.
نحن في 1cloud استخدمنا في البداية MS SQL لتسجيل الدخول. ومع ذلك ، مع زيادة عدد العملاء والخدمات (على سبيل المثال ،
قمنا مؤخرًا
بنشر المعدات في مركز بيانات مينسك وإضافة دعم IPv6 ) ، قمنا بتوزيع مكونات البنية التحتية جغرافيًا التي لم يكن لديها إمكانية الوصول إلى قاعدة البيانات. وكانت إحدى مهامنا الرئيسية الحفاظ على القدرة على تحليل السجلات من مكان واحد.
نظام تسجيل 1cloud
كما ذكرنا من قبل ، تم استخدام MS SQL لتخزين السجلات في 1cloud ، وتم استخدام log4net لتسجيلها. وقد بدأ هذا يخلق لنا بعض الصعوبات. نظرًا للمكونات المتناثرة جغرافيًا ، أصبح من المستحيل الحفاظ على اتصال الشبكة بقاعدة البيانات وتوفير نقطة واحدة للتحليل.
في الوقت نفسه ، أدى حجم كبير من السجلات وعدم القدرة على إنشاء فهارس على جميع الحقول التي نحتاج إلى البحث عنها إلى تبسيط مفرط لتحليل السجلات - كان علينا التخلي عن الوظائف من أجل الأداء.
لحل هذه المشكلة وتوفير قابلية التوسع ، قدمنا نظام تسجيل جديد. في المجموع ، درسنا أكثر من خمسين حلًا مختلفًا وحددنا أربعة حلول تلبي متطلباتنا بالكامل:
- مكان واحد لتخزين السجلات ؛
- التحجيم الأفقي للنظام إذا لزم الأمر ؛
- معالجة كميات كبيرة من البيانات ؛
- نظام تحليل سجل قوي.
هذه الحلول الأربعة هي: Fluentd و Graylog و Logalyse و Logstash.
يحتوي الحل على 9.2 ألف نجمة على
GitHub . تم ترخيص Logstash بموجب ترخيص Apache 2.0 وهو جزء من مكدس ELK. يحتوي على عدد كبير من المكونات الإضافية (
هناك حوالي 250 منها على GitHub). يعمل تحت نظامي التشغيل Windows و Linux ولديه أداء عالٍ ، وهو عمليًا مستقل عن أحجام البيانات.
يتيح لك النظام مراجعة الأحداث بسرعة من محطات العمل وجدران الحماية وأجهزة التوجيه والمحولات وتحليلها بسرعة. هذا يرجع إلى حقيقة أنه لا توجد حاجة "لتطبيع" الأحداث.
ومع ذلك ، يجب أن يُفهم أن هذا محرك "مكشوف" ، لأنه لا يوفر تصورات جاهزة. من بين أوجه القصور الأخرى ، نلاحظ الحاجة إلى تثبيت Java على جميع الخوادم ، حيث أن Logstash مكتوب بلغة Ruby (JRuby).
يحتوي الحل على مجتمع كبير إلى حد ما: هناك
قناة IRC ومنتدى منفصل. هناك أمثلة على الشبكة
لتكوين النظام بأكمله و
API .
تستخدم المؤسسات التالية Logstash: CERN Control Center و GitHub و SoundCloud.
6.6 ألف نجمة على
جيثب . تم توزيعه بموجب ترخيص Apache 2.0 من قبل
CNCF (Cloud Native Computing Foundation) - تم
تأسيسه بواسطة Google و The Linux Foundation لتعزيز تقنية الحاويات.
يعمل Fluentd على Linux و Windows و Mac وهو مكتوب بلغة Ruby (CRuby). لدى Fluentd
نظام إضافي مرن يعمل على توسيع وظائفه.
يحتوي الحل على تنسيق تسجيل موحد: يحاول Fluentd تحويل البيانات المستلمة إلى تنسيق JSON. لضمان تشغيل موثوق به ، ليست هناك حاجة إلى حلول خارجية ، لذلك ، من الضروري إجراء تكوين إضافي. لا يوصى أيضًا بتثبيته على الخوادم التي تنشئ السجلات.
المجتمع كبير: هناك
قناة في Slack ، بالإضافة إلى سلسلة
محادثات في مجموعات Google . على الموقع الرسمي للمشروع
هناك أمثلة على التكوينات وواجهات برمجة التطبيقات . تستخدم شركات مثل Microsoft و Amazon و change.org و Nintendo Fluentd.
4.3 ألف نجمة على
جيثب . تم التوزيع بموجب ترخيص GNU GPL v3. يعمل فقط في لينكس. نظام
بيئي مركزي
من المكونات الإضافية ونظام التخزين المؤقت المخصص. من أجل الراحة ، فإنه يسمح للكلمة الرئيسية بدمج الرسائل الواردة في التدفقات وتجميع هذه التدفقات من مضيفين مختلفين.
يستخدم النظام وظائف Elasticsearch ، ولكن على الرغم من التحديثات المتكررة لـ Graylog والمجتمع المطور (هناك
منتدى وقناة IRC ،
وهناك أمثلة على التكوينات وواجهات برمجة التطبيقات على موقع الويب الرسمي للمشروع) ، فإن دمج الإصدارات الحالية من Elasticsearch في المشروع يستغرق وقتًا طويلاً. على سبيل المثال ، في العام الماضي نشأ موقف حيث كان Graylog 2.2.1 (الأخير في ذلك الوقت)
يعمل فقط مع الإصدار 2.4.4 من Elasticsearch ، والذي كان يعتبر قديمًا.
تستخدم Graylog في عملها وكالة البيئة الأوروبية ، Dial مرة واحدة ، Stockopedia وغيرها.
يعمل تحت لينكس وويندوز. يتمتع النظام بأداء عالٍ ويمكنه إنشاء تقارير تفصيلية حول الكلمات الرئيسية. هناك عيب خطير - يقوم LOGalyze بتجميع السجلات في قاعدة بيانات الملفات الخاصة به ، حيث يقوم بعد ذلك بفهرستها ، مما يشغل مساحة كبيرة من القرص.
يمتلك مطورو LOGalyze مدونتهم
الخاصة ، وتجري مناقشة الحل في
مجموعات Google . يوجد دليل
لتكوين النظام
وترحيل البيانات ، بالإضافة إلى
CLI .
بعد تقييم هذه الخيارات الأربعة ، اخترنا Logstash وقررنا تنظيم مجموعة ELK (ElasticSearch و Logstash و Kibana). من بين هذه ، يعتبر Elasticsearch محرك بحث ، و Logstash هي آلية لجمع وتحليل السجلات ، وتشارك Kibana في التحليلات وتصور البيانات.
لقد اخترنا ELK ، نظرًا لأن المكونات الثلاثة تم تطويرها بواسطة "جهة تصنيع" واحدة ، وبالتالي فهي تتكامل جيدًا مع بعضها البعض. إذا لزم الأمر ، يمكننا استخدام كل من هذه الأدوات بشكل فردي لحل مشاكل أخرى.
هذا النهج يجعل المنتج مرنًا ومتعدد الاستخدامات. كل هذا سيسمح بمعالجة أكثر كفاءة لأحجام البيانات الحالية وتنفيذ أسرع للخدمات الجديدة - سيكون من الأسهل الاتصال.
الآن بيئة الاختبار جاهزة. إنه "يغطي" جميع الخدمات التي سنقوم بتحليل سجلاتها. نحن ننهي عمليات التصحيح الأخيرة ونخطط لإطلاق كامل للحل في المستقبل القريب.
بالمناسبة ، على الرغم من حقيقة أننا قمنا بتحليل الخيارات المختلفة بالتفصيل واخترنا الأفضل لاحتياجاتنا ، في النهاية لم يكن بدون ذبابة في المرهم. عند اختبار الحل ، واجهنا موقفًا أسقطت فيه Kibana Elasticsearch حسب الطلب - والذي يعتبر حالة نادرة للغاية ومتدهورة. أيضا خلال "تجميع" النظام ، أثير عدد من الأسئلة ، تتعلق أساسا بالأمن. في الإصدار الأساسي ، لا يكون Elasticsearch محميًا بأي شيء - كان من الضروري تكييف برامج الجهات الخارجية لهذه الأغراض.
بعد الإطلاق ، سنقوم بإعداد أنظمة مراقبة للاستجابة بأسرع ما يمكن للإخفاقات في خدمة السجل. نأمل أن تعمل حزمة التكنولوجيا الجديدة على تحسين تجربة المستخدم لعملائنا وتطوير خدماتنا بشكل أسرع.
المواد من مدونة شركتنا: