فوائد تجميع السجلات | أصلي، ترجم بواسطة AI
فوائد تجميع السجلات (Logs)
عندما عملت كمقاول لأحد البنوك في السابق، استخدمنا منصة تطبيقات متعددة السحابات لخدمة الخدمات المصغرة (microservices). في ذلك الوقت، بدأت بتجميع السجلات أثناء عملي في الشركة.
مرت عدة سنوات، وما زلت أعتقد أنها واحدة من أفضل الطرق لمساعدتي في عملي أو في هندسة البرمجيات. مع مرور الوقت، أصبح في دليل سجلاتي المئات من ملفات السجلات.
ليس لدي أدلة فرعية محددة أو أسماء رسمية لملفات السجلات لتلك الملفات. أحيانًا، أستخدم فقط اسم مهمة JIRA كبادئة لاسم ملف السجل الخاص بي أو تلك الميزة. ثم أضيف رقمًا إلى اللاحقة. يصبح مثل mutual-fund-1.log، mutual-fund-2.log، إلخ. وهذا يعني أنه في الخدمة المصغرة mutual fund، لدي هذا السجل عند تشغيل تلك الخدمة المصغرة.
أحيانًا، عند العمل على مشاريع تخدم مناطق متعددة، سأضيف اسم البلد كلاحقة، مثل mutual-fund-cn-1.log، mutual-fund-sg-1.log. أسماء ملفات السجلات عشوائية إلى حد ما. لأنني في ذلك الوقت، كنت بحاجة للتركيز على مكدس الأخطاء أو استدعاء الوظيفة المحيطة.
سجلات البرامج مهمة. الجميع يعرف ذلك. ومع ذلك، أريد أن أبالغ في أهمية تجميع السجلات بدلاً من مجرد مشاهدتها في وحدة التحكم وتركها تذهب. ستعرف المزيد من الراحة عندما يستمر المشروع. لديك المزيد من الوقت للعثور على السجلات السابقة. قد تحتاج إلى معرفة ما إذا كان استدعاء إجراء مخزن لقاعدة بيانات مماثل قد حدث من قبل. قد تحتاج إلى معرفة ما إذا كان نفس الخطأ قد حدث من قبل. قد تحتاج إلى تذكر كيفية إصلاح هذه المشكلة في المرة الأخيرة.
هناك الكثير من التفاصيل في مشروع كبير أو عشرات الخدمات المصغرة. والأخطاء أو الاستثناءات أو المشاكل تتكرر مرارًا وتكرارًا. السجل يشبه المستند الجاري للبرنامج. ويتم إنشاؤه بواسطة البرنامج تلقائيًا دون كتابة بشرية. وبالنسبة للمطورين، هذه السجلات قابلة للقراءة. لذلك عند بدء مهمة جديدة أو إصلاح خطأ جديد، لديك المئات من السجلات في يدك لإصلاح هذا الخطأ الجديد. لست وحدك.
لماذا نجمعها؟ لأن الأشياء أو المعرفة تُنسى بسهولة.
تقدمت الحضارة البشرية عندما اخترعت الورق. وعندما اخترعت أجهزة الكمبيوتر، كان هناك مستوى آخر من الحضارة البشرية. الاحتفاظ بالملاحظات على الورق يشبه تجميع السجلات في أجهزة الكمبيوتر.
ليس فقط للبشر، ولكن لروبوتات الدردشة الذكية (AI chatbots)، وأدوات نماذج اللغة الكبيرة (LLM tooling)، أصبحت هذه السجلات أكثر أهمية. GreptimeDB، قاعدة بيانات لجمع وتحليل بيانات المراقبة الموحدة (المقاييس والسجلات والتتبع) التي تأسست في عام 2022 ليست صدفة.
لماذا لم أفعل ذلك من قبل؟ بعد أن عملت كمقاول للبنوك الكبيرة، احتجت إلى القيام بالمزيد من التعاون والعمل في مشاريع أكبر. قبل ذلك، معظم الوقت في الشركات الناشئة أو فترة تأسيس شركتي، كنت أعمل بمفردي. عندما عملت في LeanCloud من قبل، عملت على تطبيق المراسلة الفورية LeanChat لمدة نصف الوقت تقريبًا.
وعندما دخلت عالم الشركات الأكثر رسمية، كان تطوير المشاريع مختلفًا عن مشروعي الشخصي أو مشروع شركتي الناشئة. لديهم بيئات اختبار SIT و UAT. وغالبًا ما يكون بيئة الإنتاج مفتوحة فقط لعدد قليل من أعضاء الفريق. الحصول على السجلات منهم وإصلاح المشاكل يصبح طويلاً ومملًا إلى حد ما. وتشغيل المشروع يستغرق وقتًا، وغالبًا ما يستغرق مسار Jenkins نصف ساعة للتشغيل.
لذلك لا أستطيع تشغيل أو اختبار البرنامج مثل الفراشة. لا أستطيع إجراء نشر بمجرد كتابة أمر على جهاز الكمبيوتر الشخصي الخاص بي وتحميل الكود إلى الخادم للتشغيل.
لذلك بطريقة ما، يسمح لي ذلك بتجميع السجلات للحصول على المزيد من السياق للتعامل مع المهام. من الأفضل أن نصلح المشاكل من المحاولة الأولى. من الأفضل أن نتحقق من إصلاحنا في بضع مرات فقط. ليس من السهل علينا الحصول على سجلات البرنامج الذي يعمل في السحابة أو على خادم الشركة، لذلك من الأفضل نسخها وحفظها على الكمبيوتر المحمول المحلي لإجراء التحليل.
والآن، بالنسبة لمشاريعي الشخصية، سأقوم بتجميع السجلات أيضًا. لقد أصبحت عادة. بعد العمل في شركات كبيرة لعدة سنوات، أصبح لدي بطريقة ما المزيد من الصبر أو الإستراتيجية لجعل مشاريعي أكبر وأطول. لذلك أعلم أنني بحاجة إلى هذه السجلات مع مرور الوقت.
قد يقول أحدهم إنك تحتاج فقط إلى كود أنيق ومشروع عامل. لا تحتاج إلى تجميع السجلات أو تتبع مكدس الأخطاء. لا بأس. عندما يكون لدينا خطأ أو ميزة جديدة، يمكننا تشغيل البرنامج للحصول على السجلات الحالية. لا نحتاج إلى السجلات من عملية التطوير. إنها مثل السجلات التفصيلية للتجارب العلمية. للوهلة الأولى، يبدو الأمر جيدًا. ولكن على المدى الطويل، إذا أردت يومًا ما العمل عليها مرة أخرى، أو أردت مشاركتها، أو السماح للآخرين بتوليها، فقد لا يكون ذلك جيدًا.
أعتقد أنه قد تكون هناك فرص جيدة هنا. في الشركات، لماذا لا نشجع كل مطور على مشاركة سجلاته المجمعة؟ في مشاريع المصادر المفتوحة، يجب أن يكون لدينا ذلك أيضًا. لا نجد سجلات الآخرين جذابة لأننا لا نعرفها. نفقد السياق عند حفظ تلك السجلات. وداخلها، يبدو أن هناك الكثير من الرسائل غير ذات الصلة أو البسيطة.
ولكن الجهد المبذول لتجميع السجلات بسيط. إنه مجرد نسخ ولصق في كل مرة نرى فيها بعض السجلات، خاصة سجلات الأخطاء تلك. وماذا لو فعلنا ذلك بطريقة آلية؟ من الجيد تسجيل السجلات في دليل في كل مرة نقوم فيها بتشغيل مشروع، مثل مشاريع Spring Boot تلك.
يصبح العالم رقميًا أكثر فأكثر، لذا فإن تجميع سجلات البرامج الرقمية يشبه تمامًا تجميع الكتب في العالم المادي.