- Witr (why-is-this-running) เป็นเครื่องมือที่แสดงอย่างชัดเจนว่า เหตุใดโปรเซส บริการ หรือพอร์ตใดพอร์ตหนึ่งจึงกำลังทำงานอยู่ บนระบบ Linux
- แตกต่างจาก
ps, top, lsof แบบเดิมที่เพียงแค่แสดงว่า “มีอะไรที่กำลังทำงานอยู่บ้าง” โดย จะแสดงความสัมพันธ์เชิงเหตุและผลของคำถามว่า “ทำไมจึงกำลังทำงานอยู่” ในหน้าจอเดียว
- ผ่าน การวิเคราะห์แบบอิง PID เพื่อติดตามที่มา เส้นทางการรัน สาเหตุที่ยังคงทำงานอยู่ และบริบทที่เกี่ยวข้องของโปรเซส
- อธิบายสาเหตุการรันโดยเชื่อมโยงกับแหล่งที่มาต่าง ๆ เช่น systemd, docker, pm2, cron, shell และทำงานแบบ อ่านอย่างเดียวและไม่ทำลายระบบ
- เป็นเครื่องมือที่ช่วย ลดเวลาในการทำความเข้าใจ ระหว่างการดีบักและรับมือเหตุขัดข้อง พร้อมทำให้มองเห็นโครงสร้างการทำงานของระบบที่ซับซ้อนได้ในภาพเดียว
วัตถุประสงค์และแนวคิด
- คำถามหลักของ Witr คือ “ทำไมสิ่งนี้ถึงกำลังทำงานอยู่? (why-is-this-running)”
- ติดตาม ที่มาและสาเหตุ ของทุกสิ่งที่กำลังทำงานอยู่ ไม่ว่าจะเป็นโปรเซส บริการ หรือพอร์ต
- แสดง สาเหตุทางอ้อมของการรัน ที่พาดผ่านหลายชั้นอย่างชัดเจน เช่น supervisor, container, service, shell
- ในขณะที่เครื่องมือแบบเดิมให้เพียงสถานะและเมทาดาทา Witr แสดงความสัมพันธ์เชิงเหตุและผลได้อย่างชัดเจน
- ผลลัพธ์คือสามารถแสดง “อะไร ทำงานอย่างไร ทำไมจึงทำงาน และทำงานอยู่ในบริบทใด” ในรูปแบบที่ มนุษย์อ่านเข้าใจได้ง่าย
เป้าหมายหลัก
- อธิบาย เหตุผลของการมีอยู่ของโปรเซส และให้ข้อมูลที่มากกว่าแค่ว่ากำลังทำงานอยู่หรือไม่
- ลดเวลาในการดีบักและรับมือเหตุขัดข้อง
- ใช้งานได้ทันทีโดยไม่ต้องตั้งค่า, อ่านอย่างเดียวและปลอดภัย
- ให้ความสำคัญกับ ความชัดเจนมากกว่าความครบถ้วนสมบูรณ์
- ไม่รวมความสามารถด้าน monitoring, การวิเคราะห์ประสิทธิภาพ, หรือการกู้คืนอัตโนมัติ
หลักการทำงาน
- ตีความทุกเป้าหมายโดยยึด โปรเซส (PID) เป็นศูนย์กลาง
- พอร์ต บริการ คอนเทนเนอร์ และคำสั่งทั้งหมดเชื่อมโยงกลับมาที่ PID
- สร้าง ห่วงโซ่เหตุและผลของการรัน (causal chain) โดยอ้างอิงจาก PID
- คำถามหลัก 4 ข้อ
- อะไรกำลังทำงานอยู่
- มันถูกเริ่มต้นขึ้นอย่างไร
- อะไรเป็นตัวคอยทำให้มันยังคงทำงานอยู่
- มันอยู่ในบริบทใด
สิ่งที่รองรับ
- รองรับการป้อน ชื่อโปรเซส/บริการ, PID, และ หมายเลขพอร์ต เป็นเป้าหมาย
- หากป้อนชื่อแล้วตรงกับหลายโปรเซส ระบบจะให้เลือก PID
- สามารถวิเคราะห์โดยอิงโปรเซสหรือพอร์ตเฉพาะได้ด้วยตัวเลือก
--pid, --port
โครงสร้างผลลัพธ์
- Target: เป้าหมายที่ผู้ใช้ระบุ
- Process: ไฟล์ปฏิบัติการ, PID, ผู้ใช้, คำสั่ง, เวลาเริ่มต้น, จำนวนครั้งที่รีสตาร์ต
- Why It Exists: ลำดับเชื้อสายเชิงเหตุและผล (ancestry chain) ของโปรเซส
- Source: ระบบหลักที่รับผิดชอบการรัน (เช่น systemd, docker, pm2, cron, shell อย่างใดอย่างหนึ่ง)
- Context: ไดเรกทอรีทำงาน, Git repository, Docker container, ข้อมูล bind เป็นต้น
- Warnings: คำเตือนแบบไม่บล็อก เช่น การรันด้วยสิทธิ์ root, การ listen บน public interface, การรันเป็นเวลานาน, การใช้หน่วยความจำมากเกินไป
ตัวเลือกบรรทัดคำสั่ง
--pid, --port: วิเคราะห์ PID หรือพอร์ตที่ระบุ--short: สรุปแบบหนึ่งบรรทัด--tree: แสดง tree ของโปรเซสทั้งหมด--json: แสดงผลในรูปแบบ JSON--warnings: แสดงเฉพาะคำเตือน--no-color: ปิดการใช้สี--env: แสดงเฉพาะตัวแปรสภาพแวดล้อม--help: แสดงวิธีใช้
การติดตั้งและการลบ
- แจกจ่ายในรูปแบบ Linux binary แบบ static ไฟล์เดียว
- ติดตั้งด้วยสคริปต์ (แนะนำ)
- ติดตั้งด้วยตนเอง
- ดาวน์โหลด binary สำหรับ
amd64, arm64 โดยตรงและตรวจสอบ checksum
- ให้สิทธิ์รันแล้วนำไปไว้ใน PATH
- การตรวจสอบและการลบ
- ตรวจสอบได้ด้วย
witr --version, man witr
- ลบได้ด้วย
sudo rm -f /usr/local/bin/witr
- รองรับ Nix Flake: สามารถรันได้ด้วย
nix run github:pranshuparmar/witr -- --port 5000
แพลตฟอร์มและสิทธิ์
- สำหรับ Linux เท่านั้น
- เก็บข้อมูลผ่านการเข้าถึง
/proc
- การดูข้อมูลของบางโปรเซสอาจต้องใช้ สิทธิ์ sudo
1 ความคิดเห็น
ความเห็นจาก Hacker News
มีคนเสนอว่า GIF แบบวนลูป ใน README รีสตาร์ตเร็วเกินไป ทำให้อ่านผลลัพธ์ทั้งหมดได้ยาก
ถ้าหยุดค้างไว้อีกสักสองสามวินาทีก็น่าจะดี
แค่ดูเฟรมสุดท้ายก็สื่อข้อมูลที่ต้องการได้ครบแล้ว
ตอนนี้เปลี่ยนเป็น ภาพนิ่ง แล้ว และขอบคุณสำหรับทุกข้อเสนอแนะ
มันช่วยให้เห็นว่าคำสั่งทำงานเร็ว แต่ทุกอย่างก็อยู่ในเฟรมสุดท้ายอยู่แล้ว และยัง สิ้นเปลืองแบนด์วิดท์ ด้วย
ให้หน้าจอผลลัพธ์ค้างอยู่ที่ 100% ก็พอ ทุกคนรู้อยู่แล้วว่าการพิมพ์ในเทอร์มินัลหน้าตาเป็นอย่างไร
เครื่องมือนี้ไม่ได้มีไว้เพื่อ แทนที่เครื่องมือ monitoring/observability ที่มีอยู่แล้ว
จุดประสงค์คือช่วยให้ตอน SSH เข้าเครื่องแล้วตอบคำถามว่า “ทำไมตัวนี้ถึงกำลังรันอยู่?” ได้อย่างรวดเร็ว
และก็พร้อมจะปรับทิศทางตามฟีดแบ็ก
เวลาที่โปรเซสบางตัวเริ่มใช้ทรัพยากรเยอะขึ้น การหาว่ามันมีไว้ทำอะไรเป็นเรื่องยากเสมอ
ตอนแรกฉันนึกว่าเครื่องมือนี้จะอธิบายหน้าที่ของโปรเซสได้ด้วย แต่ก็ไม่ใช่
ถึงอย่างนั้นก็ยังเป็นเครื่องมือที่ยอดเยี่ยม ต่อไปอาจขยายให้รวม man page + ฐานข้อมูลโปรเซส เข้าไว้ด้วยกันได้
ดูมีประโยชน์ แต่ตอนนี้ผลลัพธ์ส่วนใหญ่แสดงแค่ ppid เลยทำให้รู้ว่า “ใครเป็นคนรัน” มากกว่า “ทำไมถึงถูกรัน”
การรองรับหลายรูปแบบผลลัพธ์เป็นเรื่องดี ถ้าคิดถึงงานอัตโนมัติ การตั้ง JSON หรือฟอร์แมตที่เป็นมิตรกับ grep เป็นค่าเริ่มต้นน่าจะดีกว่า
ผลลัพธ์ปกติออกแบบมาให้อ่านง่ายสำหรับมนุษย์ แต่ก็รองรับงานอัตโนมัติผ่าน JSON flag อยู่แล้ว
จะลองคิดเรื่องรูปแบบที่ grep ได้ง่ายขึ้นด้วย
เป็นเครื่องมือที่น่าสนใจ แต่ฉันไม่ค่อยอยาก ติดตั้งไบนารีผ่าน
curlภายหลังอาจมีปัญหาอย่าง “อันนี้ติดตั้งมายังไงนะ?” หรือ “security patch อัปเดตล่าสุดหรือยัง?”
ถ้ามี แพ็กเกจ deb หรือ snap ก็น่าจะดี
curlไม่เหมาะกับทุกคนนี่เป็นรีลีสแรกเลยเริ่มแบบเรียบง่ายก่อน แต่ถ้ามีคนใช้มากขึ้นก็วางแผนจะทำ การแจกจ่ายแพ็กเกจอย่างเป็นทางการ
wdtci: “what does this curl install?”systemctl status $pidก็ให้ข้อมูลได้เยอะเหมือนกันประโยคที่ว่า “witr ตั้งอยู่บนพื้นฐานของความเชื่อใจ” กับคำอธิบายว่า “พัฒนาด้วยความช่วยเหลือจาก AI/LLM” ให้ความรู้สึก ขัดแย้งกัน
ถ้ามีการตรวจผลลัพธ์จาก LLM และทำ code review อย่างเหมาะสม ก็น่าจะเชื่อถือได้
ถึงอย่างนั้นก็ชอบที่เปิดเผยการใช้ LLM อย่าง โปร่งใส
การตัดสินใจจริงยังเป็นของมนุษย์
ถ้าพัฒนาโดยยึดผลลัพธ์เป็นหลักก็ถือว่าโอเค
เป็นเครื่องมือที่เจ๋งและมีประโยชน์มากจริง ๆ
แต่ใน สภาพแวดล้อม production คงยังใช้ได้ยากทันทีด้วยเหตุผลที่พูดไว้ข้างต้น
ถ้ามี แพ็กเกจ Debian หรือ RPM ก็น่าจะดี
ถ้าจะ build จากซอร์สโดยตรง ให้ใช้คำสั่งต่อไปนี้
ส่วนตัวแล้ว ถ้ามี
install.shก็มักจะคาดหวังว่า จะติดตั้งจากซอร์สในเครื่องก่อนนี่แหละเหตุผลที่ทำให้เครื่องมือเล็ก ๆ แบบนี้ยังอยู่ในเทอร์มินัลต่อไป
สงสัยว่า “Git repository name and branch” หมายถึงอะไร
เป็นฟีเจอร์ที่ตรวจว่าโปรเซสที่กำลังรันอยู่ ถูกรันจากภายใน Git repository หรือไม่ ใช่ไหม?
.gitลิงก์โค้ดที่เกี่ยวข้อง
ไอเดียเจ๋งมาก เมื่อก่อนฉันเคยทำ alias ชื่อ “whodis” ไว้ใช้หา PID ที่เปิดพอร์ตอยู่ แต่นี่ทรงพลังกว่าเยอะ
เป็นเครื่องมือที่น่าทึ่งมาก ขอบคุณที่แชร์
ถ้าฉันจะทำ แพ็กเกจ AUR ขึ้นมาจะโอเคไหม?
ข้อดีของ Arch คือเครื่องมือที่น่าสนใจแบบนี้มัก ขึ้น AUR ได้เร็วมาก