---
title: "รัน ติดตาม และชำระค่าแอปด้วย erpc worker"
description: "ดูว่าแอปทำงานอยู่หรือไม่และมีค่าใช้จ่ายรายชั่วโมงเท่าใด rollback release วัดเวลาแฝงของ RPC จากเซิร์ฟเวอร์ สำรองข้อมูล state และยุติการเรียกเก็บเงินรายชั่วโมง"
canonical: "https://erpc.global/th/doc/erpc-cli/worker-status-and-billing/"
locale: "th"
---

# รัน ติดตาม และชำระค่าแอปด้วย erpc worker

`erpc worker status` แสดงว่าแอปของคุณทำงานอยู่หรือไม่ และมีค่าใช้จ่ายรายชั่วโมงเท่าใด การเริ่มทุกครั้งจะแสดงราคาก่อน และ `erpc worker delete --release-server` จะยุติ gRPC, Shreds และ Unlimited RPC ที่แอปใช้แบบรายชั่วโมง แล้วจึงยุติเซิร์ฟเวอร์รายชั่วโมงของแอป

หน้านี้อธิบาย ERPC CLI `v0.1.0-rc.4` ซึ่งเป็นเวอร์ชัน pre-release

## ตรวจสอบแอป

```text
$ erpc worker status --env prod
api-prod on 203.0.113.10: running, release 20261101T093000Z-1a2b3c4d, pid 4217, up 2h 14m
  current 20261101T093000Z-1a2b3c4d, previous 20261028T171500Z-9f8e7d6c, 2 releases kept
  WAF: listening on port 8080, forwarding to 127.0.0.1:3000, since 2026-11-01T09:30:12Z; requests 5120, forwarded 5043, blocked 71, connections refused 12, app errors 6, addresses banned now 1
  `erpc worker delete --release-server --env prod` ends what this app is charged for.
```

`status` แสดงว่าแอปถูกล็อกหรือทำงานอยู่ เป็น release ใด และตั้งแต่เมื่อใด เมื่อคุณลงชื่อเข้าใช้อยู่ คำสั่งนี้ยังแสดงค่าใช้จ่ายรายชั่วโมงของสภาพแวดล้อมนั้น โดยแต่ละรายการแสดงราคาที่บัญชีของคุณถูกเรียกเก็บ และแสดง credit ของบัญชีคุณพร้อมระยะเวลาที่ credit จะใช้ได้ `--json` มีข้อมูลเดียวกันภายใต้ `hourly.charged`

รายการที่ไม่อยู่ในสิ่งที่บัญชีถูกเรียกเก็บเงิน จะถูกระบุว่าไม่อยู่ในนั้น และไม่ถูกเรียกว่ายุติแล้ว เพราะรายการเรียกเก็บนั้นอาจตามหลังการเริ่มได้หนึ่งนาที หากไม่มีเซสชัน หรือเมื่ออ่านรายการเรียกเก็บของบัญชีไม่ได้ `status` จะแสดงสิ่งที่อยู่ในบันทึก

## ควบคุมแอป

| คำสั่ง | สิ่งที่ทำ |
| --- | --- |
| `erpc worker logs -n 200`, `logs -f` | log ของแอปและของเอเจนต์ อักขระควบคุมในบรรทัดจะแสดงเป็น `?` |
| `erpc worker start` | รันแอป โดยส่งคีย์ไปด้วยเมื่อ worker ถูกล็อกอยู่ |
| `erpc worker stop`, `stop --lock` | หยุดแอป และ `--lock` จะลบคีย์ออกจากหน่วยความจำด้วย |
| `erpc worker restart` | หยุดแล้วเริ่มแอปอีกครั้ง |
| `erpc worker releases` | release ที่เก็บไว้บนเซิร์ฟเวอร์ (`deploy.keep_releases`) |
| `erpc worker rollback`, `rollback --to <release>` | rollback กลับไปยัง release ก่อนหน้า หรือ release ที่ระบุ คำสั่งนี้จะถูกปฏิเสธโดยคง release ที่ใช้อยู่ไว้ตามเดิม เมื่อพอร์ต health check ของ release นั้นตอนนี้เป็นของ worker อื่นที่กำลังทำงานอยู่ |
| `erpc worker api <PATH>` | อ่าน API ของแอปจากเครื่องนี้ โดยที่ API ยังคงอยู่บน loopback ของเซิร์ฟเวอร์ (`-X POST`, `-d '{...}'` สำหรับการเปลี่ยนแปลง) |
| `erpc worker trades [--profit]` | การเทรดของแอปบนเซิร์ฟเวอร์ของแอป |
| `erpc worker list` | แอปบนเครื่องนี้และตำแหน่งที่แต่ละแอปถูก deploy ส่วน `--prune` จะนำแอปที่ `erpc.toml` หายไปแล้วออกจากรายการ |

