---
read_when:
    - การเปลี่ยนเอาต์พุตหรือรูปแบบการบันทึกล็อก
    - การดีบักเอาต์พุตของ CLI หรือ Gateway
summary: พื้นผิวการบันทึกล็อก, ล็อกไฟล์, รูปแบบล็อก WS และการจัดรูปแบบคอนโซล
title: การบันทึกล็อกของ Gateway
x-i18n:
    generated_at: "2026-06-27T17:35:44Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: dde5e589bb48cd8c41ac6dd0d74780fec1cc1ee79d82d433b4e7c7450dc5c8b6
    source_path: gateway/logging.md
    workflow: 16
---

# การบันทึก log

สำหรับภาพรวมที่ผู้ใช้เห็น (CLI + Control UI + config) โปรดดู [/logging](/th/logging)

OpenClaw มี "พื้นผิว" ของ log สองแบบ:

- **เอาต์พุตคอนโซล** (สิ่งที่คุณเห็นในเทอร์มินัล / Debug UI)
- **log ไฟล์** (บรรทัด JSON) ที่เขียนโดยตัวบันทึก log ของ Gateway

เมื่อเริ่มต้น Gateway จะบันทึก log โมเดล agent เริ่มต้นที่แก้ค่าแล้ว พร้อมกับ
ค่าเริ่มต้นของโหมดที่มีผลต่อเซสชันใหม่ เช่น:

```text
agent model: openai/gpt-5.5 (thinking=medium, fast=on)
```

`thinking` มาจาก agent เริ่มต้น, พารามิเตอร์ของโมเดล, หรือค่าเริ่มต้น agent ส่วนกลาง;
เมื่อไม่ได้ตั้งค่าไว้ สรุปตอนเริ่มต้นจะแสดง `medium` `fast` มาจาก
agent เริ่มต้นหรือพารามิเตอร์ `fastMode` ของโมเดล

## ตัวบันทึก log แบบไฟล์

- ไฟล์ log แบบหมุนเวียนเริ่มต้นอยู่ใต้ `/tmp/openclaw/` (หนึ่งไฟล์ต่อวัน): `openclaw-YYYY-MM-DD.log`
  - วันที่ใช้เขตเวลาท้องถิ่นของโฮสต์ Gateway
- ไฟล์ log ที่ใช้งานอยู่จะหมุนเวียนเมื่อถึง `logging.maxFileBytes` (ค่าเริ่มต้น: 100 MB) โดยเก็บ
  ไฟล์เก็บถาวรแบบมีหมายเลขไว้สูงสุดห้าไฟล์ และเขียนไฟล์ที่ใช้งานอยู่ไฟล์ใหม่ต่อไป
- สามารถกำหนดค่าเส้นทางและระดับของไฟล์ log ผ่าน `~/.openclaw/openclaw.json` ได้:
  - `logging.file`
  - `logging.level`

รูปแบบไฟล์คือหนึ่งออบเจ็กต์ JSON ต่อหนึ่งบรรทัด

เส้นทางโค้ดการสนทนา, เสียงแบบเรียลไทม์, และห้องที่จัดการ ใช้ตัวบันทึก log ไฟล์ร่วมสำหรับ
ระเบียนวงจรชีวิตแบบมีขอบเขต ระเบียนเหล่านี้มีไว้สำหรับการดีบักเชิงปฏิบัติการ
และการส่งออก log ของ OTLP; ข้อความทรานสคริปต์, เพย์โหลดเสียง, turn ids, call ids, และ
provider item ids จะไม่ถูกคัดลอกเข้าไปในระเบียน log

แท็บ Logs ของ Control UI tail ไฟล์นี้ผ่าน Gateway (`logs.tail`)
CLI ทำแบบเดียวกันได้:

```bash
openclaw logs --follow
```

**Verbose เทียบกับระดับ log**

