APPLICATION PERFORMANCE MONITORING

Application ช้า
เห็นชัดว่าช้าตรงไหน

จากหน้า Checkout ที่รอนาน ไปจนถึง API ที่สะดุด เชื่อม Transaction, SQL, External Service และ Code ให้ทีมเห็นหลักฐานเดียวกัน แล้วเลือกแก้จุดที่กระทบผู้ใช้จริง

ปรึกษาทีม APM →ลองวิเคราะห์อาการช้า

Distributed tracingSQL insightsContinuous profiling

01 / DISCOVERรู้ว่า Endpoint ไหนกระทบธุรกิจ

02 / DIAGNOSEแยกเวลาของ Code, SQL และ API

03 / VALIDATEวัดผลหลัง Deploy ด้วย Baseline เดิม

INSIDE A REQUEST

ไม่หยุดแค่รู้ว่าช้า
เปิดดูเวลาที่หายไปในแต่ละขั้น

ลองเลือกอาการเพื่อดูตัวอย่างการวิเคราะห์ ตั้งแต่ภาพรวมจนถึง Trace และแนวทางตรวจสอบต่อ

Ruk-Com APM

commerce / production

ข้อมูลจำลอง · ไม่เชื่อมระบบจริง

APPLICATION / CHECKOUT-API · NODE.JS · APP-03

ภาพรวมประสิทธิภาพ

ช่วงตัวอย่าง 15 นาที

p95 response time2.84 s95% ของ Request อยู่ในค่านี้

Throughput428 rpmจำนวน Request ต่อนาที

Error rate0.8 %สัดส่วน Request ที่ผิดพลาด

Apdex0.72เทียบกับเป้าหมายที่กำหนด

Response time / p95 checkout-api

14:00–14:15 · Deploy v2.8.1 เวลา 14:07

Service dependencies

checkout-api

SQLPayment API

ความสัมพันธ์ที่พบจาก Trace

SELECTED TRACE

POST /api/checkout

2,480 ms · trace #a72f

Span / ระยะเวลา

01,240 ms2,480 ms

POST /api/checkout2,480 ms

↳ checkout.handler2,380 ms

↳ SELECT inventory1,820 ms

↳ POST payment /authorize280 ms

Trace นี้ = Request เดียว · Span แม่รวมเวลาของ Span ลูกอยู่แล้ว จึงไม่นำระยะเวลาทุกแถวมาบวกกัน · p95 ด้านบนเป็นค่ารวมของช่วงเวลา

จุดที่ควรตรวจ: SQL ใช้เวลา 73% ของ Request

SELECT inventory ใช้เวลา 1,820 ms เปิด Query Plan ตรวจ Index, จำนวนแถว และ Lock ก่อนเลือกวิธีปรับ SQL

หลักฐานสำหรับตรวจต่อ

ตัวอย่างเพื่ออธิบายการใช้งาน หน้าจอและตัวเลขไม่ได้แสดงผลลัพธ์หรือรับประกันประสิทธิภาพของระบบลูกค้า

FULL APPLICATION VISIBILITY

ครบตั้งแต่ภาพรวม
ถึงรายละเอียดระดับ Code

เลือกมุมมองให้ตรงคำถามของทีม ทั้งงานประจำวัน การวิเคราะห์ Incident และการวัดผลหลังปรับปรุง

Transactions & Apdex

เห็น Endpoint ที่ควรดูแลก่อน

ดู Response Time, Throughput, Error Rate และ Apdex แยกตาม Transaction ใช้ Percentile ประกอบค่าเฉลี่ยเพื่อเห็น Request กลุ่มที่รอนาน

Distributed traces

ไล่ Request ข้าม Service

เปิด Trace เพื่อดู Parent–Child Span และเวลาของแต่ละขั้น เชื่อมบริบทข้าม Service ที่ติดตั้ง Instrumentation และส่ง Trace Context ครบ

Service map

เข้าใจ Dependency ที่กระทบกัน

มองความสัมพันธ์ระหว่าง Service จาก Trace ที่เก็บได้ ใช้ Latency และ Error ช่วยเลือกจุดเจาะลึกโดยไม่ต้องเดาจากชื่อเครื่อง

Database & N+1

ค้นหา SQL ช้าและ Query ที่เรียกซ้ำ

แยกเวลาที่ใช้กับ Database เปิด SQL ที่เชื่อมกับ Trace และค้นหารูปแบบ N+1 ที่เรียก Query ซ้ำตามจำนวนรายการ

External services

รู้ว่าเวลาหายไปกับ API ใด

แยกเวลาของ HTTP Call ไปยัง Payment, ERP หรือ Third-party ตรวจ Endpoint, Status และ Timeout ร่วมกับ Trace ของ Request ต้นทาง

Exceptions & HTTP failures

เปิด Error พร้อมบริบทที่แก้ต่อได้

รวม Exception ตามลักษณะปัญหา ดู Stack Trace, Transaction และ HTTP Failure เพื่อแยกปัญหา Code ออกจากการเรียก Service ที่ล้มเหลว

Continuous profiling

ดูว่า Function ใดใช้ CPU หรือ Memory

