أفضل الممارسات لتسجيل تطبيقات المؤسسة (من منظور مهندس الدعم)



تكشف سجلات التطبيق معلومات حول الأحداث الخارجية والداخلية التي يراها التطبيق أثناء التنفيذ. عند حدوث خطأ أو اختراق أو شذوذ أثناء النشر ، فإن السجلات هي الدليل الأكثر فائدة وموثوقية لتحليل أسباب الحادث.



دعونا نلقي نظرة على كيفية كتابة الرسائل المفيدة في المجلة التي يحبها الجميع.



1. ما لتسجيل الدخول



الرسائل الواردة والصادرة



إذا تفاعلت المكونات مع بعضها البعض باستخدام الرسائل ، فأنت بحاجة إلى تسجيل الرسائل الواردة والصادرة التي تشير إلى عناوين URL لنقاط نهاية API ، ومعلمات الطلب ، وطلبات IP الأولية والمتوسطة ، ورؤوس الطلبات ، ومعلومات حول المؤلف ، وهيئات الطلب والاستجابة ، وسياق الأعمال والطوابع الزمنية وخطوات المعالجة الداخلية.



من المهم جدًا أن يتم تعيين معرف فريد لكل رسالة (يتم إنشاؤه عادةً على مستوى مدير واجهة برمجة التطبيقات أو مستوى الخدمة). هذا ضروري لتتبع تبادل الرسائل بين الخدمات في النظام.



خدمات الاتصال والوظائف



عند استدعاء خدمة أو وظيفة ، من المستحسن تسجيل سياقها بمزيد من التفاصيل ، خاصة لتصحيح الأخطاء (استخدم TRACE أو DEBUG). ستساعدك هذه السجلات في استكشاف مشكلات منطق الأعمال وإصلاحها ، خاصةً إذا لم يكن لديك امتياز إرفاق مصحح أخطاء بتطبيق ما (على سبيل المثال ، عند النشر في بيئة اختبار أو مرحلة أو بيئة مسبقة الإنتاج).



إجراءات المستخدم وإحصاءات الأعمال



يحتوي كل تطبيق على سيناريوهات عمل فريدة ورحلات مستخدم توفر الكثير من المعلومات للمهنيين المتخصصين. على سبيل المثال ، ما إذا كانت معاملة معينة تستغرق وقتًا طويلاً ، أو ما إذا كان المستخدمون عالقون في بعض الوظائف - كل هذه بيانات مهمة جدًا من وجهة نظر تجربة المستخدم. المعلومات الأخرى المتعلقة بالعمل - عدد المعاملات والمستخدمين النشطين ، وكذلك مراحلهم - مهمة لإيجاد العلاقات السببية ، ويمكن حتى استخدامها في تحليل الأعمال.



عمليات البيانات (مسار المراجعة)



لأسباب تتعلق بالأمان والامتثال ، تتطلب معظم تطبيقات المؤسسة سجلات معاملات منفصلة مع جميع المعلومات المهمة مثل معرفات الوصول (المستخدمون والأنظمة) ، ومثيلات الخدمة الدقيقة وامتيازات الدور المستخدمة ، والطوابع الزمنية ، وطلبات البيانات ، واللقطات والحالة الجديدة للبيانات المتغيرة (فرق). يجب أن يسجل مسار التدقيق جميع العمليات مع البيانات (الوصول والاستيراد والتصدير وما إلى ذلك) ، بالإضافة إلى عمليات CRUD (الإنشاء والقراءة والتحديث والحذف) التي يقوم بها المستخدمون والأنظمة والخدمات الأخرى.



أحداث النظام



يتضمن ذلك معلومات حول السلوك (عمليات البدء والتوقف وإعادة التشغيل والأحداث المتعلقة بالسلامة) ، والأوضاع المؤقتة (الباردة ، والإحماء ، والساخنة) ، والاتصال بين الخدمات (المصافحة ، وحالات إنشاء الاتصال - متصلة ، وغير متصلة ، وإعادة الاتصال ، وإعادة المحاولة) ، والمعرفات مثيلات الخدمة ، وخدمة واجهات برمجة التطبيقات بنشاط ، والاستماع بنشاط إلى نطاقات IP والمنافذ ، والتكوينات المحملة (التمهيد والتحديثات الديناميكية) ، وحالة الخدمة الإجمالية ، وأي شيء آخر يمكن أن يساعدك في فهم سلوك النظام.



