Microsoft ปล่อย ETW MCP — ให้ Copilot อ่าน trace ประสิทธิภาพของ Windows ได้เองในเทอร์มินัล ไม่ต้องเปิด WPA

วันที่ 21 กรกฎาคม 2026 ทีม Performance and Diagnostics ของ Microsoft ปล่อย ETW MCP เป็น early preview — เซิร์ฟเวอร์ Model Context Protocol ที่เปิดทางให้ผู้ช่วย AI (GitHub Copilot ใน VS Code, Copilot CLI หรือไคลเอนต์ MCP ตัวไหนก็ได้) เข้าไปอ่านข้อมูลภายในไฟล์ trace .etl ของ Event Tracing for Windows ได้โดยตรง แบบมีโครงสร้างและ อ่านอย่างเดียว

ปัญหาที่มันแก้ตรงประเด็นมาก และคนที่เคย debug ปัญหาประสิทธิภาพบน Windows จะเข้าใจทันที: การอ่าน ETW trace ต้องใช้ Windows Performance Analyzer ซึ่งเป็น GUI ที่มีตารางเป็นสิบ ๆ แบบ และตามที่บล็อกเขียนไว้ตรง ๆ ว่า “ถ้าคุณไม่รู้ว่าตารางไหนใน WPA ตอบคำถามคุณ คุณจะเสียเวลาหนึ่งชั่วโมงไปกับการเรียนเครื่องมือ ก่อนจะได้เรียนรู้อะไรจาก trace ของตัวเอง”

มันเปิดอะไรให้ AI บ้าง

จุดออกแบบที่สำคัญคือ ETW MCP ไม่ได้โยน raw event stream ให้โมเดล (ซึ่งจะระเบิด context ทันที) แต่ห่อเป็น tool ที่นิยามชัดเจน คืนผลลัพธ์แบบมีขอบเขต:

• ประมวลผลและ query trace โดยจำกัดจำนวนผลลัพธ์ที่คืนกลับ
• เทียบหลาย trace พร้อมกัน — baseline เทียบกับ trial ซึ่งเป็นท่ามาตรฐานเวลาไล่หา regression
• วิเคราะห์ระดับสัญลักษณ์ ลงลึกถึงระดับ module!function
• Critical Path Analysis หาเส้นทางที่กำหนดเวลารวมจริง ๆ
• Regions of Interest scoring ให้คะแนนช่วงที่น่าสนใจข้ามหลาย trace

เบื้องหลังใช้เอนจิน TraceProcessor ตัวเดียวกับที่ Microsoft มีเอกสารฝั่ง .NET อยู่แล้ว ไม่ได้เขียน parser ใหม่

ติดตั้งยังไง

ตัวมันส่งมาเป็นแพ็กเกจ NuGet ชื่อ Microsoft.Windows.EventTracing.MCP ต้องมี .NET 10 SDK แล้วเพิ่มบล็อก MCP server เข้าไปในไฟล์ config ของไคลเอนต์ที่ใช้ — รองรับ VS Code, GitHub Copilot CLI และไคลเอนต์ที่พูด MCP ได้ทั่วไป ปัญหาแจ้งได้ที่รีโป microsoft/eventtracing-processing

กลุ่มเป้าหมายที่ Microsoft ระบุไว้: วิศวกรที่ไล่หา regression, คนทำไดรเวอร์และฮาร์ดแวร์ที่ต้อง profile, ทีมที่อยากรัน performance test แบบ batch อัตโนมัติ และ “ใครก็ตามที่ต้องเปิดไฟล์ .etl โดยไม่เคยมีพื้นมาก่อน” — กลุ่มสุดท้ายนี่แหละคือกลุ่มที่ได้ประโยชน์ที่สุด

มุมมอง AI Curator

ผมมองว่านี่เป็นตัวอย่างที่ดีมากของ “MCP server ที่ควรเป็น” และต่างจากกระแส MCP ส่วนใหญ่ที่เห็นกันทุกสัปดาห์อย่างมีนัยสำคัญ

MCP server จำนวนมากที่ปล่อยกันออกมาคือ wrapper บาง ๆ ของ REST API ที่ agent เรียกเองก็ได้อยู่แล้ว คุณค่าเพิ่มน้อย แต่ ETW MCP แก้ปัญหาคนละชั้น — มันเปิดทางเข้าถึง ข้อมูลที่เดิมเข้าถึงได้ผ่าน GUI เท่านั้น และเป็น GUI ที่ความรู้ในการใช้กระจุกอยู่กับผู้เชี่ยวชาญไม่กี่คนในองค์กร นี่คือรูปแบบที่ผมคิดว่าจะเห็นซ้ำอีกเยอะในปีหน้า: เครื่องมือวิเคราะห์เฉพาะทางเก่าแก่ที่มี learning curve ชัน ถูกห่อด้วย MCP แล้วกลายเป็นสิ่งที่ถามด้วยภาษาคนได้

จุดที่ทำถูกอีกอย่างคือ read-only และ bounded results ทีมที่เคยลองต่อ agent เข้ากับฐานข้อมูลจริงจะรู้ว่าสองข้อนี้คือเส้นแบ่งระหว่างเครื่องมือที่ใช้ใน production ได้กับใช้ไม่ได้ ผลลัพธ์ที่ไม่จำกัดขนาดจะกิน context จนโมเดลตอบมั่ว ส่วนสิทธิ์เขียนบนระบบ diagnostics คือความเสี่ยงที่ไม่มีใครอยากรับ

สำหรับบริบทไทย ผมคิดถึงทีมที่ทำ ซอฟต์แวร์เดสก์ท็อปและระบบฝังตัวบน Windows ซึ่งบ้านเรายังมีเยอะกว่าที่คนสาย web คิด — โรงงาน, POS, ระบบธนาคารสาขา, เครื่องมือแพทย์ ทีมเหล่านี้มักไม่มี performance engineer เต็มเวลา และเมื่อระบบช้าลงหลังอัปเดต การหาคนที่อ่าน WPA เป็นคือคอขวดจริง เครื่องมือแบบนี้ไม่ได้แทนผู้เชี่ยวชาญ แต่ย่นเวลาจาก “ไม่รู้จะเริ่มตรงไหน” ไปถึง “มีสมมติฐานให้ตรวจสอบ” ได้จริง

ข้อควรจำ: มันยังเป็น early preview และ Windows-only อย่าเพิ่งวางไว้บนเส้นทางที่ CI ต้องพึ่งพา — ใช้เป็นเครื่องมือช่วยสืบสวนตอนนี้กำลังดี และอย่าลืมว่า trace ประสิทธิภาพมักมีชื่อไฟล์ ชื่อโปรเซส และ path ภายในองค์กรติดอยู่ ก่อนส่งเข้าโมเดลคลาวด์ ควรเช็คนโยบายข้อมูลของบริษัทก่อน

แหล่งข่าว

• Introducing the ETW MCP: AI-assisted ETL trace analysis, headless and in your terminal — Microsoft DevBlogs (21 ก.ค. 2026)
• microsoft/eventtracing-processing — GitHub
• Performance and Diagnostics Blog