ใช้ Profile และ Flamegraph สำรวจ Function ที่ใช้ทรัพยากรมาก เทียบช่วงเวลาและเชื่อมกับอาการช้า โดยตรวจความสามารถของ Runtime ก่อนเปิดใช้

Correlated context

เชื่อม Trace กับเหตุการณ์รอบข้าง

ประกอบการวิเคราะห์ด้วย Logs, Infrastructure Metrics และ Session Trace เมื่อมีการติดตั้งและเชื่อมข้อมูลที่รองรับ ขอบเขตเครื่องมือเสริมกำหนดในข้อเสนอ

Versions & deployments

เทียบอาการก่อนและหลังปล่อย Version

วาง Deployment Marker เทียบ App Version และช่วงเวลา ดูว่า Latency หรือ Error เปลี่ยนหลัง Deploy หรือไม่ แล้วตรวจหลักฐานก่อนสรุปสาเหตุ

Host tracking

หาเครื่องที่มีพฤติกรรมต่างจากกลุ่ม

แยกผลตาม Host เพื่อดูว่าอาการเกิดทั้ง Service หรือเฉพาะเครื่อง เชื่อมกับ Version และ Resource Context ที่มีเพื่อจำกัดขอบเขตการตรวจ

Alerts & escalation

ส่งสัญญาณให้คนที่รับผิดชอบ

กำหนด Threshold หรือ Baseline สำหรับ Anomaly แล้วส่ง Alert ผ่าน Email, Slack, Teams หรือ Webhook ที่ตั้งค่าไว้ พร้อม Suppression ในช่วง Maintenance และขั้นตอน Escalation

Reports & comparisons

ส่งต่อผลที่ทีมใช้ตัดสินใจได้

สรุป Requests, Failures และ Apdex เป็น Report รายวัน รายสัปดาห์ หรือรายเดือน เปรียบเทียบช่วงเวลาให้ทีม Dev กับผู้ดูแลระบบติดตามงานปรับปรุงร่วมกัน

HOW IT CONNECTS

Application ทำงานตามเดิม
APM รับ Telemetry ไปวิเคราะห์

ติดตั้ง Agent หรือ Instrumentation ที่เข้ากับ Runtime เพื่อส่งข้อมูลการทำงานออกไปยังระบบ APM โดยไม่ได้บังคับให้ Request ของผู้ใช้วิ่งผ่าน APM

การเชื่อม Trace ข้าม Service ต้องส่ง Context ต่อกัน ส่วน Endpoint, Sampling และสิทธิ์ข้อมูลวางแผนตามระบบจริง

APPLICATION REQUEST / RESPONSE

User / Client

⇄

ApplicationAPM Agent

⇄

SQL / API

↓Traces · Metrics · Errorsส่ง Telemetry แยกจาก Request

APM Platformวิเคราะห์ · เชื่อมบริบท · แจ้งเตือน

↓ ทีม Dev / Ops ตรวจหลักฐานและวางแผนแก้ไข

YOUR STACK, CONNECTED

เริ่มจากภาษาและ Framework
ที่ทีมคุณใช้อยู่

ตรวจ Runtime, เวอร์ชัน และ Framework ก่อนเลือก Agent พร้อมทดสอบการเก็บข้อมูลในสภาพแวดล้อมที่ควบคุมได้

PHP

Node.js

Java

Python

Ruby

.NET

Auto-instrumentation, Custom Span, Profiling และ Context Correlation รองรับต่างกันตามภาษา เวอร์ชัน และ Library ทีมจะยืนยัน Compatibility รวมถึง Overhead และขั้นตอน Restart ก่อนเปิดใช้งานจริง

ENTERPRISE ONBOARDING

เครื่องมือที่ดี ต้องมาพร้อม
วิธีใช้งานที่ทีมรับต่อได้

Ruk-Com ช่วยวางการเก็บข้อมูลและขั้นตอนตรวจสอบให้เข้ากับการทำงานขององค์กร โดยกำหนดสิทธิ์และผู้รับผิดชอบร่วมกัน

01Scope

กำหนดโจทย์และระบบสำคัญ

ระบุ Transaction ที่กระทบธุรกิจ Runtime, Host, ผู้รับผิดชอบ และช่วงเวลาที่เกิดอาการ

สิ่งส่งมอบตามขอบเขตService inventory + success criteria

02Instrument

ติดตั้งพร้อมกำหนดสิทธิ์ข้อมูล

กำหนด Sampling, Retention และ Masking ของ Header, Query หรือ Payload ที่อาจมีข้อมูลอ่อนไหว ทดสอบก่อนส่งข้อมูลจริง

สิ่งส่งมอบตามขอบเขตInstrumentation + access plan

03Baseline

สร้างภาพอ้างอิงและตรวจ Alert

ตรวจว่า Trace ต่อเนื่อง Metric เชื่อถือได้ และ Alert ถึงทีมที่ถูกต้อง บันทึกภาวะปกติในช่วงโหลดที่เป็นตัวแทน

สิ่งส่งมอบตามขอบเขตBaseline + alert validation

04Handover

ส่งต่อหลักฐานและแนวทางดูแล

