تعد السجلات جزءًا مهمًا من النظام ، مما يسمح لك بفهم أنه يعمل (أو لا يعمل) كما هو متوقع. في ظل ظروف بنية الخدمات المصغرة ، يصبح العمل مع السجلات تخصصًا منفصلاً في الأولمبياد الخاص. هناك الكثير من المشكلات التي تحتاج إلى معالجة:
- كيفية كتابة السجلات من التطبيق ؛
- أين تكتب السجلات.
- كيفية تسليم السجلات للتخزين والمعالجة ؛
- كيفية معالجة السجلات وتخزينها.
يضيف استخدام تقنيات النقل بالحاويات الشائعة حاليًا رمالًا على قمة أشعل النار في مجال خيارات حل المشكلات.
هذا هو نص تقرير يوري بوشيليف "خريطة أشعل النار في مجال جمع الأخشاب وتسليمها"
من يهتم ، من فضلك تحت القط.
اسمي يوري بوشميلف. أعمل لدى Lazada. سأتحدث اليوم عن كيفية صنعنا لسجلاتنا ، وكيف جمعناها ، وما نكتبه هناك.
من اين نحن؟ من نحن؟ Lazada هو بائع التجزئة الأول عبر الإنترنت في ستة بلدان في جنوب شرق آسيا. يتم توزيع كل هذه البلدان بين مراكز البيانات. يوجد الآن إجمالي 1 مراكز بيانات ، ما أهمية ذلك؟ لأن بعض القرارات كانت بسبب ضعف الارتباط بين المراكز. لدينا بنية الخدمات المصغرة. لقد فوجئت عندما اكتشفت أن لدينا بالفعل 4 خدمة مصغرة. عندما بدأت المهمة مع السجلات ، كان هناك 80 منهم فقط.بالإضافة إلى ذلك ، هناك جزء كبير إلى حد ما من تراث PHP ، والذي يجب علي أيضًا التعايش معه والتعامل معه. كل هذا يولد لنا في الوقت الحالي أكثر من 20 ملايين رسالة في الدقيقة للنظام ككل. علاوة على ذلك ، سأوضح كيف نحاول التعايش مع هذا ، ولماذا يحدث هذا.
عليك أن تعيش مع هذه الـ 6 ملايين رسالة بطريقة ما. ماذا نفعل معهم؟ مطلوب 6 ملايين رسالة:
- أرسل من التطبيق
- قبول للتسليم
- تسليم للتحليل والتخزين.
- تحليل
- تخزين بطريقة ما.
عندما كان هناك ثلاثة ملايين رسالة ، كان لدي نفس المظهر تقريبًا. لأننا بدأنا ببعض البنسات. من الواضح أن سجلات التطبيق مكتوبة هناك. على سبيل المثال ، لا يمكن الاتصال بقاعدة البيانات ، ويمكن الاتصال بقاعدة البيانات ، ولكن لا يمكن قراءة شيء ما. ولكن بالإضافة إلى ذلك ، تكتب كل خدمة من خدماتنا المصغرة أيضًا سجل وصول. يقع كل طلب يصل إلى الخدمة المصغرة في السجل. لماذا نفعل ذلك؟ يريد المطورون أن يكونوا قادرين على التتبع. يحتوي كل سجل وصول على حقل traceid ، والذي بموجبه تقوم واجهة خاصة بفك السلسلة بأكملها وتعرض التتبع بشكل جميل. يوضح التتبع كيف سار الطلب ، وهذا يساعد مطورينا على التعامل مع أي قمامة غير معروفة بشكل أسرع.
كيف تتعايش معها؟ الآن سوف أصف بإيجاز مجال الخيارات - كيف يتم حل هذه المشكلة بشكل عام. كيفية حل مشكلة جمع السجلات ونقلها وتخزينها.
كيف تكتب من التطبيق؟ من الواضح أن هناك طرقًا مختلفة. على وجه الخصوص ، هناك أفضل الممارسات ، كما يخبرنا الرفاق العصريون. هناك نوعان من المدارس القديمة كما قال الأجداد. هناك طرق أخرى.
مع جمع السجلات ، يكون الوضع متماثلًا تقريبًا. لا توجد الكثير من الخيارات لحل هذا الجزء بالذات. هناك المزيد منهم ، ولكن ليس الكثير منهم حتى الآن.
ولكن مع التسليم والتحليل اللاحق ، يبدأ عدد الاختلافات في الانفجار. لن أصف كل خيار الآن. أعتقد أن الخيارات الرئيسية معروفة جيدًا لكل من كان مهتمًا بالموضوع.
سأريكم كيف فعلنا ذلك في Lazada وكيف بدأ كل شيء.
قبل عام ، أتيت إلى Lazada وتم إرسالي إلى مشروع السجل. كان مثل هذا هناك. تمت كتابة السجل من التطبيق إلى stdout و stderr. كل شيء تم بطريقة عصرية. ولكن بعد ذلك قام المطورون برميها من التدفقات القياسية ، ومن ثم سيقوم متخصصو البنية التحتية باكتشافها بطريقة ما. بين المتخصصين في البنية التحتية والمطورين ، هناك أيضًا محرّرون قالوا: "آه ... حسنًا ، دعنا نلفهم في ملف بصدفة ، وهذا كل شيء." ونظرًا لأن كل هذا موجود في حاوية ، فقد قاموا بلفه في الحاوية نفسها مباشرةً ، ووضعوا الدليل على الخريطة بالداخل ووضعوه هناك. أعتقد أنه من الواضح للجميع ما حدث.
دعونا ننظر إلى أبعد من ذلك بقليل. كيف قمنا بتسليم هذه السجلات. اختار شخص ما عامل td ، والذي هو في الواقع بطلاقة ولكن ليس بطلاقة تمامًا. ما زلت لا أفهم العلاقة بين هذين المشروعين ، لكن يبدو أنهما متشابهان. وهذا ، المكتوب بطلاقة بلغة روبي ، يقرأ ملفات السجل ، ويحللها في JSON باستخدام بعض التعبيرات النمطية. ثم تم إرسالهم إلى كافكا. علاوة على ذلك ، في كافكا ، كان لدينا 4 موضوعات منفصلة لكل واجهة برمجة تطبيقات. لماذا 4؟ لأن هناك حي ، وهناك مرحلة ، ولأن هناك ستدير وستدير. ينتجها المطورون ، وعلى عمال البنية التحتية أن يصنعوها في كافكا. علاوة على ذلك ، كان كافكا تحت سيطرة دائرة أخرى. لذلك ، كان من الضروري إنشاء تذكرة بحيث قاموا بإنشاء 4 مواضيع هناك لكل واجهة برمجة تطبيقات. نسيها الجميع. بشكل عام ، كانت القمامة والنفايات.
ماذا سنفعله بعد ذلك؟ أرسلناه إلى الكافكة. بعيدًا عن كافكا ، طار نصف جذوع الأشجار إلى لوغستاش. تمت مشاركة النصف الآخر من السجلات. طار البعض إلى Graylog ، وآخر إلى Graylog آخر. نتيجة لذلك ، تطاير كل هذا في مجموعة Elasticsearch واحدة. أي أن كل هذه الفوضى وقعت في النهاية هناك. ليس عليك القيام بذلك!
هذا ما يبدو عليه عند النظر إليه من الأعلى. ليس عليك القيام بذلك! هنا ، يتم تمييز مناطق المشكلات على الفور بالأرقام. يوجد بالفعل عدد أكبر منها ، لكن 6 منها تمثل إشكالية بالفعل ، والتي يجب القيام بشيء ما بها. سأخبر عنهم بشكل منفصل الآن.
هنا (1,2,3،XNUMX،XNUMX) نكتب الملفات ، وبالتالي ، هناك ثلاث مكابس هنا مرة واحدة.
الأول (1) هو أننا نحتاج إلى كتابتها في مكان ما. ليس من المستحسن دائمًا إعطاء API القدرة على الكتابة مباشرة إلى ملف. من المستحسن أن يتم عزل API في حاوية ، والأفضل من ذلك ، أن تكون للقراءة فقط. أنا مسؤول نظام ، لذا لدي وجهة نظر بديلة قليلاً لهذه الأشياء.
النقطة الثانية (2,3) هي أن لدينا الكثير من الطلبات القادمة إلى واجهة برمجة التطبيقات. تقوم واجهة برمجة التطبيقات (API) بكتابة الكثير من البيانات إلى ملف. الملفات تتزايد. نحن بحاجة إلى تدويرها. لأنه بخلاف ذلك لن تتمكن من حفظ أي أقراص هناك. يعد تدويرها أمرًا سيئًا لأنه تمت إعادة توجيهها عبر shell إلى دليل. لا توجد طريقة يمكننا من تدويرها. لا يمكنك إخبار التطبيق بإعادة فتح المقابض. لأن المطورين سوف ينظرون إليك مثل الأحمق: "ما هي الواصفات؟ عموما نكتب إلى stdout. جعلت الأطر نسخًا مقتطعة إلى logrotate ، والتي تقوم فقط بعمل نسخة من الملف وتجزئ النسخة الأصلية. وفقًا لذلك ، بين عمليات النسخ هذه ، عادةً ما تنفد مساحة القرص.
(4) لدينا تنسيقات مختلفة في واجهات برمجة تطبيقات مختلفة. كانت مختلفة بعض الشيء ، ولكن يجب كتابة التعبير العادي بشكل مختلف. نظرًا لأن Puppet كان يدير كل شيء ، فقد كان هناك مجموعة كبيرة من الفصول مع الصراصير الخاصة بهم. بالإضافة إلى ذلك ، يمكن لعامل td في معظم الأوقات أن يأكل الذاكرة ، ويكون غبيًا ، ويمكنه فقط التظاهر بأنه كان يعمل ولا يفعل شيئًا. ظاهريًا ، كان من المستحيل أن نفهم أنه لم يفعل شيئًا. في أحسن الأحوال ، سوف يسقط ، وسوف يلتقطه شخص ما لاحقًا. بتعبير أدق ، سيطير تنبيه ، وسيذهب شخص ما ويرفعه بأيديهم.
(6) والأكثر قمامة ونفايات - كان البحث المرن. لأنها كانت نسخة قديمة. لأنه لم يكن لدينا معلمون متخصصون في ذلك الوقت. كان لدينا سجلات غير متجانسة يمكن أن تتداخل حقولها. يمكن كتابة سجلات مختلفة لتطبيقات مختلفة بنفس أسماء الحقول ، ولكن في نفس الوقت قد تكون هناك بيانات مختلفة بالداخل. أي أن سجل واحد يأتي مع عدد صحيح في حقل ، على سبيل المثال ، المستوى. سجل آخر يأتي مع سلسلة في حقل المستوى. في حالة عدم وجود رسم خرائط ثابت ، يظهر مثل هذا الشيء الرائع. إذا وصلت ، بعد تدوير الفهرس ، رسالة بها سلسلة أولاً في elasticsearch ، فإننا نعيش بشكل طبيعي. وإذا وصلت الرسالة الأولى مع عدد صحيح ، فسيتم تجاهل جميع الرسائل اللاحقة التي وصلت مع String. لأن نوع الحقل لا يتطابق.
بدأنا في طرح هذه الأسئلة. قررنا عدم البحث عن المذنبين.
لكن هناك شيء يجب القيام به! الشيء الواضح هو أننا بحاجة إلى وضع المعايير. لدينا بالفعل بعض المعايير. أحضرنا البعض بعد ذلك بقليل. لحسن الحظ ، تمت الموافقة بالفعل على تنسيق سجل واحد لجميع واجهات برمجة التطبيقات في ذلك الوقت. يتم كتابته مباشرة في معايير تفاعل الخدمة. وفقًا لذلك ، يجب على أولئك الذين يرغبون في تلقي السجلات كتابتها بهذا التنسيق. إذا لم يكتب شخص ما سجلات بهذا التنسيق ، فإننا لا نضمن أي شيء.
علاوة على ذلك ، أود الحصول على معيار واحد لطرق تسجيل السجلات وتسليمها وجمعها. في الواقع ، أين تكتبها ، وكيف توصلها. الوضع المثالي هو عندما تستخدم المشاريع نفس المكتبة. توجد مكتبة تسجيل منفصلة لـ Go ، وهناك مكتبة منفصلة لـ PHP. كل شخص لدينا ، يجب على الجميع استخدامها. في الوقت الحالي ، أود أن أقول إننا نحقق النجاح بنسبة 80 في المائة. لكن البعض يواصل أكل الصبار.
وهناك (على الشريحة) "اتفاقية مستوى الخدمة لتسليم السجل" بالكاد بدأت في الظهور. لم يتم الوصول إليها بعد ، لكننا نعمل على حلها. لأنه من المريح جدًا عندما تقول أدناه أنك إذا كتبت بتنسيق كذا وكذا لمكان كذا وكذا وليس أكثر من N رسائل في الثانية ، فسنقوم على الأرجح بتسليمها هناك. يزيل الكثير من الصداع. إذا كان هناك اتفاقية مستوى الخدمة (SLA) ، فهذا أمر رائع!
كيف بدأنا في حل المشكلة؟ أشعل النار الرئيسي كان مع عامل td. لم يكن من الواضح أين تذهب سجلاتنا. هل يتم تسليمها؟ هم ذاهبون؟ أين هم على أي حال؟ لذلك ، تقرر استبدال td-agent بالعنصر الأول. خيارات لما يحل محله ، أوجزت بإيجاز هنا.
بطلاقة د. أولاً ، صادفته في وظيفة سابقة ، وكان يسقط هناك أيضًا بشكل دوري. ثانيًا ، هذا هو نفسه ، فقط في الملف الشخصي.
ملف. كيف كانت جيدة بالنسبة لنا؟ حقيقة أنه موجود في Go ، ولدينا خبرة كبيرة في Go. وفقًا لذلك ، إذا كان هناك أي شيء ، فيمكننا بطريقة ما إضافته لأنفسنا. لهذا لم نأخذها. حتى لا يكون هناك أي إغراء للبدء في إعادة كتابته بنفسك.
الحل الواضح لمسؤول النظام هو جميع أنواع سجلات النظام بهذه الكمية (syslog-ng / rsyslog / nxlog).
أو اكتب شيئًا خاصًا بك ، لكننا تجاهلناه ، وكذلك Filebeat. إذا كتبت شيئًا ، فمن الأفضل أن تكتب شيئًا مفيدًا للعمل. لتقديم السجلات ، من الأفضل أن تأخذ شيئًا جاهزًا.
لذلك ، جاء الاختيار في الواقع إلى الاختيار بين syslog-ng و rsyslog. اتجهت نحو rsyslog لمجرد أننا لدينا بالفعل فصول لـ rsyslog في Puppet ، ولم أجد فرقًا واضحًا بينهما. ما هو syslog ، ما هو syslog. نعم ، بعض الوثائق أسوأ ، وبعضها أفضل. إنه يعرف هذه الطريقة ، وهو يفعلها بشكل مختلف.
والقليل عن rsyslog. أولاً ، إنه رائع لأنه يحتوي على الكثير من الوحدات. لديها RainerScript يمكن قراءتها من قبل الإنسان (لغة التكوين الحديثة). مكافأة رائعة هي أنه يمكننا محاكاة سلوك td-agent بأدواته القياسية ، ولم يتغير شيء بالنسبة للتطبيقات. أي أننا نغير td-agent إلى rsyslog ، ولا نلمس أي شيء آخر بعد. وعلى الفور نحصل على توصيل عمل. التالي ، mmnormalize هو الشيء الرائع في rsyslog. يسمح لك بتحليل السجلات ، ولكن ليس باستخدام Grok و regexp. يصنع شجرة بناء مجردة. إنه يوزع السجلات بنفس الطريقة التي يوزع بها المترجم شفرة المصدر. يتيح لك ذلك العمل بسرعة كبيرة ، وتناول القليل من وحدة المعالجة المركزية ، وبشكل عام ، إنه شيء رائع جدًا. هناك مجموعة من المكافآت الأخرى. لن أسهب في الحديث عنها.
rsyslog له عيوب أكثر بكثير. هم تقريبا نفس المكافآت. تتمثل المشاكل الرئيسية في أنك تحتاج إلى أن تكون قادرًا على طهيه ، وتحتاج إلى تحديد إصدار.
قررنا أن نكتب السجلات في مقبس يونكس. وليس في / dev / log ، نظرًا لوجود فوضى في سجلات النظام ، هناك دفتر يوميات في خط الأنابيب هذا. لذلك دعونا نكتب إلى مقبس مخصص. سنقوم بإرفاقه بمجموعة قواعد منفصلة. دعونا لا نتدخل في أي شيء. سيكون كل شيء شفافًا ومفهومًا. لذلك فعلنا ذلك بالفعل. الدليل الذي يحتوي على هذه المقابس موحد ويتم إعادة توجيهه إلى جميع الحاويات. يمكن للحاويات رؤية المقبس الذي يحتاجون إليه ، وفتحه والكتابة عليه.
لماذا ليس ملفا؟ لأن الجميع قد قرأ ، الذي حاول إعادة توجيه الملف إلى عامل التحميل ، ووجد أنه بعد إعادة تشغيل سجل rsyslog ، يتغير واصف الملف ، ويفقد عامل التحميل هذا الملف. يحافظ على فتح شيء آخر ، لكن ليس نفس المقبس الذي يكتبون فيه. قررنا أن نتجاوز هذه المشكلة ، وفي نفس الوقت ، نتجاوز مشكلة الحجب.
يقوم Rsyslog بتنفيذ الإجراءات الموضحة على الشريحة ويرسل السجلات إما إلى الترحيل أو إلى كافكا. يتبع كافكا الطريقة القديمة. Rayleigh - حاولت استخدام سجل rsyslog الخالص لتقديم السجلات. بدون قائمة انتظار الرسائل ، باستخدام أدوات سجل rsyslog القياسية. في الأساس ، إنه يعمل.
ولكن هناك فروق دقيقة في كيفية حشوها لاحقًا في هذا الجزء (Logstash / Graylog / ES). يُستخدم هذا الجزء (rsyslog-rsyslog) بين مراكز البيانات. فيما يلي رابط tcp مضغوط ، والذي يسمح لك بحفظ النطاق الترددي ، وبالتالي يزيد بطريقة ما من احتمالية تلقي بعض السجلات من مركز بيانات آخر عندما تكون القناة ممتلئة. لأن لدينا إندونيسيا ، حيث كل شيء سيء. هذا هو المكان الذي تكمن فيه المشكلة المستمرة.
فكرنا في كيفية قيامنا بالمراقبة بالفعل ، مع أي احتمالية تصل السجلات التي سجلناها من التطبيق إلى هذه النهاية؟ قررنا أن نبدأ المقاييس. يحتوي Rsyslog على وحدة جمع الإحصائيات الخاصة به ، والتي تحتوي على نوع من العدادات. على سبيل المثال ، يمكن أن يُظهر لك حجم قائمة الانتظار ، أو عدد الرسائل الواردة لمثل هذا الإجراء. يمكنك بالفعل أخذ شيء منهم. بالإضافة إلى ذلك ، يحتوي على عدادات مخصصة يمكنك تكوينها ، وستظهر لك ، على سبيل المثال ، عدد الرسائل التي سجلتها بعض واجهات برمجة التطبيقات. بعد ذلك ، كتبت rsyslog_exporter بلغة Python ، وأرسلناها كلها إلى Prometheus وخططنا لها. لقد أردنا حقًا مقاييس Graylog ، لكن حتى الآن لم يكن لدينا الوقت لإعدادها.
ما هي المشاكل؟ نشأت المشكلة مع حقيقة أننا اكتشفنا (فجأة!) أن واجهات برمجة التطبيقات الحية لدينا تكتب 50 ألف رسالة في الثانية. هذا هو Live API فقط دون التدريج. ويظهر لنا Graylog فقط 12 ألف رسالة في الثانية. ونشأ سؤال معقول أين البقايا؟ استنتجنا من ذلك أن Graylog ببساطة لا تستطيع التأقلم. نظرنا ، وبالفعل ، لم يتقن Graylog مع Elasticsearch هذا التدفق.
بعد ذلك ، اكتشافات أخرى قمنا بها على طول الطريق.
يتم حظر عمليات الكتابة إلى المقبس. كيف حدث ذلك؟ عندما استخدمت rsyslog للتسليم ، كسرنا القناة في مرحلة ما بين مراكز البيانات. تم التسليم في مكان ، والتوصيل في مكان آخر. كل هذا يعود إلى آلة ذات واجهات برمجة تطبيقات تكتب على مقبس سجل rsyslog. كان هناك طابور. ثم امتلأت قائمة انتظار الكتابة إلى مقبس يونكس ، والتي تكون افتراضيًا 128 حزمة. ثم اكتب () في تطبيق الكتل. عندما نظرنا إلى المكتبة التي نستخدمها في تطبيقات Go ، كان مكتوبًا هناك أن الكتابة على المقبس تحدث في وضع عدم الحظر. كنا على يقين من أنه لم يتم حظر أي شيء. لأننا قرأنا الذي كتب عنها. لكن هناك لحظة. كانت هناك أيضًا حلقة لا نهائية حول هذه المكالمة ، حيث كانت هناك محاولة مستمرة لدفع رسالة إلى المقبس. لم نلاحظه. اضطررت إلى إعادة كتابة المكتبة. منذ ذلك الحين ، تغير الأمر عدة مرات ، لكننا الآن تخلصنا من الأقفال في جميع الأنظمة الفرعية. لذلك ، يمكنك إيقاف rsyslog ولن يسقط أي شيء.
من الضروري مراقبة حجم قوائم الانتظار ، مما يساعد على عدم الخطو على هذا أشعل النار. أولاً ، يمكننا مراقبة متى نبدأ في فقدان الرسائل. ثانيًا ، يمكننا مراقبة أننا نواجه مشكلات في التسليم.
ولحظة أخرى غير سارة - التضخيم بمقدار 10 مرات في بنية الخدمات المصغرة أمر سهل للغاية. ليس لدينا الكثير من الطلبات الواردة ، ولكن بسبب الرسم البياني الذي يتم من خلاله تشغيل هذه الرسائل بشكل أكبر ، نظرًا لسجلات الوصول ، فإننا في الواقع نزيد الحمل على السجلات بحوالي عشر مرات. لسوء الحظ ، لم يكن لدي الوقت لحساب الأرقام الدقيقة ، لكن الخدمات المصغرة هي ما هي عليه. يجب أن يؤخذ هذا في الاعتبار. اتضح أن النظام الفرعي لجمع السجلات هو الأكثر تحميلًا في Lazada في الوقت الحالي.
كيف تحل مشكلة البحث المرن؟ إذا كنت بحاجة إلى الحصول على السجلات بسرعة في مكان واحد ، حتى لا يتم تشغيلها عبر جميع الأجهزة وتجميعها هناك ، فاستخدم تخزين الملفات. هذا مضمون للعمل. يتم ذلك من أي خادم. تحتاج فقط إلى لصق الأقراص هناك ووضع سجل النظام. بعد ذلك ، نضمن لك الاحتفاظ بجميع السجلات في مكان واحد. بعد ذلك سيكون من الممكن تكوين elasticsearch أو graylog أو أي شيء آخر ببطء. ولكن سيكون لديك بالفعل جميع السجلات ، علاوة على ذلك ، يمكنك تخزينها ، طالما أن هناك عددًا كافيًا من مصفوفات القرص.
في وقت تقديم تقريري ، بدأ المخطط في الظهور على هذا النحو. عمليا توقفنا عن الكتابة إلى الملف. الآن ، على الأرجح ، سنقوم بإيقاف البقايا. على الأجهزة المحلية التي تقوم بتشغيل API ، سنتوقف عن الكتابة إلى الملفات. أولاً ، هناك تخزين للملفات ، والذي يعمل بشكل جيد للغاية. ثانيًا ، تنفد مساحة هذه الأجهزة باستمرار ، فأنت بحاجة إلى مراقبتها باستمرار.
هذا الجزء مع Logstash و Graylog ، إنه يرتفع حقًا. لذلك ، تحتاج إلى التخلص منه. عليك أن تختار واحدا.
قررنا التخلي عن Logstash و Kibana. لأن لدينا قسم أمن. ما هي العلاقة؟ الاتصال هو أن Kibana بدون X-Pack وبدون Shield لا يسمح لك بالتفريق بين حقوق الوصول إلى السجلات. لذلك ، أخذوا Graylog. لديها كل شيء. لا يعجبني ، لكنه يعمل. اشترينا أجهزة جديدة ، وقمنا بتثبيت Graylog جديد هناك ، ونقلنا جميع السجلات ذات التنسيقات الصارمة إلى Graylog منفصل. لقد قمنا بحل المشكلة من خلال أنواع مختلفة من نفس المجالات من الناحية التنظيمية.
ما تم تضمينه بالضبط في Graylog الجديد. نحن فقط كتبنا كل شيء في عامل الميناء. أخذنا مجموعة من الخوادم ، وطرحنا ثلاث نسخ من كافكا ، 7 خوادم Graylog الإصدار 2.3 (لأنني أردت Elasticsearch الإصدار 5). كل هذا أثير على غارات من HDD. لقد رأينا معدل فهرسة يصل إلى 100 ألف رسالة في الثانية. لقد رأينا الرقم الذي يبلغ 140 تيرابايت من البيانات في الأسبوع.
ومرة أخرى أشعل النار! لدينا اثنين من المبيعات القادمة. لقد تجاوزنا 6 ملايين مشاركة. نحن Graylog ليس لدينا وقت للمضغ. بطريقة ما عليك البقاء على قيد الحياة مرة أخرى.
هذه هي الطريقة التي نجونا بها. تمت إضافة عدد قليل من الخوادم ومحركات أقراص الحالة الثابتة. في هذه اللحظة نعيش مثل هذا. نحن الآن نمضغ بالفعل 160 ألف رسالة في الثانية. لم نصل إلى الحد الأقصى بعد ، لذلك ليس من الواضح إلى أي مدى يمكننا أن نتخلص منه بشكل واقعي.
هذه هي خططنا للمستقبل. من بين هؤلاء ، حقًا ، ربما يكون الأهم هو التوافر الكبير. ليس لدينا بعد. تم إعداد العديد من السيارات بنفس الطريقة ، ولكن حتى الآن كل شيء يمر عبر سيارة واحدة. من الضروري قضاء بعض الوقت في إنشاء تجاوز الفشل بينهما.
اجمع المقاييس من Graylog.
ضع حدًا للمعدل بحيث يكون لدينا واجهة برمجة تطبيقات مجنونة لا تقضي على النطاق الترددي وكل شيء آخر.
وأخيرًا ، وقع نوعًا من اتفاقية مستوى الخدمة مع المطورين حتى نتمكن من تقديم الكثير. إذا كتبت أكثر ، فآسف.
واكتب التوثيق.
باختصار ، نتائج كل ما مررنا به. أولاً ، المعايير. ثانيًا ، سجل النظام عبارة عن كعكة. ثالثًا ، يعمل rsyslog تمامًا كما هو مكتوب على الشريحة. ودعونا ننتقل إلى الأسئلة.
الأسئلة.
سؤال: لماذا قرروا عدم أخذ ... (Filebeat؟)
إجابة: تحتاج إلى الكتابة إلى ملف. أنا حقا لا أريد ذلك. عندما تكتب واجهة برمجة التطبيقات الخاصة بك آلاف الرسائل في الثانية ، حتى إذا قمت بالتناوب مرة واحدة في الساعة ، فلا يزال هذا خيارًا غير متاح. يمكنك الكتابة إلى الأنابيب. سألني المطورون: "ماذا سيحدث إذا سقطت العملية التي نكتب فيها"؟ لم أجد ما أجيب عليهم ، وقلت: "حسنًا ، حسنًا ، دعونا لا نفعل ذلك."
سؤال: لماذا لا تكتب فقط السجلات إلى HDFS؟
إجابةج: هذه هي الخطوة التالية. لقد فكرنا في الأمر في البداية ، ولكن نظرًا لعدم وجود موارد للتعامل معه في الوقت الحالي ، فإنه معلق في حلنا على المدى الطويل.
سؤال: سيكون تنسيق العمود أكثر ملاءمة.
إجابة: أفهم. نحن "مع" بكلتا يديه.
سؤال: تكتب إلى rsyslog. يتوفر كل من TCP و UDP هناك. ولكن إذا كان UDP ، فكيف تضمن التسليم؟
إجابةج: هناك نقطتان. أولاً ، أخبر الجميع على الفور أننا لا نضمن تسليم السجلات. لأنه عندما يأتي المطورون ويقولون: "لنبدأ في كتابة البيانات المالية هناك ، وسوف تضعها في مكان ما لنا في حالة حدوث شيء ما ،" نجيبهم ، "رائع! لنبدأ في منع الكتابة على المقبس ، ونفعل ذلك في المعاملات ، حتى نضمن لك وضعه في المقبس بالنسبة لنا ونتأكد من استلامنا له من الجانب الآخر. وفي هذه اللحظة ، يصبح الجميع على الفور غير ضروري. وإذا لم يكن كذلك ، فما هي الأسئلة التي لدينا؟ إذا كنت لا تريد ضمان الكتابة إلى المقبس ، فلماذا نضمن التسليم؟ نحن نبذل قصارى جهدنا. نحاول حقًا تقديم أكبر قدر ممكن وأفضل ما يمكن ، لكننا لا نقدم ضمانًا بنسبة 100٪. لذلك ، لا تحتاج إلى كتابة البيانات المالية هناك. هناك قواعد بيانات المعاملات لهذا الغرض.
سؤال: عندما تنشئ واجهة برمجة التطبيقات بعض الرسائل إلى السجل وتنقل التحكم إلى الخدمات المصغرة ، هل واجهت مشكلة وصول الرسائل من الخدمات المصغرة المختلفة بترتيب خاطئ؟ لهذا السبب ، ينشأ الارتباك.
إجابةج: من الطبيعي أن يأتوا بترتيب مختلف. يجب أن تكون مستعدًا لهذا. لأن أي توصيل عبر الشبكة لا يضمن لك الطلب ، أو تحتاج إلى إنفاق موارد خاصة على ذلك. إذا أخذنا ملفات تخزين ، فكل واجهة برمجة تطبيقات تحفظ السجلات في ملفها الخاص. بدلاً من ذلك ، يقوم rsyslog بتقسيمها إلى أدلة هناك. كل واجهة برمجة تطبيقات لها سجلات خاصة بها هناك ، حيث يمكنك الذهاب والبحث ، وبعد ذلك يمكنك مقارنتها باستخدام الطابع الزمني في هذا السجل. إذا ذهبوا للبحث في Graylog ، فسيتم فرزهم هناك حسب الطابع الزمني. كل شيء سيكون على ما يرام هناك.
سؤال: قد يختلف الطابع الزمني بالمللي ثانية.
إجابة: يتم إنشاء الطابع الزمني بواسطة API نفسها. هذا ، في الواقع ، هو بيت القصيد. لدينا NTP. تقوم واجهة برمجة التطبيقات بإنشاء طابع زمني بالفعل في الرسالة نفسها. لم تتم إضافته بواسطة rsyslog.
سؤال: التفاعل بين مراكز البيانات ليس واضحًا تمامًا. في إطار عمل مركز البيانات ، من الواضح كيف تم جمع السجلات ومعالجتها. كيف يتم التفاعل بين مراكز البيانات؟ أم أن كل مركز بيانات يعيش حياته الخاصة؟
إجابة: بالكاد. لدينا كل بلد يقع في مركز بيانات واحد. ليس لدينا انتشار حاليًا ، لذلك يتم وضع دولة واحدة في مراكز بيانات مختلفة. لذلك ، ليست هناك حاجة للجمع بينهما. يوجد داخل كل مركز مرحل سجل. هذا هو خادم Rsyslog. في الواقع ، جهازي إدارة. هم أقاموا بنفس الطريقة. لكن في الوقت الحالي ، تمر حركة المرور عبر أحدها. انها تسجل كل شيء مجمعات. لديها قائمة انتظار القرص فقط في حالة. تضغط على السجلات وترسلها إلى مركز البيانات المركزي (سنغافورة) ، حيث يتم تسميمها بالفعل في Graylog. ولكل مركز بيانات تخزين الملفات الخاص به. في حالة فقد الاتصال ، فلدينا جميع السجلات هناك. سيبقون هناك. سيتم تخزينها هناك.
سؤال: هل تحصل على سجلات من هناك أثناء المواقف غير الطبيعية؟
إجابة: يمكنك الذهاب إلى هناك (لتخزين الملفات) والبحث.
سؤال: كيف تراقب أنك لا تفقد السجلات؟
إجابة: نحن نفقدهم بالفعل ، ونحن نراقب ذلك. بدأت المراقبة منذ شهر. تحتوي المكتبة التي تستخدمها Go APIs على مقاييس. يمكنها حساب عدد المرات التي فشلت في الكتابة فيها. هناك في الوقت الحالي هناك مجريات الأمور صعبة. هناك عازلة هناك. يحاول كتابة رسالة منه إلى المقبس. إذا فاض المخزن المؤقت ، فإنه يبدأ في إسقاطها. ويحسب كم أسقطهم. إذا بدأت العدادات بالفيضان هناك ، فسنعرف ذلك. هم الآن يأتون أيضًا إلى بروميثيوس ، ويمكنك رؤية الرسوم البيانية في جرافانا. يمكنك إعداد التنبيهات. لكن لم يتضح بعد لمن ترسلهم.
سؤال: في elasticsearch ، تقوم بتخزين السجلات مع التكرار. كم عدد النسخ المتماثلة لديك؟
إجابة: نسخة طبق الأصل.
سؤال: هل هو مجرد سطر واحد؟
إجابة: هذا هو المعلم والنسخة المتماثلة. يتم تخزين البيانات في نسختين.
سؤال: هل قمت بتعديل حجم المخزن المؤقت rsyslog بطريقة ما؟
إجابة: نكتب مخططات البيانات إلى مقبس يونكس مخصص. هذا يفرض على الفور حدًا قدره 128 كيلوبايت علينا. لا يمكننا كتابة المزيد فيه. لقد كتبنا هذا في المعيار. من يريد الوصول إلى التخزين ، يكتبون 128 كيلوبايت. المكتبات ، علاوة على ذلك ، تقطع ، وتضع علامة على أن الرسالة مقطوعة. لدينا مجال خاص في مستوى الرسالة نفسها يوضح ما إذا كان قد تم قطعها أثناء التسجيل أم لا. لذلك لدينا فرصة لتتبع هذه اللحظة.
سؤال: هل تكتب JSON المكسور؟
إجابة: سيتم تجاهل JSON المكسور إما أثناء الترحيل لأن الحزمة كبيرة جدًا. أو سيتم تجاهل Graylog ، لأنه لن يكون قادرًا على تحليل JSON. ولكن هناك فروق دقيقة هنا تحتاج إلى إصلاح ، وهي مرتبطة في الغالب بـ rsyslog. لقد قمت بالفعل بملء عدد قليل من القضايا هناك ، والتي لا تزال بحاجة إلى العمل عليها.
سؤال: لماذا كافكا؟ هل جربت RabbitMQ؟ Graylog لا تضيف تحت مثل هذه الأحمال؟
إجابة: لا ينجح الأمر مع Graylog. ويتشكل Graylog. انها حقا مشكلة بالنسبة له. إنه شيء من نوع ما. وفي الحقيقة ، ليست هناك حاجة لذلك. أفضل الكتابة من rsyslog مباشرة إلى elasticsearch ثم مشاهدة Kibana. لكن علينا تسوية الموضوع مع حراس الأمن. هذا هو البديل المحتمل لتطورنا عندما نتخلص من Graylog ونستخدم Kibana. لن يكون Logstash منطقيًا. لأنني أستطيع أن أفعل الشيء نفسه مع rsyslog. ويحتوي على وحدة للكتابة إلى elasticsearch. مع Graylog نحاول أن نعيش بطريقة ما. حتى أننا قمنا بتعديله قليلاً. لكن لا يزال هناك مجال للتحسين.
عن كافكا. هكذا حدث تاريخيا. عندما وصلت ، كانت موجودة بالفعل ، وكانت السجلات تُكتب عليها بالفعل. لقد قمنا للتو برفع المجموعة الخاصة بنا ونقلنا السجلات إليها. نحن نتعامل معه ، ونعرف كيف يشعر. أما بالنسبة لـ RabbitMQ ... فنحن نواجه مشكلة مع RabbitMQ. و RabbitMQ يتطور بالنسبة لنا. لدينا في الإنتاج ، وكانت هناك مشاكل معها. الآن ، قبل البيع ، سوف يتم تصويره بالشامان ، ويبدأ في العمل بشكل طبيعي. لكن قبل ذلك ، لم أكن مستعدًا لإطلاقه في الإنتاج. هناك نقطة أخرى. يستطيع Graylog قراءة إصدار AMQP 0.9 ويمكن لـ rsyslog كتابة إصدار AMQP 1.0. ولا يوجد حل واحد يمكنه فعل الأمرين في المنتصف. إما أن يكون هناك واحد أو آخر. حتى الآن كافكا فقط. لكن هناك أيضًا فروق دقيقة. لأن omkafka من إصدار rsyslog الذي نستخدمه يمكن أن يفقد المخزن المؤقت للرسائل بالكامل الذي جمعه من rsyslog. طالما أننا نتحملها.
سؤال: هل تستخدم كافكا لأنك امتلكتها؟ لا تستخدم لأي غرض آخر؟
إجابة: كافكا ، والذي استخدمه فريق علوم البيانات. هذا مشروع منفصل تمامًا ، ولسوء الحظ ، لا أستطيع أن أقول أي شيء عنه. لا أعلم. كانت تدار من قبل فريق علوم البيانات. عندما بدأت السجلات ، قرروا استخدامها ، حتى لا يضعوا السجلات الخاصة بهم. الآن قمنا بتحديث Graylog ، وفقدنا التوافق ، لأن هناك نسخة قديمة من كافكا. كان علينا أن نصنع منطقتنا. في الوقت نفسه ، تخلصنا من هذه الموضوعات الأربعة لكل واجهة برمجة تطبيقات. لقد صنعنا قمة عريضة للجميع على الهواء مباشرة ، وقمة عريضة واحدة لجميع المراحل ونحن فقط نطلق النار على كل شيء هناك. يقوم Graylog بإخراج كل هذا بالتوازي.
سؤال: لماذا نحتاج هذه الشامانية ذات المآخذ؟ هل حاولت استخدام برنامج تشغيل سجل النظام للحاويات.
إجابة: في الوقت الذي طرحنا فيه هذا السؤال ، كانت علاقاتنا متوترة مع عامل الرصيف. كان docker 1.0 أو 0.9. كان عامل السفن نفسه غريبًا. ثانيًا ، إذا قمت أيضًا بدفع سجلات الدخول إليه ... فلدي شكوك لم يتم التحقق منها في أنه يمر بجميع السجلات من خلال نفسه ، من خلال برنامج عامل الميناء. إذا كان لدينا واجهة برمجة تطبيقات واحدة أصبحت مجنونة ، فستواجه بقية واجهات برمجة التطبيقات حقيقة أنها لا تستطيع إرسال stdout و stderr. لا أعرف إلى أين سيقودنا هذا. لدي شك على مستوى الشعور بأنه ليس من الضروري استخدام برنامج تشغيل docker syslog في هذا المكان. يحتوي قسم الاختبارات الوظيفية لدينا على مجموعة Graylog الخاصة به مع السجلات. يستخدمون برامج تشغيل سجل عامل الإرساء ويبدو أن كل شيء على ما يرام هناك. لكنهم كتبوا على الفور GELF إلى Graylog. في اللحظة التي بدأنا فيها كل هذا ، كنا بحاجة إلى أن يعمل فقط. ربما لاحقًا ، عندما يأتي أحدهم ويقول إنه يعمل بشكل طبيعي منذ مائة عام ، سنحاول.
سؤال: تقوم بالتوصيل بين مراكز البيانات باستخدام rsyslog. لماذا ليس على كافكا؟
إجابة: نحن نفعل هذا ، وهذا ما يحدث بالفعل. لسببين. إذا كانت القناة ميتة تمامًا ، فلن تتسلق جميع سجلاتنا ، حتى في شكل مضغوط. والكفكة تسمح لهم بالخسارة ببساطة في هذه العملية. بهذه الطريقة ، نتخلص من التصاق هذه السجلات. نحن فقط نستخدم كافكا في هذه الحالة بشكل مباشر. إذا كانت لدينا قناة جيدة ونريد تحريرها ، فنحن نستخدم rsyslog الخاصة بهم. لكن في الواقع ، يمكنك إعداده بحيث يسقط ما لم ينجح. في الوقت الحالي ، نستخدم فقط تسليم rsyslog مباشرة في مكان ما ، في مكان ما كافكا.
المصدر: www.habr.com