- **log ไฟล์** ถูกควบคุมโดย `logging.level` เท่านั้น
- `--verbose` มีผลต่อ **ความละเอียดของคอนโซล** เท่านั้น (และรูปแบบ log ของ WS); ไม่ได้
  เพิ่มระดับ log ของไฟล์
- หากต้องการเก็บรายละเอียดที่เห็นเฉพาะใน verbose ลงใน log ไฟล์ ให้ตั้ง `logging.level` เป็น `debug` หรือ
  `trace`
- การบันทึก log ระดับ trace ยังรวมสรุปเวลาวินิจฉัยสำหรับ hot paths บางรายการ
  เช่น การเตรียม factory ของเครื่องมือ Plugin ดู
  [/tools/plugin#slow-plugin-tool-setup](/th/tools/plugin#slow-plugin-tool-setup)

## การจับเอาต์พุตคอนโซล

CLI จะจับ `console.log/info/warn/error/debug/trace` และเขียนลงใน log ไฟล์
ขณะที่ยังพิมพ์ไปยัง stdout/stderr อยู่

คุณสามารถปรับความละเอียดของคอนโซลแยกต่างหากได้ผ่าน:

- `logging.consoleLevel` (ค่าเริ่มต้น `info`)
- `logging.consoleStyle` (`pretty` | `compact` | `json`)

## การปกปิดข้อมูล

OpenClaw สามารถปิดบังโทเค็นที่ละเอียดอ่อนก่อนที่เอาต์พุต log หรือทรานสคริปต์จะออกจาก
กระบวนการ นโยบายการปกปิดข้อมูลในการบันทึก log นี้ถูกใช้กับปลายทางข้อความของคอนโซล, log ไฟล์, ระเบียน log ของ OTLP,
และทรานสคริปต์เซสชัน ดังนั้นค่าความลับที่ตรงกันจะถูกปิดบังก่อนที่บรรทัด JSONL หรือข้อความจะถูกเขียนลงดิสก์

- `logging.redactSensitive`: `off` | `tools` (ค่าเริ่มต้น: `tools`)
- `logging.redactPatterns`: อาร์เรย์ของสตริง regex (แทนที่ค่าเริ่มต้น)
  - ใช้สตริง regex ดิบ (เพิ่ม `gi` อัตโนมัติ) หรือ `/pattern/flags` หากคุณต้องการ flags แบบกำหนดเอง
  - รายการที่ตรงกันจะถูกปิดบังโดยคงอักขระ 6 ตัวแรก + 4 ตัวสุดท้ายไว้ (ความยาว >= 18) มิฉะนั้นใช้ `***`
  - ค่าเริ่มต้นครอบคลุมการกำหนดคีย์ทั่วไป, CLI flags, ฟิลด์ JSON, bearer headers, บล็อก PEM, คำนำหน้าโทเค็นยอดนิยม, และชื่อฟิลด์ข้อมูลรับรองการชำระเงิน เช่น หมายเลขบัตร, CVC/CVV, โทเค็นการชำระเงินที่ใช้ร่วมกัน, และข้อมูลรับรองการชำระเงิน

ขอบเขตความปลอดภัยบางส่วนจะปกปิดข้อมูลเสมอไม่ว่า `logging.redactSensitive` จะเป็นค่าใด
ซึ่งรวมถึงเหตุการณ์การเรียกเครื่องมือของ Control UI, เอาต์พุตเครื่องมือ `sessions_history`,
การส่งออกข้อมูลสนับสนุนการวินิจฉัย, ข้อสังเกตข้อผิดพลาดของผู้ให้บริการ, การแสดงคำสั่งอนุมัติ exec,
และ log โปรโตคอล Gateway WebSocket พื้นผิวเหล่านี้อาจยังใช้
`logging.redactPatterns` เป็นรูปแบบเพิ่มเติมได้ แต่ `redactSensitive: "off"`
ไม่ได้ทำให้พื้นผิวเหล่านี้ปล่อยความลับดิบออกมา

## log ของ Gateway WebSocket

Gateway พิมพ์ log โปรโตคอล WebSocket ในสองโหมด:

- **โหมดปกติ (ไม่มี `--verbose`)**: พิมพ์เฉพาะผลลัพธ์ RPC ที่ "น่าสนใจ":
  - ข้อผิดพลาด (`ok=false`)
  - การเรียกที่ช้า (ค่า threshold เริ่มต้น: `>= 50ms`)
  - ข้อผิดพลาดการแยกวิเคราะห์
- **โหมด Verbose (`--verbose`)**: พิมพ์ทราฟฟิกคำขอ/คำตอบ WS ทั้งหมด

### รูปแบบ log ของ WS

`openclaw gateway` รองรับสวิตช์รูปแบบต่อ Gateway:

- `--ws-log auto` (ค่าเริ่มต้น): โหมดปกติได้รับการปรับให้เหมาะสม; โหมด verbose ใช้เอาต์พุตแบบกระชับ
- `--ws-log compact`: เอาต์พุตแบบกระชับ (คำขอ/คำตอบเป็นคู่) เมื่อ verbose
- `--ws-log full`: เอาต์พุตเต็มต่อเฟรมเมื่อ verbose
- `--compact`: นามแฝงของ `--ws-log compact`

ตัวอย่าง:

```bash
# optimized (only errors/slow)
openclaw gateway

# show all WS traffic (paired)
openclaw gateway --verbose --ws-log compact

# show all WS traffic (full meta)
openclaw gateway --verbose --ws-log full
```

## การจัดรูปแบบคอนโซล (การบันทึก log ของระบบย่อย)

ตัวจัดรูปแบบคอนโซล **รับรู้ TTY** และพิมพ์บรรทัดที่สอดคล้องกันพร้อมคำนำหน้า
ตัวบันทึก log ของระบบย่อยจะจัดเอาต์พุตให้เป็นกลุ่มและสแกนได้ง่าย

พฤติกรรม:

- **คำนำหน้าระบบย่อย** ในทุกบรรทัด (เช่น `[gateway]`, `[canvas]`, `[tailscale]`)
- **สีของระบบย่อย** (คงที่ต่อระบบย่อย) พร้อมการลงสีตามระดับ
- **ใช้สีเมื่อเอาต์พุตเป็น TTY หรือสภาพแวดล้อมดูเหมือนเทอร์มินัลแบบ rich** (`TERM`/`COLORTERM`/`TERM_PROGRAM`) และเคารพ `NO_COLOR`
- **คำนำหน้าระบบย่อยแบบย่อ**: ตัด `gateway/` + `channels/` นำหน้าออก, เก็บ 2 เซกเมนต์สุดท้าย (เช่น `whatsapp/outbound`)
- **ตัวบันทึก log ย่อยตามระบบย่อย** (คำนำหน้าอัตโนมัติ + ฟิลด์เชิงโครงสร้าง `{ subsystem }`)
- **`logRaw()`** สำหรับเอาต์พุต QR/UX (ไม่มีคำนำหน้า, ไม่มีการจัดรูปแบบ)
- **รูปแบบคอนโซล** (เช่น `pretty | compact | json`)
- **ระดับ log ของคอนโซล** แยกจากระดับ log ของไฟล์ (ไฟล์คงรายละเอียดเต็มไว้เมื่อ `logging.level` ถูกตั้งเป็น `debug`/`trace`)
- **เนื้อความข้อความ WhatsApp** ถูกบันทึก log ที่ `debug` (ใช้ `--verbose` เพื่อดู)

สิ่งนี้ทำให้ log ไฟล์เดิมคงที่ ขณะที่เอาต์พุตแบบโต้ตอบสแกนได้ง่ายขึ้น

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

- [การบันทึก log](/th/logging)
- [การส่งออก OpenTelemetry](/th/gateway/opentelemetry)
- [การส่งออกการวินิจฉัย](/th/gateway/diagnostics)