إحصائيات الأداء



يعتبر الاجتهاد سمة رائعة لأجهزة الحوسبة ، لكنها قد لا تؤدي بشكل مثالي. في أي وقت ، قد تكون هناك مشكلات في الأداء أو تدهور مفاجئ غير متوقع في الخدمة (غالبًا بسبب أخطاء غير معالجة وبيانات تالفة). لتحديد هذه ، يوصى دائمًا بنشر إحصائيات حول الصحة العامة وأداء النظام. يمكن أن تحتوي على معلومات مثل عدادات مكالمات API (الناجحة والفاشلة) ، وزمن انتقال الشبكة ، ومتوسط ​​مدة الرحلة ذهابًا وإيابًا ، واستهلاك الذاكرة ، ومعلومات أخرى خاصة بالتطبيق (عادةً ما يتم تحديدها بواسطة سياق الأعمال)



التهديدات ونقاط الضعف



يعد الكشف عن التهديدات ونقاط الضعف باستخدام سجلات وتطبيقات وقت التشغيل فنًا يجب على أي مطور برامج مؤسسي إتقانه. عادة لا تحدث الاختراقات ومواطن الخلل فجأة. في أغلب الأحيان ، هناك علامات لا يلاحظها أحد في البداية. لذلك ، يجب عليك دائمًا تسجيل النشاط البشري المشبوه (على سبيل المثال ، المحاولات الخاطئة للمصادقة والتحقق من خلال تطبيق جميع المعلومات منخفضة المستوى مثل الشبكات المستخدمة ، ومصادر الطلبات ، وأدوار المستخدم وامتيازاته) ، بالإضافة إلى سلوك النظام (على سبيل المثال ، زيادة في أنماط استهلاك الموارد ، وحمل كبير على خوادم الويب ، وإخفاقات الخدمة العرضية). عندما تلاحظ حدثًا مريبًا ، تأكد من احتواء السجلات على جميع المعلومات المتعلقة به. تماما،بحيث يكون تتبع مكدس كامل بقيم معلمات ومعلومات إضافية تم الحصول عليها من سياق التطبيق.



2. ما لا تحتاج إلى تسجيل الدخول



معلومات شخصية



توصي جميع قوانين الخصوصية تقريبًا (مثل القانون العام لحماية البيانات وقانون حماية خصوصية المستهلك) المطورين صراحةً بعدم تسجيل معلومات التعريف الشخصية. يتضمن ذلك الاسم والألقاب والجنس وتاريخ الميلاد وعنوان الشارع والبريد الإلكتروني وأرقام الهواتف ورقم الضمان الاجتماعي وأرقام بطاقات الائتمان.



أسماء الشركات ومعلومات الاتصال



تأكد من عدم كتابة أسماء الشركات أو الموظفين أو العملاء أو معلومات المورد أو معلومات الاتصال الخاصة بالشركة والأفراد. يجب ألا تفصح المجلة مطلقًا عن العلاقات التجارية والمعاملات مع أطراف ثالثة. لتتبع معاملات محددة ، استخدم معرفات الأحداث التي ينشئها النظام بدلاً من الأسماء الحقيقية وقم بتمريرها إلى خدمات أخرى.



البيانات المالية (الحسابات المصرفية ، تفاصيل البطاقة المصرفية ، المبالغ المحولة ، إلخ.)



بموجب القانون ، يجب إزالة أو إخفاء جميع البيانات المالية تمامًا. يمكن أن يؤدي الكشف عن مثل هذه المعلومات في المجلات بسهولة إلى إجراءات قانونية خطيرة (تصل إلى المسؤولية الجنائية). تجنب هذا بكل الوسائل.



كلمات المرور ومفاتيح الأمان والأسرار ورموز المصادقة



تُعتبر بيانات الاعتماد ورموز المصادقة معلومات سرية ، لذا فإن وجودها في السجلات سيساعد المهاجمين في العثور بسهولة على ثغرات في النظام. لذلك ، لا تدع هذه البيانات في السجلات.



