การส่งออกข้อมูลวินิจฉัย

OpenClaw สามารถสร้าง zip การวินิจฉัยภายในเครื่องสำหรับรายงานบั๊กได้ โดยรวม สถานะ Gateway, สุขภาพ, ล็อก, รูปแบบ config และเหตุการณ์เสถียรภาพล่าสุด ที่ไม่มี payload ซึ่งผ่านการทำให้ปลอดภัยแล้ว

ปฏิบัติกับชุดการวินิจฉัยเหมือนเป็นความลับจนกว่าคุณจะตรวจสอบแล้ว ชุดเหล่านี้ ออกแบบมาให้ละเว้นหรือแก้ไข payload และข้อมูลรับรอง แต่ยังคงสรุป ล็อก Gateway ภายในเครื่องและสถานะ runtime ระดับโฮสต์

เริ่มต้นอย่างรวดเร็ว

openclaw gateway diagnostics export

คำสั่งจะแสดงพาธ zip ที่เขียนไว้ หากต้องการเลือกพาธ:

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

สำหรับระบบอัตโนมัติ:

openclaw gateway diagnostics export --json

คำสั่งแชท

เจ้าของสามารถใช้ /diagnostics [note] ในแชทเพื่อขอ export Gateway ภายในเครื่องได้ ใช้สิ่งนี้เมื่อบั๊กเกิดขึ้นในการสนทนาจริงและคุณต้องการรายงานสำหรับฝ่ายสนับสนุน ที่คัดลอกและวางได้หนึ่งชุด:

1. ส่ง /diagnostics ในการสนทนาที่คุณพบปัญหา เพิ่มหมายเหตุสั้นๆ ถ้าช่วยได้ เช่น /diagnostics bad tool choice
2. OpenClaw จะส่งคำนำการวินิจฉัยและขออนุมัติ exec แบบชัดเจนหนึ่งครั้ง การอนุมัติจะเรียกใช้ openclaw gateway diagnostics export --json อย่าอนุมัติการวินิจฉัยผ่านกฎที่อนุญาตทั้งหมด
3. หลังอนุมัติ OpenClaw จะตอบกลับด้วยรายงานที่วางได้ ซึ่งประกอบด้วยพาธ bundle ภายในเครื่อง สรุป manifest, หมายเหตุความเป็นส่วนตัว และ session id ที่เกี่ยวข้อง

ในแชทกลุ่ม เจ้าของยังคงเรียกใช้ /diagnostics ได้ แต่ OpenClaw จะไม่ โพสต์รายละเอียดการวินิจฉัยกลับเข้าไปในแชทร่วม โดยจะส่งคำนำ พรอมป์อนุมัติ ผลลัพธ์ export ของ Gateway และรายละเอียด session/thread ของ Codex ให้เจ้าของผ่านเส้นทางอนุมัติส่วนตัว กลุ่มจะได้รับเพียงประกาศสั้นๆ ว่าขั้นตอนการวินิจฉัยถูกส่งเป็นส่วนตัวแล้ว หาก OpenClaw ไม่พบเส้นทางส่วนตัว ไปยังเจ้าของ คำสั่งจะล้มเหลวแบบปิดและขอให้เจ้าของเรียกใช้จากข้อความส่วนตัว

เมื่อ session ของ OpenClaw ที่ใช้งานอยู่ใช้ native OpenAI Codex harness การอนุมัติ exec เดียวกันจะครอบคลุมการอัปโหลด feedback ไปยัง OpenAI สำหรับ thread runtime ของ Codex ที่ OpenClaw รู้จักด้วย การอัปโหลดนั้นแยกจาก zip Gateway ภายในเครื่อง และจะปรากฏเฉพาะสำหรับ session ของ Codex harness ก่อนอนุมัติ พรอมป์จะอธิบายว่าการอนุมัติการวินิจฉัยจะส่ง feedback ของ Codex ด้วย แต่ จะไม่แสดง session id หรือ thread id ของ Codex หลังอนุมัติ การตอบกลับในแชทจะแสดง ช่องทาง, session id ของ OpenClaw, thread id ของ Codex และคำสั่ง resume ภายในเครื่อง สำหรับ thread ที่ถูกส่งไปยังเซิร์ฟเวอร์ของ OpenAI หากคุณปฏิเสธหรือไม่ตอบสนองต่อ การอนุมัติ OpenClaw จะไม่เรียกใช้ export, ไม่ส่ง feedback ของ Codex และ ไม่พิมพ์ id ของ Codex

