Gateway
การส่งออกข้อมูลวินิจฉัย
OmeniaClaw สามารถสร้าง zip การวินิจฉัยภายในเครื่องสำหรับรายงานบั๊กได้ โดยรวม สถานะ Gateway, สุขภาพ, ล็อก, รูปแบบ config และเหตุการณ์เสถียรภาพล่าสุด ที่ไม่มี payload ซึ่งผ่านการทำให้ปลอดภัยแล้ว
ปฏิบัติกับชุดการวินิจฉัยเหมือนเป็นความลับจนกว่าคุณจะตรวจสอบแล้ว ชุดเหล่านี้ ออกแบบมาให้ละเว้นหรือแก้ไข payload และข้อมูลรับรอง แต่ยังคงสรุป ล็อก Gateway ภายในเครื่องและสถานะ runtime ระดับโฮสต์
เริ่มต้นอย่างรวดเร็ว
OmeniaClaw gateway diagnostics exportคำสั่งจะแสดงพาธ zip ที่เขียนไว้ หากต้องการเลือกพาธ:
OmeniaClaw gateway diagnostics export --output OmeniaClaw-diagnostics.zipสำหรับระบบอัตโนมัติ:
OmeniaClaw gateway diagnostics export --jsonคำสั่งแชท
เจ้าของสามารถใช้ /diagnostics [note] ในแชทเพื่อขอ export Gateway ภายในเครื่องได้
ใช้สิ่งนี้เมื่อบั๊กเกิดขึ้นในการสนทนาจริงและคุณต้องการรายงานสำหรับฝ่ายสนับสนุน
ที่คัดลอกและวางได้หนึ่งชุด:
- ส่ง
/diagnosticsในการสนทนาที่คุณพบปัญหา เพิ่มหมายเหตุสั้นๆ ถ้าช่วยได้ เช่น/diagnostics bad tool choice - OmeniaClaw จะส่งคำนำการวินิจฉัยและขออนุมัติ exec แบบชัดเจนหนึ่งครั้ง
การอนุมัติจะเรียกใช้
OmeniaClaw gateway diagnostics export --jsonอย่าอนุมัติการวินิจฉัยผ่านกฎที่อนุญาตทั้งหมด - หลังอนุมัติ OmeniaClaw จะตอบกลับด้วยรายงานที่วางได้ ซึ่งประกอบด้วยพาธ bundle ภายในเครื่อง สรุป manifest, หมายเหตุความเป็นส่วนตัว และ session id ที่เกี่ยวข้อง
ในแชทกลุ่ม เจ้าของยังคงเรียกใช้ /diagnostics ได้ แต่ OmeniaClaw จะไม่
โพสต์รายละเอียดการวินิจฉัยกลับเข้าไปในแชทร่วม โดยจะส่งคำนำ
พรอมป์อนุมัติ ผลลัพธ์ export ของ Gateway และรายละเอียด session/thread ของ Codex
ให้เจ้าของผ่านเส้นทางอนุมัติส่วนตัว กลุ่มจะได้รับเพียงประกาศสั้นๆ
ว่าขั้นตอนการวินิจฉัยถูกส่งเป็นส่วนตัวแล้ว หาก OmeniaClaw ไม่พบเส้นทางส่วนตัว
ไปยังเจ้าของ คำสั่งจะล้มเหลวแบบปิดและขอให้เจ้าของเรียกใช้จากข้อความส่วนตัว
เมื่อ session ของ OmeniaClaw ที่ใช้งานอยู่ใช้ native OpenAI Codex harness การอนุมัติ exec เดียวกันจะครอบคลุมการอัปโหลด feedback ไปยัง OpenAI สำหรับ thread runtime ของ Codex ที่ OmeniaClaw รู้จักด้วย การอัปโหลดนั้นแยกจาก zip Gateway ภายในเครื่อง และจะปรากฏเฉพาะสำหรับ session ของ Codex harness ก่อนอนุมัติ พรอมป์จะอธิบายว่าการอนุมัติการวินิจฉัยจะส่ง feedback ของ Codex ด้วย แต่ จะไม่แสดง session id หรือ thread id ของ Codex หลังอนุมัติ การตอบกลับในแชทจะแสดง ช่องทาง, session id ของ OmeniaClaw, thread id ของ Codex และคำสั่ง resume ภายในเครื่อง สำหรับ thread ที่ถูกส่งไปยังเซิร์ฟเวอร์ของ OpenAI หากคุณปฏิเสธหรือไม่ตอบสนองต่อ การอนุมัติ OmeniaClaw จะไม่เรียกใช้ 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 อยู่
ตรวจสอบตัวบันทึกสด:
OmeniaClaw gateway stabilityOmeniaClaw gateway stability --type payload.largeOmeniaClaw gateway stability --jsonตรวจสอบ bundle เสถียรภาพที่คงอยู่ล่าสุดหลัง fatal exit, shutdown timeout หรือความล้มเหลวในการเริ่มต้นหลัง restart:
OmeniaClaw gateway stability --bundle latestสร้าง zip การวินิจฉัยจาก bundle ที่คงอยู่ล่าสุด:
OmeniaClaw gateway stability --bundle latest --exportbundle ที่คงอยู่จะอยู่ใต้ ~/.OmeniaClaw/logs/stability/ เมื่อมีเหตุการณ์
ตัวเลือกที่มีประโยชน์
OmeniaClaw gateway diagnostics export \ --output OmeniaClaw-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