ملاحظة: سيكون من السهل عليك تحديد المعلومات التي تريد إخفاؤها من السجلات إذا أضفت سمة لكل حقل تحدد مستوى الرؤية (على سبيل المثال ، إظهار ، إخفاء ، إخفاء ، تشفير). إذا كانت لديك مثل هذه الآلية ، فيمكنك تغيير رؤية الحقول ببساطة عن طريق تحديث الخصائص في التكوين. يعد هذا حلاً جيدًا في الحالات التي تحتاج فيها إلى تسجيل بعض معلومات المستخدم في بيئات غير قتالية ، خاصةً للاختبار وتصحيح الأخطاء. أو يمكنك كتابة موزعات تقوم بتصفية السجلات ومعالجة الحقول الحساسة وفقًا لإرشادات مكتوبة مسبقًا خاصة بالبيئة.



3. أفضل الممارسات



اعرف متى يجب استخدام مستوى معين من التسجيل



يتم استخدام مستوى السجل للإشارة إلى خطورة كل عنصر في النظام. تحتوي معظم أطر التسجيل على هذه المستويات:



  • فادح : أخطاء جسيمة من المرجح أن تؤدي إلى إنهاء التطبيق. هذا عادة ما ينتهي بفشل خطير.
  • خطأ : الأخطاء التي يمكن للتطبيق الاستمرار في العمل بها ، ولكن مع تدهور بعض القدرات.
  • تحذير : أحداث أقل خطورة مقارنة بالأخطاء. عادة لا تتحلل أو تعطل التطبيق تمامًا. لكن هذه لا تزال أحداثًا مهمة تحتاج إلى التحقيق.
  • INFO : لافتات الأحداث الهامة والرسائل الإعلامية في سلوك التطبيق.
  • DEBUG: , . .
  • TRACE: , , . .


يحتوي Linux Syslog أيضًا على مستويات أكثر خطورة مثل الطوارئ والتنبيه والحرجة والخطأ والتحذير والإشعار والمعلومات وتصحيح الأخطاء.



بغض النظر عن مدى تعقيد وعمق كل مستوى من مستويات التسجيل ، يجب علينا تكوينها بشكل صحيح في الكود الخاص بنا لتوفير الكمية المثلى من المعلومات في كل سيناريو. على سبيل المثال ، يجب أن تذهب جميع البيانات التي يستخدمها المطورون لتصحيح الأخطاء والتحليل الفني إلى مستويات DEBUG أو TRACE ، ويجب أن تكون اللافتات التي تحتوي على بيانات النظام أقل من INFO.



استخدم الإنجليزية



لا تدعم بعض الأدوات ووحدات التحكم إخراج وتخزين السجلات بأحرف Unicode معينة. لذلك ، قد تكون الترجمة والتحسينات الأخرى صعبة. التزم باللغة الإنجليزية واستخدم دائمًا مجموعة أحرف مدعومة على نطاق واسع لكتابة الرسائل.



2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all

      
      





أضف رسائل صديقة للمطورين (موجزة وذات مغزى)



إذا كان هناك القليل جدًا من التسجيلات ، فلن نتمكن من الحصول على المعلومات التي نحتاجها لإعادة إنشاء سياق كل حدث مهم. وإذا قمت بتسجيل الكثير ، فسيؤدي ذلك إلى تدهور الأداء: سيؤدي كتابة ملف سجل ضخم إلى زيادة استهلاك موارد الإدخال / الإخراج وتخزين القرص. إذا كان نظام الملفات لا يدعمه ، فسيؤدي ذلك إلى تقليل أداء النظام بشكل عام.



لتحسين الرسائل ، تحتاج إلى فهم واضح للتوقعات الوظيفية وغير الوظيفية للنظام والتخطيط للجودة والكمية المطلوبة للرسائل. يجب أن تكون كل مجلة ذات معنى ومناسبة للسياق: اكتب دائمًا باختصار وفي صلب الموضوع.



2020-11-11 13:52:27 DEBUG  Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERROR  Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)

      
      





قم بإنشاء معرفات مرجعية ، وأسماء مستعارة ، وقوالب مبسطة للرسائل الطويلة والمستخدمة بشكل متكرر



بدلاً من كتابة وصف كامل في كل مرة ، حاول إنشاء معرفات مرجعية أو قوالب مبسطة لتمثيل أوصاف طويلة ومتكررة في السجل. يؤدي ذلك إلى تقليل العدد الإجمالي للرسائل وطولها ، كما يزيد من المرونة لإخفاء معلومات معينة. على سبيل المثال ، بدلاً من وصف ثغرة أمنية في سجل نصي ، من الأفضل استخدام اسم مستعار أو معرف بحيث يمكن للخبراء المتخصصين فقط فهم السيناريو الحالي.