สิ่งนี้ทำให้วงจรการดีบัก Codex ทั่วไปสั้นลง: พบพฤติกรรมที่ไม่ถูกต้องใน Telegram, Discord หรือช่องทางอื่น เรียกใช้ /diagnostics อนุมัติหนึ่งครั้ง แชร์ รายงานกับฝ่ายสนับสนุน แล้วเรียกใช้คำสั่ง codex resume <thread-id> ที่พิมพ์ออกมา ภายในเครื่อง หากคุณต้องการตรวจสอบ thread ของ native Codex ด้วยตนเอง ดู Codex harness สำหรับ เวิร์กโฟลว์การตรวจสอบนั้น

export มีอะไรบ้าง

zip ประกอบด้วย:

• summary.md: ภาพรวมที่มนุษย์อ่านได้สำหรับฝ่ายสนับสนุน
• diagnostics.json: สรุป config, ล็อก, สถานะ, สุขภาพ และข้อมูลเสถียรภาพที่เครื่องอ่านได้
• manifest.json: metadata ของ export และรายการไฟล์
• รูปแบบ config และรายละเอียด config ที่ไม่ใช่ความลับซึ่งผ่านการทำให้ปลอดภัยแล้ว
• สรุปล็อกที่ผ่านการทำให้ปลอดภัยแล้วและบรรทัดล็อกล่าสุดที่ถูกแก้ไขข้อมูลแล้ว
• snapshot สถานะและสุขภาพของ Gateway แบบ best-effort
• stability/latest.json: bundle เสถียรภาพที่คงอยู่ล่าสุด เมื่อมี

export มีประโยชน์แม้ Gateway จะไม่อยู่ในสภาวะปกติ หาก Gateway ไม่สามารถ ตอบคำขอสถานะหรือสุขภาพได้ ล็อกภายในเครื่อง, รูปแบบ config และ bundle เสถียรภาพล่าสุดจะยังถูกรวบรวมเมื่อมี

โมเดลความเป็นส่วนตัว

การวินิจฉัยถูกออกแบบมาให้แชร์ได้ export จะเก็บข้อมูลปฏิบัติการ ที่ช่วยในการดีบัก เช่น:

• ชื่อ subsystem, plugin id, provider id, channel id และโหมดที่กำหนดค่าไว้
• status code, ระยะเวลา, จำนวน byte, สถานะ queue และค่าหน่วยความจำ
• metadata ล็อกที่ผ่านการทำให้ปลอดภัยแล้วและข้อความปฏิบัติการที่ถูกแก้ไขข้อมูลแล้ว
• รูปแบบ config และการตั้งค่าฟีเจอร์ที่ไม่ใช่ความลับ

export จะละเว้นหรือแก้ไขข้อมูล:

• ข้อความแชท, พรอมป์, คำสั่ง, webhook body และผลลัพธ์เครื่องมือ
• ข้อมูลรับรอง, API key, token, cookie และค่าความลับ
• request body หรือ response body ดิบ
• account id, message id, session id ดิบ, hostname และ username ภายในเครื่อง

เมื่อข้อความล็อกดูเหมือนข้อความผู้ใช้ แชท พรอมป์ หรือ payload ของเครื่องมือ export จะเก็บไว้เพียงว่ามีข้อความถูกละเว้นและจำนวน byte

ตัวบันทึกเสถียรภาพ

Gateway บันทึกสตรีมเสถียรภาพแบบมีขอบเขตและไม่มี payload เป็นค่าเริ่มต้นเมื่อ เปิดใช้งานการวินิจฉัย สตรีมนี้มีไว้สำหรับข้อเท็จจริงด้านปฏิบัติการ ไม่ใช่เนื้อหา

