صدور اطلاعات تشخیصی

OpenClaw می‌تواند برای گزارش اشکال، یک فایل تشخیصی محلی .zip بسازد: وضعیت پاک‌سازی‌شدهٔ Gateway، سلامت، گزارش‌ها، ساختار پیکربندی و رویدادهای پایداری اخیرِ بدون بار داده.

تا پیش از بازبینی، بسته‌های تشخیصی را مانند اطلاعات محرمانه در نظر بگیرید. بارهای داده و اعتبارنامه‌ها عمداً حذف یا پنهان می‌شوند، اما بسته همچنان خلاصه‌ای از گزارش‌های محلی Gateway و وضعیت زمان اجرای میزبان را در بر دارد.

شروع سریع

openclaw gateway diagnostics export

مسیر فایل zip نوشته‌شده را نمایش می‌دهد. برای انتخاب مسیر خروجی:

openclaw gateway diagnostics export --output openclaw-diagnostics.zip

برای خودکارسازی:

openclaw gateway diagnostics export --json

فرمان گفت‌وگو

مالکان می‌توانند در هر مکالمه‌ای /diagnostics [note] را اجرا کنند تا یک خروجی محلی Gateway را به‌صورت گزارشی واحد و قابل کپی‌وچسباندن برای پشتیبانی درخواست کنند:

1. /diagnostics را، در صورت تمایل همراه با یادداشتی کوتاه (/diagnostics bad tool choice)، ارسال کنید.
2. OpenClaw یک مقدمه می‌فرستد و یک تأیید صریح برای اجرا درخواست می‌کند که فرمان openclaw gateway diagnostics export --json را اجرا می‌کند. تشخیص را از طریق یک قاعدهٔ «اجازه به همه» تأیید نکنید.
3. پس از تأیید، OpenClaw مسیر بستهٔ محلی، خلاصهٔ مانیفست، نکات حریم خصوصی و شناسه‌های نشست مرتبط را پاسخ می‌دهد.

در گفت‌وگوهای گروهی، مالک همچنان می‌تواند /diagnostics را اجرا کند، اما OpenClaw نتیجهٔ خروجی، درخواست‌های تأیید و تفکیک نشست/رشتهٔ Codex را به‌صورت خصوصی برای مالک می‌فرستد. گروه فقط اعلان کوتاهی می‌بیند که تشخیص به‌صورت خصوصی ارسال شده است. اگر مسیر خصوصی برای مالک وجود نداشته باشد، فرمان به‌صورت امن متوقف می‌شود و از مالک می‌خواهد آن را از یک پیام مستقیم اجرا کند.

هنگامی که نشست فعال از چارچوب بومی OpenAI Codex استفاده می‌کند، همان تأیید اجرا، بارگذاری بازخورد OpenAI برای رشته‌های Codex شناخته‌شده برای OpenClaw را نیز پوشش می‌دهد. این بارگذاری از فایل zip محلی Gateway جدا است و فقط برای نشست‌های چارچوب Codex انجام می‌شود. درخواست تأیید بیان می‌کند که تأیید کردن، بازخورد Codex را نیز ارسال می‌کند، بدون آنکه شناسه‌های نشست یا رشتهٔ Codex را فهرست کند. پس از تأیید، پاسخ کانال‌ها، شناسه‌های نشست OpenClaw، شناسه‌های رشتهٔ Codex و فرمان‌های محلی ازسرگیری برای رشته‌هایی را که به OpenAI ارسال شده‌اند فهرست می‌کند. رد یا نادیده‌گرفتن تأیید، خروجی‌گیری، بارگذاری بازخورد Codex و فهرست شناسه‌های Codex را انجام نمی‌دهد.

این کار چرخهٔ اشکال‌زدایی Codex را کوتاه می‌کند: رفتار نامناسبی را در یک کانال مشاهده کنید، /diagnostics را اجرا کنید، یک‌بار تأیید کنید، گزارش را به اشتراک بگذارید و سپس اگر می‌خواهید خودتان رشته را بررسی کنید، فرمان نمایش‌داده‌شدهٔ codex resume <thread-id> را به‌صورت محلی اجرا کنید. به چارچوب Codex مراجعه کنید.

محتوای خروجی

• summary.md: نمای کلی خوانا برای پشتیبانی.
• diagnostics.json: خلاصهٔ ماشین‌خوان از پیکربندی، گزارش‌ها، وضعیت، سلامت و داده‌های پایداری.
• manifest.json: فرادادهٔ خروجی و فهرست فایل‌ها.
• ساختار پاک‌سازی‌شدهٔ پیکربندی و جزئیات غیرمحرمانهٔ آن.
• خلاصه‌های پاک‌سازی‌شدهٔ گزارش‌ها و خطوط اخیر گزارش با اطلاعات حذف‌شده.
• تصویرهای لحظه‌ای وضعیت و سلامت Gateway به‌صورت بهترین تلاش.
• stability/latest.json: جدیدترین بستهٔ پایداری ذخیره‌شده، در صورت وجود.

حتی هنگامی که Gateway ناسالم است، خروجی همچنان مفید خواهد بود: اگر درخواست‌های وضعیت/سلامت ناموفق باشند، گزارش‌های محلی، ساختار پیکربندی و آخرین بستهٔ پایداری، در صورت وجود، همچنان جمع‌آوری می‌شوند.

مدل حریم خصوصی