2020-11-11 13:52:27 ERROR  DB:22 - Failed to write (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied" error message

      
      





استخدم الطوابع الزمنية الصحيحة



تسمح لك الطوابع الزمنية بفهم تسلسل الأحداث ، فهي ضرورية لتصحيح الأخطاء والتحليل. عند تحديد الوقت ، يوصى باستخدام القيم الأكثر تفصيلاً (على سبيل المثال ، على مستوى المللي ثانية أو الميكروثانية) حتى يسهل التعرف على الأحداث المجاورة. تأكد أيضًا من وجود الطوابع الزمنية في بداية الرسالة بالتنسيق yyyy-mm-dd HH: mm: ss. حدد دائمًا منطقتك الزمنية إلا إذا كنت تستخدم الوقت الافتراضي للخادم (UTC).



// with default server time (UTC)2020-11-11 13:52:12 INFO  XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO  XYZ Integration API Manager v2.0.0

      
      





توفير مصدر أو أصل بيانات السجل (لـ DEBUG و TRACE و ERROR)



هذا مفيد جدًا لتحديد الموقع الذي أدى إلى الرسالة المقابلة بوضوح. تسمح لك بعض أطر التسجيل بتحديد المصادر على المستوى الأكثر تفصيلاً (وصولاً إلى اسم الملفات بأرقام الأسطر) ، ولكن في أغلب الأحيان ، يكفي ذكر الفئة أو الوظيفة أو اسم الملف فقط.



2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...

      
      





يجب أن تكون كل مجلة فريدة داخل النظام



يرتكب معظم المبتدئين نفس الخطأ - يقومون بنسخ ولصق عينة من الرسائل في ملفات مختلفة ، وجمع السجل النهائي من نفس الأسطر القادمة من أجزاء مختلفة من النظام. في هذه الحالة ، من الصعب تعقب الموقع المحدد الذي أدى إلى بدء الحدث. إذا تعذر تغيير مجموعة الكلمات ، فعليك على الأقل ذكر المصدر في الرسالة بحيث تختلف السطور الموجودة في الملف النهائي عن بعضها البعض. أيضًا ، إذا تم التعامل مع التسجيل بواسطة الفئة الأصلية ، فأرسل معرفًا عند التهيئة واستخدمه لتسجيل الرسائل حول سلوك الفئات الفرعية.



2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all

      
      





أضف معرفًا متتبعًا أو رمزًا مميزًا للرسالة إلى الرسالة



عند دخول حدث أو رسالة إلى النظام ، يتم عادةً تعيين معرف فريد له. يمكن تمريرها إلى مراحل معالجة أخرى لتتبع حركة الحدث عبر النظام ، وهو أمر مفيد لتصحيح الأخطاء والمعالجة المتزامنة والعمليات التي تعتمد على البيانات. من الناحية المثالية ، يجب أن يكون للنظام معرف حدث فريد في جميع الوحدات والخدمات.



[87d4s-a98d7-9a8742jsd] Request Body: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "option_val": "IBM",
 "req_type_id": "0013",
 "data": {...........}
[87d4s-a98d7-9a8742jsd] Sending request to RefData: href="http://10.244.2.168:8280/v1

      
      





تطابق معرفات في نقاط الانتقال



في حالات معينة ، خاصة عند نقل حدث من نظام إلى آخر ، تتغير المعرفات وفقًا للاتفاقية المعتمدة في النظام الآخر. في نقاط الانتقال هذه ، من الضروري الإشارة صراحة إلى المراسلات بين المعرف القديم والجديد في رسالة منفصلة ، مع إضافة السياق الضروري.



[1000508] ***** Incoming request from 10.244.2.168:3000 *****
[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508
[1000508] Transaction successfully added to Rabbit Queue

      
      





حدد معرفات جميع طبعات الخدمة



معظم أنظمة المؤسسات عبارة عن منصات حوسبة موزعة ، حيث يوجد العديد من مثيلات نفس الخدمات مع تكوينات تطبيقات وموارد وإصدارات وخصائص شبكة متنوعة. من المستحسن أن تقوم بتعيين معرفات للحالات واستخدامها للتواصل بين الخدمات.



2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)

      
      





تكوين مستوى تسجيل نشط



يجب تغيير مستوى التسجيل النشط وفقًا لبيئة النشر. بالنسبة للإنتاج ، يوصى بإخراج سجلات تصل إلى مستوى INFO. في البيئات الأخرى ، يتم إخراج السجلات وصولاً إلى مستوى DEBUG أو TRACE ، اعتمادًا على مستوى التفاصيل المطلوبة من قبل فرق التطوير والعمليات.



// Active Log Level = DEBUG2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...// Active Log Level = INFO2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID API_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 04 (INFO)
2020-11-11 13:52:31 INFO  app - Started listening...

      
      





توفير سياق كافٍ للأخطاء والأعطال



تتطلب الأخطاء والإخفاقات إجراء تحقيق شامل. للقيام بذلك ، يجب أن يزود التطبيق الخبراء المتخصصين بالمعلومات التي يحتاجون إليها ، بالإضافة إلى سياق التكنولوجيا والأعمال. على سبيل المثال ، إذا تعذر معالجة طلب أو رسالة ، فمن المفيد جدًا تسجيل نص الطلب الفاشل بالإضافة إلى الخطأ.



[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)[1000508] Failed Message: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "req_type_id": "0013",
 "data": {...........}
}

      
      





