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

السجلات النصية والسجلات المنظمة

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

اختر تنسيق السجلات

استخدم JSON، مع كائن واحد في كل سطر. استخدم أسماء الحقول نفسها في كل الخدمات. يسرد هذا الجدول الحقول الأساسية والأسماء المقابلة لها في نموذج بيانات السجلات في OpenTelemetry وفي LogBrew. تتراوح أرقام الخطورة في OpenTelemetry من 1 إلى 24. يبدأ INFO عند 9، وWARN عند 13، وERROR عند 17، وFATAL عند 21. ويقبل LogBrew سجلات OTLP مباشرة. راجع أرسل بيانات OpenTelemetry.

أفضل ممارسات التسجيل

أبقِ الرسالة ثابتة

اكتب "payment failed" وضع معرّف طلب الشراء في حقل. تتيح لك الرسالة الثابتة تجميع نوع حدث واحد وعدّه وإطلاق التنبيهات عليه.

استخدم اسمًا واحدًا لكل حقل

اختر order_id أو orderId مرة واحدة، واستخدمه في كل الخدمات. استخدم أسماء الاصطلاحات الدلالية في OpenTelemetry للحقول الشائعة، مثل http.response.status_code.

اختر المستوى حسب الإجراء الذي يتطلبه

يعني error أن عملية فشلت. ويعني warning أن البرنامج تعافى. ويؤكد info أن العمل يسير بشكل عادي. استخدم debug فقط أثناء تشخيص خلل.

اكتب الوقت بتوقيت UTC

استخدم RFC 3339 مع أجزاء الألف من الثانية وفارق التوقيت، مثل 2026-11-07T14:21:19.773+00:00. دون UTC وأجزاء الألف من الثانية، تُرتَّب السجلات القادمة من مناطق زمنية مختلفة، أو السجلات التي تقع في الثانية نفسها، بترتيب خاطئ.

أضف معرّف التتبّع ومعرّف الـ Span

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

اضبط الخدمة والبيئة والإصدار مرة واحدة

اضبطها عند بدء التشغيل، وليس في كل استدعاء. فغياب الإصدار يُخفي عملية النشر التي سبّبت التغيير.

سجّل الخطأ مرة واحدة حيث تعالجه

أضف نوع الخطأ ورسالته. لا تسجّل الخطأ نفسه مرة أخرى في كل طبقة.

أبعد الأسرار والبيانات الشخصية عن السجلات

لا تسجّل كلمات المرور أو الرموز المميزة أو ملفات تعريف الارتباط أو متون الطلبات أو عناوين URL الكاملة مع سلاسل الاستعلام. استخدم ميزة الحجب في المسجِّل. راجع التحكم في البيانات الملتقطة.

استخدم أسماء حقول ثابتة

لا تستخدم القيم كأسماء حقول، مثل {"ord_1001": "failed"}. عندها تضيف كل قيمة جديدة حقلًا جديدًا، ولا تجد تصفية واحدة كل طلبات الشراء.

اكتب JSON إلى المخرج القياسي في بيئة الإنتاج

استخدم تنسيقًا سهل القراءة في التطوير فقط.

التسجيل المنظم في Python

لا تحتوي الوحدة القياسية logging على منسِّق JSON. يكتب هذا المنسِّق الحقول الأساسية والقيم الواردة في extra={"fields": {...}}.
لإرسال السجلات نفسها إلى LogBrew، أضف LogBrewLoggingHandler. فهو يرسل الرسالة والمستوى والمسجِّل كحقول، ويرسل القيم الأولية في extra كبيانات وصفية. راجع تسجيل السجلات في Python.

التسجيل المنظم في Node.js

يكتب Pino افتراضيًا سطر JSON واحدًا لكل سجل. ويكتب Winston بتنسيق JSON باستخدام winston.format.json(). وتحتفظ المكتبتان بالحقول القادمة من الاستدعاء ومن المسجِّلات الفرعية. راجع تسجيل السجلات في Node.js لإعداد المكتبتين ولمعرّف التتبّع في سجلات Express.

ابحث في السجلات المنظمة في LogBrew

يخزّن LogBrew كل سجل مع رسالته ومستواه ومسجِّله وبياناته الوصفية وتتبّعه. صفِّ السجلات حسب هذه الحقول من الـ CLI.
يمكن للـ API أيضًا تصفية السجلات حسب قيم البيانات الوصفية ذات الأنواع، مثل رقم يساوي 500 أو أكثر. راجع عوامل تصفية الاستعلام.