สรุปจุดที่ควรตรวจ จัดลำดับงานร่วมกับ Dev และกำหนดวิธีเทียบผลหลังแก้ไข พร้อม Runbook และช่องทางส่งต่อ

สิ่งส่งมอบตามขอบเขตFindings + operational runbook

APM ช่วยให้เห็นหลักฐาน ส่วนการเปลี่ยน Code, Index หรือ Production Configuration ต้องมีเจ้าของงาน การอนุมัติ และการทดสอบตามกระบวนการขององค์กร ขอบเขตทีมดูแลและงานพัฒนาเพิ่มเติมยืนยันในข้อเสนอ

Ruk-Com Agent

ทุกบริการ มี Agent ช่วยดูแล

ดูแลร่วมกับทีมผู้เชี่ยวชาญ ทั้ง Technology และ Cyber Security ตั้งแต่ติดตามระบบ วิเคราะห์ความผิดปกติ ไปจนถึงช่วยวางแผนและประสานการแก้ไข

Technology · ประสิทธิภาพ ความจุ และการทำงานของระบบ

Cyber Security · ความเสี่ยง ช่องโหว่ และการเฝ้าระวังภัย

การเข้าถึงข้อมูล การลงมือแก้ไข และระดับการดูแล เป็นไปตามสิทธิ์และขอบเขตบริการที่ตกลงกับทีม

รู้จัก Ruk-Com Agent

CLEAR PRICE / CLEAR SCOPE

APM สำหรับทีมที่ต้องการ
เข้าใจ Application อย่างจริงจัง

เริ่มจากระบบที่มีผลต่อรายได้หรือการให้บริการ แล้วขยาย Coverage ตามความสำคัญและสิ่งที่เรียนรู้จากข้อมูลจริง

APPLICATION PERFORMANCE MONITORING

฿3,500 / เครื่อง / เดือน

ส่งจำนวนเครื่อง Runtime และอาการที่พบ เพื่อรับข้อเสนอที่ระบุขอบเขตการติดตั้งและการดูแลชัดเจน

ยืนยันก่อนเริ่มบริการ

วิธีนับเครื่องและ Container, ปริมาณข้อมูล, Sampling, Retention, สิทธิ์เข้าถึง, ค่า Setup และภาษี รวมถึงเครื่องมือเชื่อมต่อที่ต้องใช้เพิ่มเติม

ให้ทีมประเมินระบบและราคา →

BEFORE YOU START

คำถามก่อนเชื่อม
ระบบ Production

วางขอบเขตให้ชัด เพื่อได้ข้อมูลที่นำไปใช้ต่อได้อย่างมั่นใจ

APM ต่างจาก Monitoring เครื่องอย่างไร?

CPU หรือ Memory ช่วยบอกสภาพ Resource ส่วน APM เชื่อมอาการเข้ากับ Transaction, SQL, External Call และ Code ทั้งสองมุมมองช่วยกันแยกว่าควรตรวจ Application หรือ Infrastructure ต่อ

มี APM แล้ว Application จะเร็วขึ้นอัตโนมัติไหม?

ไม่ใช่อัตโนมัติ APM ช่วยค้นหาจุดที่ควรตรวจ ทีมต้องวิเคราะห์สาเหตุ เลือกวิธีแก้ ทดสอบ และวัดผลหลัง Deploy โดยใช้ช่วงโหลดและตัวชี้วัดที่เปรียบเทียบกันได้

ข้อมูลสำคัญจะถูกส่งเข้า APM หรือไม่?

ขึ้นกับ Agent และ Configuration จึงต้องทบทวนข้อมูลที่จะเก็บ โดยเฉพาะ Header, Query String, SQL Parameter และ Request Body ตั้ง Masking หรือ Exclusion พร้อมทดสอบ และตกลง Retention กับสิทธิ์ก่อนเชื่อม Production

ระบบ Microservices และ Container ใช้ได้อย่างไร?

ต้องติดตั้ง Instrumentation ใน Service ที่ต้องการและส่ง Trace Context ให้ต่อเนื่อง พร้อมกำหนดชื่อ Service, Environment และ Version ส่วนวิธีคิดจำนวนเครื่องหรือ Container จะยืนยันกับทีมก่อนเสนอราคา

ต้องเตรียมอะไรให้ทีม Ruk-Com?

ส่ง Architecture คร่าว ๆ ภาษาและเวอร์ชัน จำนวนเครื่อง Endpoint ที่ช้า ช่วงเวลาและผลกระทบ พร้อมทีมผู้รับผิดชอบและข้อจำกัดการเข้าถึง เพื่อกำหนดขอบเขตและเกณฑ์วัดผล

LET’S FIND THE SLOW PART

บอกเราว่า Application ช้าตอนไหน
แล้วมาเปิดดูหลักฐานด้วยกัน

เริ่มจาก Endpoint สำคัญหนึ่งจุด และคำถามที่ทีมอยากตอบให้ได้

LINE @rukcom →[email protected]

Application ช้าเห็นชัดว่าช้าตรงไหน

ไม่หยุดแค่รู้ว่าช้าเปิดดูเวลาที่หายไปในแต่ละขั้น