نسخ معاملات البيانات احتياطيًا بالأدلة (لا تفترض!)



لكل عملية بيانات ، لا تعتبر أنها كانت ناجحة. تحقق دائمًا من الحالة النهائية بالأدلة. على سبيل المثال ، عند إنشاء سجل أو تحديثه أو حذفه في قاعدة البيانات ، فإنه يقوم بإرجاع عداد للسجلات التي تم تغييرها والسجل المحدث نفسه. تحقق دائمًا من العداد أو النتيجة المتوقعة. مثال آخر: عند إدراج سجل في بنية بيانات (على سبيل المثال ، في قائمة انتظار) ، تحقق مما إذا كان حجمه قد زاد. افترض أن نظامك يستخدم عمليات متزامنة ، لكن قائمة الانتظار لا تدعمها. ثم يمكنك أن تفقد بعض السجلات ، والطريقة الوحيدة لاكتشاف مثل هذه الأخطاء المخفية في الكود هي التحقق من الطول.



DEBUG  BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG  BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24

      
      





تشفير أو إخفاء البيانات الحساسة



عادة ، يتطلب القانون إخفاء و / أو تشفير المعلومات السرية للمستخدمين والأنظمة الداخلية. قد تختلف المتطلبات التنظيمية حسب مجال عملك ومكان عملك. تعرف على جميع الفروق الدقيقة وتنفيذ الإجراءات الصحيحة في التطبيق. في بعض الحالات ، قد تحتاج إلى إرسال استراتيجية التسجيل إلى خدمة الأمان والحصول على موافقتها أو شهادتها قبل التفعيل.



[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Request Body: {
”user_id”:”XXXXXXXXXX”,
”personal_details”:{
  ”firstName”:”XXXXXXXXXX”,
  ”lastName”:”XXXXXXXXXX”,
  ”DOB”:”XXXXXXXXXX”,
  ”gender”:”Male”,
  ”proffessional”:”Software Architect”,
  ”industry”:”IT”,
  ”SSN”:”XXXXXXXXXX”
},
”address_history”:[
  {”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”},
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”},  
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”}
],
”card_info”:[
  {”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”},
  {”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}
]
}

      
      





قم بتكوين تسمية ملف السجل وسياسات التدوير وأحجام التخزين وإجراءات النسخ الاحتياطي



إذا قمت بكتابة سجلات إلى ملفات ، فتأكد من تخزينها على قرص منفصل لا يؤثر على التطبيق قيد التشغيل بأي شكل من الأشكال (على سبيل المثال ، يمكنك تخصيص وحدة تخزين على خادم بعيد وإرفاقها بخادم التطبيق). اكتشف أيضًا تواتر تسجيل دفتر اليومية وكيف تنمو الملفات. تأكد من أن لديك سياسة تدوير السجل مع اصطلاحات التسمية الصحيحة (على سبيل المثال ، إضافة طابع زمني إلى الاسم عند الإنشاء) للحفاظ على الحجم المثالي وعدد الملفات. يجب أن يكون لديك أيضًا آلية للنسخ الاحتياطي للسجلات القديمة في مكان آمن ، وآلية لتنظيف التخزين بانتظام. اعتمادًا على مجال عملك ، يمكنك إعداد نسخة احتياطية موقوتة (عادة كل بضعة أشهر أو سنوات) ، وحذف جميع الملفات السابقة في نهاية الفترة.



