Gateway
سجل التدقيق
سجل التدقيق
يحتفظ Gateway بسجل تدقيق محدود يقتصر على البيانات الوصفية في قاعدة بيانات حالة OpenClaw المشتركة. ويجيب عن أسئلة تشغيلية مثل «أي وكيل جرى تشغيله، ومتى، وكيف انتهى»، و«ما إجراءات الأدوات التي نفّذها تشغيلٌ ما»، وعند تمكين تدقيق الرسائل، «هل وصلت رسالة واردة مقبولة إلى الإرسال» و«هل وصلت رسالة صادرة إلى حالة تسليم نهائية».
يخزّن السجل الهوية، والترتيب، والمنشأ، والإجراء، والحالة، ورموز النتائج الموحّدة. ولا يخزّن مطلقًا المطالبات، أو نصوص الرسائل، أو وسيطات الأدوات، أو نتائج الأدوات، أو المرفقات، أو أسماء الملفات، أو عناوين URL، أو مخرجات الأوامر، أو نصوص الأخطاء الخام.
فئات السجلات
تُسجّل أحداث التشغيل والأدوات كلما كان التدقيق مفعّلًا (وهو الإعداد الافتراضي). أما أحداث دورة حياة الرسائل فهي اختيارية ومعطّلة افتراضيًا.
| الفئة | الإجراءات | الافتراضي |
|---|---|---|
| تشغيلات الوكلاء | agent.run.started، agent.run.finished |
مفعّل |
| إجراءات الأدوات | tool.action.started، tool.action.finished |
مفعّل |
| الرسائل | message.inbound.processed، message.outbound.finished |
معطّل |
يحمل كل سجل معرّف حدث ثابتًا، وتسلسلًا رتيبًا للسجل،
وطابعًا زمنيًا لدورة الحياة، والجهة الفاعلة، والإجراء، والحالة، وschemaVersion: 1، و
redaction: "metadata_only". راجع سجلات التدقيق للاطلاع على مرجع
الحقول الكامل ومرشحات الاستعلام.
أحداث دورة حياة الرسائل
اضبط audit.messages لاختيار ما
يُسجّل، ثم أعد تشغيل Gateway:
off(الافتراضي): لا توجد سجلات للرسائل.direct: الرسائل في المحادثات المباشرة فقط.all: الرسائل المباشرة ورسائل المجموعات والقنوات.
ينشئ حدّان مرجعيان سجلات الرسائل:
- تُكتب صفوف الوارد عندما تصل رسالة مقبولة إلى الإرسال الأساسي، بما في ذلك نتائج المعالجة المكررة والنهائية.
- تُكتب صفوف الصادر عندما يصل التسليم الدائم المشترك إلى
نتيجة نهائية: مُرسلة، أو مكبوتة، أو فاشلة، أو
unknownصريحة لعمليات الإرسال الملتبسة بسبب التعطل. وتشمل استعادة قائمة الانتظار ونتائج قائمة الرسائل المتعذّر تسليمها. وتحصل كل حمولة رد منطقية أصلية على صف نهائي واحد؛ ويُجمّع التقسيم إلى أجزاء والتوزيع المتشعّب عبر المحوّلات فيresultCount.
تصنيف نوع المحادثة
يمثّل وضع direct حدًا للخصوصية، لذلك لا تُصنّف الرسالة كمحادثة مباشرة
إلا عندما تثبت حقائق الوجهة ذلك: بأن يصرّح مسار الإرسال
بنوع محادثة الوجهة، أو أن يسمّي مسار جلسة التسليم بدقة
القناة والنظير اللذين يجري التسليم إليهما. ويمكن للإشارات الأضعف، مثل حالة السياسة
أو المحادثة الأصلية، تصنيف الرسالة على أنها group (مما يستبعدها
من جمع direct) لكنها لا تستطيع مطلقًا الادعاء بأنها direct. وتُصنّف الرسائل التي
لا يمكن إثبات أنها مباشرة على أنها unknown ولا تُسجّل في
وضع direct. ولذلك قد تسجّل القنوات التي لا تصرّح بأنواع الدردشة
صفوفًا أقل في وضع direct مما تسجّله في وضع all.
نموذج الخصوصية
لا تخزّن صفوف الرسائل مطلقًا معرّفات المنصة الخام. وتُصدّر معرّفات الحساب،
والمحادثة، والرسالة، والهدف، عند توفر إمكانية الربط،
فقط كأسماء مستعارة مفتاحية محلية للتثبيت
(hmac-sha256:v1:<keyId>:<digest>):
- يُنشأ مفتاح HMAC عند أول استخدام، ويُفصل نطاقه لكل نوع من المعرّفات، ويقيم في قاعدة بيانات الحالة نفسها التي تضم السجل.
- تظل الأسماء المستعارة ثابتة ضمن تثبيت واحد، بحيث يمكن ربط الصفوف المتعلقة بالمحادثة نفسها من دون كشف معرّف المنصة.
- هذا ربط وليس إخفاءً للهوية: فأي شخص لديه صلاحية قراءة قاعدة بيانات الحالة يمتلك المفتاح أيضًا ويمكنه اختبار المعرّفات الخام المرشحة مقابل الأسماء المستعارة. ولا تتضمن عمليات التصدير عبر RPC وCLI المفتاح مطلقًا.
- إذا كانت مادة المفتاح مفقودة أو تالفة مع الاحتفاظ بصفوف الرسائل، يفشل Gateway بصورة مغلقة ويتجاهل سجلات الرسائل الجديدة بدلًا من التدوير الصامت إلى مفتاح جديد، وهو ما كان سيجزّئ الربط.
تحتفظ سجلات التشغيل والأدوات بـ sessionKey وsessionId لأغراض الربط؛
وقد تحتوي مفاتيح الجلسات القياسية نفسها على معرّفات حسابات المنصة أو النظراء.
أما سجلات الرسائل فتحذف كليهما عمدًا.
تظل صادرات التدقيق بيانات وصفية تشغيلية حساسة حتى من دون محتوى: إذ يمكن للتوقيت والقنوات والنتائج والأسماء المستعارة الثابتة أن تربط النشاط. احمِ الصادرات باستخدام ضوابط الوصول وممارسات الاحتفاظ نفسها المطبقة على سجلات المشغّلين الأخرى.
حدود التغطية والإثبات
يعمل السجل بأفضل جهد وهو محدود عمدًا. تعامل معه بوصفه دليلًا على ما جرى تسجيله، لا إثباتًا لما حدث:
- غياب صف لا يثبت شيئًا. فعمليات إسقاط الرسائل الواردة قبل القبول، وعمليات الإرسال من عمليات CLI التي لا يتوفر لها مسجّل Gateway قيد التشغيل، والمسارات المحلية للـ Plugin أو مسارات الإرسال المباشر التي تتجاوز التسليم الدائم المشترك، لا تترك أي سجل.
- تمر عمليات الكتابة عبر عامل خلفية محدود؛ ويؤدي فشل العامل أو امتلاء قائمة الانتظار إلى إسقاط السجلات وتسجيل تحذير تشغيلي واحد.
- تُسجّل عمليات الإرسال الصادرة الملتبسة بسبب التعطل على أنها
unknownبدلًا من اختلاق نتائج.
يدعم هذا السجل تصحيح الأخطاء والمراجعة التشغيلية. وهو ليس أرشيف امتثال بلا فقدان؛ فإذا كنت بحاجة إلى ذلك، فاستخدم نظامًا خارجيًا تغذّيه OpenTelemetry أو أدوات على مستوى القناة.
التخزين والاحتفاظ والترحيل
تقيم السجلات في قاعدة بيانات الحالة المشتركة (state/openclaw.sqlite) وتُكتب
خارج المسار الحرج للتسليم. ولا تعيد الاستعلامات مطلقًا سجلات أقدم من 30
يومًا، ويقتصر السجل على 100,000 صف؛ وتُزال الصفوف المنتهية أثناء
بدء التشغيل، والصيانة كل ساعة، وعمليات الكتابة اللاحقة. وتستمر صيانة الاحتفاظ
حتى عندما يكون الجمع معطّلًا.
تؤدي الترقية من Gateway يستخدم السجل السابق المقتصر على التشغيل والأدوات إلى ترحيل
المخطط تلقائيًا عند بدء التشغيل (أو عبر openclaw doctor --fix)؛ ويُحتفظ
بالصفوف الموجودة وتسلسلاتها في السجل.
الاستعلام
- CLI:
openclaw auditمع مرشحات للوكيل، والجلسة، والتشغيل، والنوع، والحالة، والاتجاه، والقناة، والحدود الزمنية، والتصفح بالمؤشر. - Gateway RPC:
audit.activity.list(يتطلبoperator.read) يعيد اتحاد أحداث النشاط V1 ذي الإصدارات؛ وتظل RPC المشحونةaudit.listدون تغيير لعملاء التشغيل والأدوات الأقدم. راجع بروتوكول Gateway.