Heartbeat การวินิจฉัยเดียวกันจะบันทึกตัวอย่าง liveness เมื่อ Gateway ยังทำงานต่อ แต่ event loop ของ Node.js หรือ CPU ดูอิ่มตัว เหตุการณ์ diagnostic.liveness.warning เหล่านี้ประกอบด้วย event-loop delay, event-loop utilization, CPU-core ratio, จำนวน session ที่ active/waiting/queued, phase startup/runtime ปัจจุบันเมื่อทราบ, ช่วง phase ล่าสุด และป้ายกำกับงาน active/queued แบบมีขอบเขต ตัวอย่าง idle จะอยู่ใน telemetry ที่ระดับ info ตัวอย่าง liveness จะกลายเป็นคำเตือนของ Gateway เฉพาะเมื่อมีงาน waiting หรือ queued หรือเมื่อ active work ซ้อนทับกับ event-loop delay ที่ต่อเนื่อง spike ของ max-delay ชั่วคราวระหว่างงานพื้นหลังที่ยังปกติจะอยู่ใน debug log และจะไม่ restart Gateway ด้วยตัวเอง

phase การเริ่มต้นจะ emit เหตุการณ์ diagnostic.phase.completed พร้อม timing แบบ wall-clock และ CPU การวินิจฉัย embedded-run ที่ค้างจะตั้ง terminalProgressStale=true เมื่อความคืบหน้า bridge ล่าสุดดูเหมือนเป็น terminal เช่น raw response item หรือ เหตุการณ์ response completion แต่ Gateway ยังถือว่า embedded run นั้น active อยู่

ตรวจสอบตัวบันทึกสด:

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

ตรวจสอบ bundle เสถียรภาพที่คงอยู่ล่าสุดหลัง fatal exit, shutdown timeout หรือความล้มเหลวในการเริ่มต้นหลัง restart:

openclaw gateway stability --bundle latest

สร้าง zip การวินิจฉัยจาก bundle ที่คงอยู่ล่าสุด:

openclaw gateway stability --bundle latest --export

bundle ที่คงอยู่จะอยู่ใต้ ~/.openclaw/logs/stability/ เมื่อมีเหตุการณ์

ตัวเลือกที่มีประโยชน์

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

• --output <path>: เขียนไปยังพาธ zip ที่ระบุ
• --log-lines <count>: จำนวนบรรทัดล็อกที่ผ่านการทำให้ปลอดภัยแล้วสูงสุดที่จะรวม
• --log-bytes <bytes>: จำนวน byte ของล็อกสูงสุดที่จะตรวจสอบ
• --url <url>: URL WebSocket ของ Gateway สำหรับ snapshot สถานะและสุขภาพ
• --token <token>: token ของ Gateway สำหรับ snapshot สถานะและสุขภาพ
• --password <password>: รหัสผ่านของ Gateway สำหรับ snapshot สถานะและสุขภาพ
• --timeout <ms>: timeout สำหรับ snapshot สถานะและสุขภาพ
• --no-stability-bundle: ข้ามการค้นหา bundle เสถียรภาพที่คงอยู่
• --json: พิมพ์ metadata ของ export ที่เครื่องอ่านได้

ปิดใช้งานการวินิจฉัย

การวินิจฉัยเปิดใช้งานเป็นค่าเริ่มต้น หากต้องการปิดใช้งานตัวบันทึกเสถียรภาพและ การรวบรวมเหตุการณ์การวินิจฉัย:

{  diagnostics: {    enabled: false,  },}

การปิดใช้งานการวินิจฉัยจะลดรายละเอียดของรายงานบั๊ก แต่ไม่ส่งผลต่อ การล็อก Gateway ตามปกติ

ที่เกี่ยวข้อง

• การตรวจสอบสุขภาพ
• Gateway CLI
• โปรโตคอล Gateway
• การล็อก
• OpenTelemetry export — ขั้นตอนแยกสำหรับสตรีมการวินิจฉัยไปยัง collector