حفظ می‌شوند: نام‌های زیرسامانه، شناسه‌های Plugin، شناسه‌های ارائه‌دهنده، شناسه‌های کانال، حالت‌های پیکربندی‌شده، کدهای وضعیت، مدت‌زمان‌ها، شمارش بایت‌ها، وضعیت صف، مقادیر حافظه، فرادادهٔ پاک‌سازی‌شدهٔ گزارش، پیام‌های عملیاتی با اطلاعات حذف‌شده، ساختار پیکربندی و تنظیمات غیرمحرمانهٔ قابلیت‌ها.

حذف یا پنهان می‌شوند: متن گفت‌وگو، اعلان‌ها، دستورالعمل‌ها، بدنه‌های Webhook، خروجی ابزارها، اعتبارنامه‌ها، کلیدهای API، توکن‌ها، کوکی‌ها، مقادیر محرمانه، بدنه‌های خام درخواست/پاسخ، شناسه‌های حساب، شناسه‌های پیام، شناسه‌های خام نشست، نام‌های میزبان و نام‌های کاربری محلی.

هنگامی که پیام گزارش شبیه متن کاربر، گفت‌وگو، اعلان یا بار دادهٔ ابزار باشد، خروجی فقط حذف‌شدن پیام و تعداد بایت‌های آن را نگه می‌دارد.

ثبت‌کنندهٔ پایداری

وقتی تشخیص فعال باشد، Gateway به‌طور پیش‌فرض یک جریان پایداری محدود و بدون بار داده ثبت می‌کند. این جریان واقعیت‌های عملیاتی را ثبت می‌کند، نه محتوا را.

همان Heartbeat، وقتی حلقهٔ رویداد یا CPU اشباع به نظر برسد، زنده‌بودن را نیز نمونه‌برداری می‌کند و رویدادهای diagnostic.liveness.warning را با تأخیر حلقهٔ رویداد، میزان استفاده از حلقهٔ رویداد، نسبت هستهٔ CPU، تعداد نشست‌های فعال/منتظر/درصف، مرحلهٔ کنونی راه‌اندازی/زمان اجرا (در صورت مشخص‌بودن)، بازه‌های زمانی اخیر مراحل و برچسب‌های محدود کار منتشر می‌کند. این موارد فقط هنگامی به خطوط گزارش سطح warn در Gateway تبدیل می‌شوند که کاری منتظر یا در صف باشد، یا کار فعال با تأخیر پایدار حلقهٔ رویداد هم‌پوشانی داشته باشد؛ در غیر این صورت، در سطح debug ثبت می‌شوند. نمونه‌های زنده‌بودن در حالت بیکار همچنان به‌عنوان رویدادهای تشخیصی ثبت می‌شوند، اما هرگز به‌تنهایی به هشدار ارتقا نمی‌یابند.

مراحل راه‌اندازی، رویدادهای diagnostic.phase.completed را با زمان ساعت واقعی و زمان‌بندی CPU منتشر می‌کنند. تشخیص اجرای تعبیه‌شدهٔ متوقف‌شده، هنگامی terminalProgressStale=true را تنظیم می‌کند که آخرین پیشرفت پل، نهایی به نظر رسیده باشد (برای مثال یک مورد پاسخ خام یا رویداد تکمیل پاسخ)، اما Gateway همچنان اجرای تعبیه‌شده را فعال در نظر بگیرد.

برای بررسی ثبت‌کنندهٔ زنده:

openclaw gateway stabilityopenclaw gateway stability --type payload.largeopenclaw gateway stability --json

برای بررسی جدیدترین بستهٔ ذخیره‌شده پس از خروج مرگبار، پایان مهلت خاموش‌شدن یا شکست راه‌اندازی مجدد:

openclaw gateway stability --bundle latest

برای ساخت فایل zip تشخیصی از جدیدترین بستهٔ ذخیره‌شده:

openclaw gateway stability --bundle latest --export

در صورت وجود رویدادها، بسته‌های ذخیره‌شده در ~/.openclaw/logs/stability/ قرار می‌گیرند.

گزینه‌های مفید

openclaw gateway diagnostics export \  --output openclaw-diagnostics.zip \  --log-lines 5000 \  --log-bytes 1000000

غیرفعال‌کردن تشخیص

تشخیص به‌طور پیش‌فرض فعال است. برای غیرفعال‌کردن ثبت‌کنندهٔ پایداری و جمع‌آوری رویدادهای تشخیصی:

{  diagnostics: {    enabled: false,  },}

غیرفعال‌کردن تشخیص، جزئیات گزارش اشکال را کاهش می‌دهد؛ اما بر ثبت عادی گزارش‌های Gateway تأثیری ندارد.

تصویرهای لحظه‌ای فشار بحرانی حافظه به‌طور پیش‌فرض خاموش هستند. برای ثبت تصویر لحظه‌ای پایداری پیش از OOM، افزون بر رویدادهای عادی تشخیصی:

{  diagnostics: {    memoryPressureSnapshot: true,  },}

این گزینه را فقط روی میزبان‌هایی استفاده کنید که می‌توانند پویش اضافی سامانهٔ فایل و نوشتن تصویر لحظه‌ای هنگام فشار بحرانی حافظه را تحمل کنند. وقتی تصویر لحظه‌ای خاموش است، رویدادهای عادی فشار حافظه همچنان واقعیت‌های RSS، هیپ، آستانه و رشد (rss_threshold، heap_threshold، rss_growth) را ثبت می‌کنند.

مرتبط

• بررسی‌های سلامت
• CLI مربوط به Gateway
• پروتکل Gateway
• ثبت گزارش
• خروجی OpenTelemetry - جریانی جداگانه برای ارسال پیوستهٔ داده‌های تشخیصی به یک گردآورنده