[ec2-user@ip-XXX-XX-X-XXX logs]$ ls
..
APIM_V2_I02-2020-11-20_04:38:43.log
APIM_V2_I02-2020-11-23_02:05:35.log
APIM_V2_I02-2020-11-24_04:38:17.log
APIM_V2_I02-2020-11-27_03:28:37.log
APIM_V2_I02-2020-11-27_12:06:45.log
...

      
      





4.





من الممارسات الشائعة جدًا بين مطوري تطبيقات المؤسسات إنشاء خادم أو موقع يمكن الوصول إليه مركزيًا لتجميع السجلات. عادةً ما تتعقب هذه المجمعات سجلات ليس فقط التطبيقات ، ولكن أيضًا للأجهزة وأنظمة التشغيل (على سبيل المثال ، Linux Syslog) والشبكات والجدران النارية وقواعد البيانات وما إلى ذلك. بالإضافة إلى ذلك ، فإنها تفصل ملفات السجل عن خوادم التطبيق وتسمح لك بتخزين السجلات في تنسيقات محمية ومنظمة وفعالة لفترة أطول. في بعض الصناعات (مثل البنوك والتمويل) ، من الضروري تخزين السجلات في كل من التخزين المحلي والمركزي حتى لا يتمكن المهاجمون من الوصول إلى كلا المكانين وإزالة الأدلة على أنشطتهم في نفس الوقت. لذلك يمكن أن يساعد التكرار في البيانات وعدم تطابق البيانات بين المتجرين في اكتشاف عمليات التطفل.



اكتب موزعي وتتبع السجلات بحكمة



تم تضمين القدرة على كتابة الموزعات والمرشحات في معظم أدوات مراقبة السجل - ما يسمى بتكامل إدارة الأحداث ومعلومات الأمان (SIEM) . يساعد الموزعون في الاحتفاظ بالسجلات بتنسيقات أكثر انسيابية ، ويصبح الاستعلام عن البيانات أسهل وأسرع. أيضًا ، يمكن نقل البيانات المنظمة بشكل صحيح إلى أنظمة البحث عن الشذوذ والرصد الاستباقي والتنبؤ بالأحداث المستقبلية. هذه الأدوات قوية جدًا في رسم البيانات بناءً على السلاسل الزمنية وفي الوقت الفعلي.



قم بإعداد التنبيهات ودفع الإخطارات للحوادث الخطيرة



تتيح لك جميع أدوات مراقبة السجلات تقريبًا تعيين عتبات محددة لمستويات معينة. عندما يصل النظام إلى هذه القيم ، تكتشفها الأداة مسبقًا ، وتساعد في تسجيل البيانات ، وتُخطر مسؤولي النظام من خلال التنبيهات ، وواجهات برمجة تطبيقات الإشعارات (مثل واجهة برمجة تطبيقات Slack Audit Logs ) ، ورسائل البريد الإلكتروني ، وما إلى ذلك ، ويمكن أيضًا تكوينها مسبقًا لبدء العمليات الآلية. مثل التدرج الديناميكي ، والنسخ الاحتياطية للنظام ، وحمل التحميل ، وما إلى ذلك. ولكن إذا كنت تستثمر في برامج مراقبة السجلات التجارية ، فقم بإلقاء نظرة جيدة عليها لأن مثل هذه الأدوات يمكن أن تكون مبالغة في استخدام أنظمة البرامج الصغيرة والمتوسطة الحجم.



5. الأدوات الموصى بها



أطر التسجيل



JavaScript / TypeScript: Log4js / pino

Java: Log4j

Golang: Logrus Serverless

-function: aws-lambda-powertools-python / مكتوب ذاتيًا



استكشاف السجلات وتجميعها ومراقبتها



أدوات CLI: أقل ،

أدوات سحابة vim : Fluentd ، أدوات AWS CloudWatch

SIEM : SolarWinds ، Splunk ، McAfee ESM ، DataDog ، IBM QRadar

أخرى: ELK Stack (ElasticSearch ، Logstash ، Kibana ، Beats) ، Loggly



All Articles