---
read_when:
    - آماده‌سازی گزارش اشکال یا درخواست پشتیبانی
    - اشکال‌زدایی خرابی‌های Gateway، راه‌اندازی‌های مجدد، فشار حافظه یا بارهای داده‌ای بیش‌ازحد بزرگ
    - بررسی اینکه چه داده‌های عیب‌یابی ثبت یا پنهان‌سازی می‌شوند
summary: ایجاد بسته‌های عیب‌یابی Gateway قابل‌اشتراک‌گذاری برای گزارش‌های اشکال
title: برون‌بری عیب‌یابی
x-i18n:
    generated_at: "2026-05-02T11:45:36Z"
    model: gpt-5.5
    provider: openai
    source_hash: 4d1f7c1e1d96aeeebe30b30c8a23ec3c7b0fb4938f15a3783bf22e861770bf78
    source_path: gateway/diagnostics.md
    workflow: 16
---

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

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

## شروع سریع

```bash
openclaw gateway diagnostics export
```

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

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

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

```bash
openclaw gateway diagnostics export --json
```

## دستور چت

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

1. در گفت‌وگویی که مشکل را در آن دیدید، `/diagnostics` را ارسال کنید. اگر کمک می‌کند، یک یادداشت کوتاه اضافه کنید، برای مثال `/diagnostics bad tool choice`.
2. OpenClaw پیش‌درآمد تشخیص را می‌فرستد و یک تأیید اجرای صریح درخواست می‌کند. این تأیید `openclaw gateway diagnostics export --json` را اجرا می‌کند. تشخیص‌ها را از طریق قانون اجازه‌دادن به همه تأیید نکنید.
3. پس از تأیید، OpenClaw با گزارشی قابل چسباندن پاسخ می‌دهد که شامل مسیر بسته محلی، خلاصه manifest، نکات حریم خصوصی و شناسه‌های نشست مرتبط است.

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

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

این باعث می‌شود حلقه رایج اشکال‌زدایی Codex کوتاه باشد: رفتار نادرست را در Telegram، Discord یا کانال دیگری ببینید، `/diagnostics` را اجرا کنید، یک‌بار تأیید کنید، گزارش را با پشتیبانی به اشتراک بگذارید، سپس اگر می‌خواهید رشته بومی Codex را خودتان بررسی کنید، دستور چاپ‌شده `codex resume <thread-id>` را به‌صورت محلی اجرا کنید. برای این گردش کار بررسی، [Codex harness](/fa/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) را ببینید.

## خروجی شامل چه چیزهایی است

فایل zip شامل موارد زیر است:

- `summary.md`: نمای کلی خوانا برای انسان جهت پشتیبانی.
- `diagnostics.json`: خلاصه قابل‌خواندن توسط ماشین از پیکربندی، لاگ‌ها، وضعیت، سلامت و داده‌های پایداری.
- `manifest.json`: فراداده خروجی و فهرست فایل‌ها.
- شکل پیکربندی پاک‌سازی‌شده و جزئیات غیرمحرمانه پیکربندی.
- خلاصه‌های لاگ پاک‌سازی‌شده و خطوط لاگ اخیر با ویرایش محتوای حساس.
- snapshotهای best-effort از وضعیت و سلامت Gateway.
- `stability/latest.json`: جدیدترین بسته پایداری ماندگارشده، در صورت وجود.

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

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

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

- نام‌های زیرسامانه، شناسه‌های Plugin، شناسه‌های ارائه‌دهنده، شناسه‌های کانال و حالت‌های پیکربندی‌شده
- کدهای وضعیت، مدت‌زمان‌ها، شمارش بایت، وضعیت صف و خوانش‌های حافظه
- فراداده لاگ پاک‌سازی‌شده و پیام‌های عملیاتی ویرایش‌شده
- شکل پیکربندی و تنظیمات ویژگی غیرمحرمانه

خروجی این موارد را حذف یا ویرایش می‌کند:

- متن چت، promptها، دستورالعمل‌ها، بدنه‌های Webhook و خروجی‌های ابزار
- اعتبارنامه‌ها، کلیدهای API، توکن‌ها، کوکی‌ها و مقادیر محرمانه
- بدنه‌های خام درخواست یا پاسخ
- شناسه‌های حساب، شناسه‌های پیام، شناسه‌های خام نشست، نام‌های میزبان و نام‌های کاربری محلی

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

## ضبط‌کننده پایداری

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

همان Heartbeat تشخیصی، وقتی Gateway همچنان در حال اجراست اما حلقه رویداد Node.js یا CPU اشباع به نظر می‌رسد، نمونه‌های زنده‌بودن را ضبط می‌کند. این رویدادهای `diagnostic.liveness.warning` شامل تأخیر حلقه رویداد، بهره‌برداری حلقه رویداد، نسبت هسته CPU و شمارش نشست‌های فعال/در انتظار/صف‌شده هستند. نمونه‌های بیکار در telemetry با سطح `info` باقی می‌مانند؛ آن‌ها فقط وقتی کار تشخیصی فعال، در انتظار یا صف‌شده باشد به‌عنوان هشدارهای Gateway لاگ می‌شوند. آن‌ها به‌خودی‌خود Gateway را restart نمی‌کنند.

ضبط‌کننده زنده را بررسی کنید:

```bash
openclaw gateway stability
openclaw gateway stability --type payload.large
openclaw gateway stability --json
```

پس از یک خروج مرگبار، timeout هنگام shutdown یا شکست startup هنگام restart، جدیدترین بسته پایداری ماندگارشده را بررسی کنید:

```bash
openclaw gateway stability --bundle latest
```

از جدیدترین بسته ماندگارشده یک zip تشخیصی ایجاد کنید:

```bash
openclaw gateway stability --bundle latest --export
```

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

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

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

- `--output <path>`: نوشتن در یک مسیر zip مشخص.
- `--log-lines <count>`: بیشینه خطوط لاگ پاک‌سازی‌شده برای درج.
- `--log-bytes <bytes>`: بیشینه بایت‌های لاگ برای بررسی.
- `--url <url>`: URL WebSocket مربوط به Gateway برای snapshotهای وضعیت و سلامت.
- `--token <token>`: توکن Gateway برای snapshotهای وضعیت و سلامت.
- `--password <password>`: رمز عبور Gateway برای snapshotهای وضعیت و سلامت.
- `--timeout <ms>`: timeout مربوط به snapshot وضعیت و سلامت.
- `--no-stability-bundle`: رد کردن جست‌وجوی بسته پایداری ماندگارشده.
- `--json`: چاپ فراداده خروجی قابل‌خواندن توسط ماشین.

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

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

```json5
{
  diagnostics: {
    enabled: false,
  },
}
```

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

## مرتبط

- [بررسی‌های سلامت](/fa/gateway/health)
- [CLI Gateway](/fa/cli/gateway#gateway-diagnostics-export)
- [پروتکل Gateway](/fa/gateway/protocol#system-and-identity)
- [لاگ‌گیری](/fa/logging)
- [خروجی OpenTelemetry](/fa/gateway/opentelemetry) — جریان جداگانه برای پخش تشخیص‌ها به یک جمع‌آوری‌کننده
