خروجی عیب‌یابی

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 تأثیری ندارد.

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

مرتبط

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