`API_TOKEN` ของแอปถูกอ่านที่นี่ และส่งถึงเซิร์ฟเวอร์ผ่าน standard input โดยไม่อยู่ในบรรทัดคำสั่งใด และไม่อยู่ใน journal ใด คำสั่ง worker ทุกคำสั่งรับ `--env <name>` (ค่าเริ่มต้น `default`) และ `--json` ยกเว้น `secret unlock` และ `secret lock` ซึ่งเกี่ยวกับ keystore ของเครื่องนี้ ไม่ใช่แอป จึงไม่รับ `--env` ไม่ว่าจะรันจากที่ใด คำสั่งจะหาแอปจากชื่อที่ erpc รู้จักแอปนั้น ส่วน `secret put`, `secret rm`, `key import`, `firewall allow` และ `firewall deny` ระบุแอปด้วย `--dir` เท่านั้น

## การเรียกเก็บเงินรายชั่วโมงทำงานอย่างไร

- **การเริ่มทุกครั้งจะแสดงราคาก่อน** ในเทอร์มินัล การเริ่มจะเกิดขึ้นหลังจากตอบ yes เท่านั้น ส่วนเมื่อใช้ `--yes` บรรทัดคำสั่งที่ระบุสิ่งที่จะเริ่มถือเป็นการตอบ yes
- **บริการรายชั่วโมงชำระจาก ERPC Credit** ซึ่งซื้อไว้ล่วงหน้า และการเริ่มที่ credit ไม่พอครอบคลุมจะถูกปฏิเสธ ดูราคาได้ที่ [ราคา](https://erpc.global/th/price/) และ [ERPC Web Dashboard](https://dashboard.erpc.global/th)
- **VPS ใหม่จะอยู่ในบันทึกทันทีที่ได้รับชื่อ** ก่อนที่จะพร้อมใช้งาน การ deploy ครั้งถัดไปจะรับ VPS นั้นมาใช้แทนการซื้อเครื่องใหม่
- **สำหรับ `deploy` การเริ่มที่ไม่ได้รับคำตอบจะถูกส่งซ้ำ และไม่ถูกส่งเป็นการเริ่มใหม่เลย** request key ของการเริ่มนั้นจะอยู่ในบันทึก (`[env.<name>.starting]`) การรันคำสั่งเดิมอีกครั้งจึงส่งคำขอเดิม หลังได้รับคำตอบบางแบบ request key จะคงอยู่จนกว่าคุณจะลบด้วยตนเอง ([การซื้อที่ erpc บันทึกไว้ไม่ได้](https://erpc.global/th/doc/erpc-cli/worker-troubleshooting/#การซื้อที่-erpc-บันทึกไว้ไม่ได้)) `erpc worker run` ไม่เก็บบันทึก การรันครั้งถัดไปจึงสร้างคำขอใหม่
- **โปรด deploy ทีละสภาพแวดล้อม** การ deploy สภาพแวดล้อมเดียวกันสองครั้งที่เริ่มพร้อมกันอาจซื้อเป็นสองรายการ และไม่รองรับกรณีนี้
- **สายข้อมูลยังคงอยู่หรือไม่ ตัดสินจากสิ่งที่บัญชีถูกเรียกเก็บเงิน** erpc จะไม่ยุติสายข้อมูลที่ไม่ได้เรียกเก็บเงินรายชั่วโมงเลย โปรดยุติสายข้อมูลนั้นในแดชบอร์ด

## ลบแอป

`erpc worker delete` จะลบ worker ส่วน `erpc worker delete --release-server` จะยุติสายข้อมูลของ worker ด้วย แล้วจึงยุติเซิร์ฟเวอร์รายชั่วโมง สิ่งที่ยุติไม่ได้จะยังคงอยู่ในบันทึก และสายข้อมูลที่ไม่ได้เรียกเก็บเงินรายชั่วโมงจะถูกระบุชื่อไว้ เพื่อให้คุณยุติในแดชบอร์ด

- การ delete แบบธรรมดาจะปฏิเสธ VPS ที่ซื้อแล้วแต่ไม่เคยเชื่อมต่อถึงได้ เพราะจะทำให้ลืม VPS นั้นไปทั้งที่ยังถูกเรียกเก็บเงินอยู่ ส่วนการ delete แบบธรรมดาของ VPS รายชั่วโมงที่เชื่อมต่อถึงแล้ว จะนำ VPS นั้นออกจากบันทึกทั้งที่ยังถูกเรียกเก็บเงินอยู่ และจะเตือนเรื่องนี้
- `--forget` จะปล่อยเซิร์ฟเวอร์ที่เชื่อมต่อถึงไม่ได้อีกต่อไปไว้โดยไม่เชื่อมต่อถึง และ `--forget-line <id>` จะนำสายข้อมูลที่ถูกยุตินอก erpc ออกจากบันทึก

## วัดเวลาแฝงของ RPC จากเซิร์ฟเวอร์

`erpc worker bench` จับเวลาการเรียก RPC จากเซิร์ฟเวอร์ของสภาพแวดล้อม โดยเทียบ shared RPC ของ ERPC, Unlimited RPC ของ ERPC และ RPC อื่นใดก็ได้แบบเคียงข้างกัน เอเจนต์บนเซิร์ฟเวอร์เป็นผู้จับเวลาการเรียกแต่ละครั้ง ตัวเลขจึงเป็นสิ่งที่แอปได้รับ

```bash
erpc worker bench                                  # getSlot: shared RPC vs the Unlimited RPC
erpc worker bench --rounds 300 --interval 150      # for a plan that limits calls per second
erpc worker bench --url other=op://<vault-id>/<item-id>/url   # another provider's RPC
```

- `--method` รับ `getSlot`, `getBlockHeight`, `getLatestBlockhash` หรือ `getHealth`
- `--no-shared` จะไม่รวม shared RPC ค่าของ `--url` อาจเป็น URL โดยตรง การอ้างอิงแบบ `op://…`, `keychain:…` หรือ `keystore:…` (ชี้ไปยังตำแหน่งที่เก็บ URL ที่มีคีย์อยู่ข้างใน แต่ไม่ชี้ไปยังรายการของคีย์เทรดเด็ดขาด ซึ่งจะถูกปฏิเสธ) หรือ `-` (อ่านจาก standard input หรือถามให้พิมพ์แบบไม่แสดงบนจอ) การระบุ endpoint มากกว่าหกรายการจะถูกปฏิเสธ
- bench จะแสดง p50, p90, p99, min และ max จำนวนครั้งที่ล้มเหลวพร้อมสาเหตุแรก และจำนวน slot ที่แต่ละคำตอบตามหลังคำตอบที่ใหม่ที่สุดในรอบเดียวกัน
- คีย์ส่งถึงเซิร์ฟเวอร์ผ่าน standard input เท่านั้น และตารางจะแสดง scheme, โฮสต์ และพอร์ต

## สำรองข้อมูล state ของแอป

`erpc worker backup on` จะสำรองข้อมูล state ของแอปทุกวันไปยัง ERPC Global Storage โดยเข้ารหัสด้วย restic ที่เวลา `--at` ตามเวลาของเซิร์ฟเวอร์ และภายใน 30 นาทีหลังจากนั้น ต้องมีแพ็กเกจพื้นที่จัดเก็บ (`erpc storage buy 5`)

- **สิ่งที่ถูกสำรองข้อมูล** คือ state ของแอป `/var/lib/private/erpc-worker-<id>` ส่วน release ไม่ถูกสำรองข้อมูล เพราะการ deploy จะนำกลับมาให้ ข้อมูลของ Redis และ PostgreSQL ไม่ได้รวมอยู่ด้วย
- **เซิร์ฟเวอร์ลบ snapshot ไม่ได้** เซิร์ฟเวอร์ไม่ถือเซสชันของ erpc, admin key ของบัญชี หรือรหัสผ่านหลักของบัญชีไว้เลย
- **เซิร์ฟเวอร์ที่ถูกยึดการควบคุมสามารถ**อ่าน snapshot ของทุกเครื่องในบัญชีได้ รวมถึงของเครื่องนี้ เก็บคีย์ของ repository ซึ่ง restic ไม่เปลี่ยนเลย ไว้ได้หลัง `off` เพิ่ม snapshot ภายใต้ชื่อของเครื่องอื่นได้ (หลังเกิดเหตุเช่นนั้น โปรดตรวจสอบว่า `restore latest` เลือก snapshot ใด) และใช้พื้นที่จัดเก็บของบัญชีจนเต็มได้ ซึ่งจะทำให้การสำรองข้อมูลของทุกเครื่องหยุดลง `erpc worker backup off` จะเพิกถอน access key ของเซิร์ฟเวอร์ก่อน ไม่ว่าเซิร์ฟเวอร์จะตอบหรือไม่
- **restic คัดลอกไฟล์ตามสภาพที่เป็นอยู่**ขณะที่ worker ทำงาน ฐานข้อมูลจึงอาจต้องมี dump ของตัวเองเพื่อให้เรียกคืนได้อย่างสอดคล้องกัน การรันที่พลาดไประหว่างที่เซิร์ฟเวอร์ปิดอยู่จะรันเมื่อเซิร์ฟเวอร์กลับมา
- `erpc worker backup off`, `status` และ `now` ใช้หยุด รายงาน และรันการสำรองข้อมูล snapshot จะยังคงอยู่หลัง `off` และ `erpc backup prune --host` จะลดจำนวน snapshot เก่าลง

เรียกคืนจากเครื่องนี้ หลังจากรัน `erpc backup init` บนเครื่องนี้แล้ว:

```bash
erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored
```

## หลายสภาพแวดล้อมและหลายเครื่อง

- worker หลายตัวบนเซิร์ฟเวอร์เดียวกันจะรันเป็น unit ของตัวเองแยกกัน ใช้ตารางไฟร์วอลล์ของเซิร์ฟเวอร์ร่วมกัน และแต่ละตัวเปิดเฉพาะพอร์ตของตัวเอง
- แอปหนึ่งแอปมีได้หลายสภาพแวดล้อม (`[env.staging]`, `[env.prod]`) แต่ละสภาพแวดล้อมมีเซิร์ฟเวอร์และสายข้อมูลของตัวเอง
- สภาพแวดล้อมสามารถเก็บข้อมูลของเซิร์ฟเวอร์ไว้ใน 1Password แทน `erpc.toml` ได้ ในกรณีนั้น เครื่องใดก็ตามที่ลงชื่อเข้าใช้ vault นั้นและมี repository ของแอป จะรันได้ทุกคำสั่ง ส่วนการอ้างอิง `keychain:` และ `keystore:` ในแอปเช่นนี้จะถูกเตือน เพราะเครื่องอื่นอ่านไม่ได้ สภาพแวดล้อมใหม่จะเก็บข้อมูลไว้ใน 1Password เมื่อ `erpc login` เก็บเซสชันไว้ที่นั่น `deploy --vault <vault-id>` ใช้ระบุ vault อื่น และ `deploy --inline` จะเก็บข้อมูลไว้ใน `erpc.toml`