How to monitor ระบบง่ายๆ ด้วย Dynatrace dashboard
ในทุกวันนี้ปัญหาที่เกิดขึ้นในระบบ Application จำเป็นต้องจัดการและแก้ไขปัญหาให้รวดเร็วมากที่สุด เพื่อให้เกิดผลกระทบกับผู้ใช้งานและส่งผลกับธุรกิจน้อยที่สุด เพราะฉะนั้นในหลายๆ องค์กรจึงมีการนำ Application Performance Monitoring (APM) Tool มาคอยช่วย monitor performance ในหลายๆ ด้านของระบบพร้อมกัน เพื่อให้เราสามารถรับรู้ปัญหาที่เกิดและ Focus กับปัญหานั้นได้เร็วขึ้น
Dynatrace ก็เป็น APM Tool ยี่ห้อหนึ่งที่มีความสามารถในการ monitor performance ของระบบในหลากหลายด้านได้พร้อมกัน อย่าง Application, Host, Process, Service, Database และ Tool ยังสามารถช่วย Detect ปัญหาที่เกิดขึ้นได้ด้วย🕵️♂️🕵️♀️ ในวันนี้ผมจะมาพูดถึงอีกหนึ่งฟังก์ชันของ Dynatrace นั้นก็คือการทำ Dashboard ว่าใน Dashboard ของเราควรใส่ข้อมูลอะไรลงไปบ้าง เพื่อ monitor ระบบของเรานั่นเอง📈📉📊
Blog นี้จึงมีเป้าหมายเพื่อนำประสบการณ์จากการทำงานของตัวเองออกมาแชร์ให้กับเพื่อนๆ ที่ใช้ Dynatrace หรือ APM อื่นๆ สามารถนำไปประยุกต์กับ dashboard ของตัวเองได้หรือเป็นตัวอย่างในการเริ่มต้น monitor application ของตัวเอง
หากเพื่อนๆ ที่ยังสงสัยหรืออยากได้รายละเอียดเพิ่มเติม ว่า Dynatrace คืออะไร? มีการทำงานยังไง? และสามารถทำอะไรได้บ้าง? สามารถไปอ่านเพิ่มเติมได้จาก Blog “What is dynatrace?”
Dashboard ช่วยในการ monitor ระบบได้อย่างไร?
จากประสบการณ์ที่เคยได้เข้าไปอยู่ใน War room และได้นั่งทำงานกับคนที่ monitor ระบบ ต้องบอกเลยว่าการจัดการกับข้อมูลขนาดใหญ่จากหน้าต่างจำนวนมากๆ ในระหว่างที่เคสตรงหน้ากำลังถาโถมเข้ามาแบบไฟลุกอยู่นั้นไม่ใช่เรื่องง่ายเลยจริงๆ 🤦♀️🤦♂️🔥🔥🔥
มันจะดีกว่ามั้ยถ้าเราสามารถนำข้อมูลรายละเอียดต่างๆ มาสร้างเป็นรายงานภาพรวมของระบบ เพื่อให้เราเห็นปัญหาที่เกิดขึ้นและสามารถวิเคราะห์ข้อมูลต่างๆ ในระยะเวลาอันสั้นได้ง่ายมากยิ่งขึ้น ดังนั้น point ของรายงานหรือ Dashboard ของเราคือ
1. รวบรวมข้อมูลทั้งหมดไว้ใน Dashboard
2. สามารถเห็นภาพรวมแบบ real-time ได้
3. สามารถนำข้อมูลไป Focus ปัญหาได้ถูกส่วน
Dashboard ที่ใช้ Monitor Application ของเราควรมีอะไรบ้าง?
ส่วนใหญ่ Dashboard ที่ใช้ในการ monitor ระบบ Application จะใช้เป็น Operational Dashboard และ Analytical Dashboard มาแสดงเพื่อให้เห็นภาพรวมของระบบและสามารถดู detail เพิ่มเติมได้ด้วย
ซึ่งผมจะขอยกตัวอย่าง dashboard ที่ทำโดยใช้ Dynatrace มาโชว์เพื่อนๆ กันนะครับ ว่าเราใส่ข้อมูลอะไรบน dashboard บ้างและหน้าตาเป็นแบบไหน เรามาเริ่มกันเลยครับ
ส่วนที่ 1: Summary Health
Summary Health ส่วนนี้จะเป็น Report ที่แสดงภาพรวมของระบบ ว่าระบบของเรายัง healthy ดีอยู่หรือไม่ และเพื่อให้เราได้เห็นปัญหาที่เกิดขึ้นที่ส่วนไหนของระบบบ้าง
รูปแบบของกราฟ
ในส่วนนี้ผมใช้กราฟที่สามารถดูภาพรวมของระบบได้ง่าย เช่น กราฟรวงผึ้ง, Total count ของข้อมูล เป็นต้น และสำหรับเนื้อหาของส่วน Summary จะประกอบไปด้วย
- Problems
- Application
- Host
- Service
- Database
- Network
ถ้า Environment ของเรา Healthy ใน Dashboard ก็ควรเป็นสีเขียวทั้งหมดและไม่มี Problems เกิดขึ้นในกราฟของเรา เท่านี้เราก็น่าจะอุ่นใจได้แล้ว👍👍
ส่วนที่ 2: Host
ในพื้นฐานการ monitor resource ของเครื่อง Host ของเราคงหนีไม่พ้น CPU, Memory และ Disk ใช่มั้ยละครับ ก็ตามที่ทุกคนเข้าใจเลยครับ พวก resource พวกนี้เป็นพื้นฐานการทำงานของคอมพิวเตอร์ของเรา เพื่อตัด choice การปัญหา resource ไม่เพียงพอและดูว่า Host ของเรามีการทำงานที่หนักหน่วงแค่ไหน ผมก็แนะนำให้ใส่ไว้ใน Dashboard นะครับ ในส่วน Host บน Dashboard นี้จะประกอบด้วย
- CPU Usage
- Disk Used
- Memory Usage
- Network Interface
และจะขออธิบายเพิ่มเติมในส่วนถัดไปครับ👇👇
2.1 CPU Usage %
เป็นค่าที่บอกการใช้งาน CPU ของคอมพิวเตอร์เรา ว่าใช้งานน้องหนักเกินไปมั้ย ถ้า peak ถึง 100% น้องก็อาจจะทำงานช้าหรือค้างไปเลยก็ได้ครับ😡😡 จากรูปกราฟ CPU ด้านล่าง ผมได้ตั้ง threshold ที่ focus ไปที่ 80% ขึ้นไป เพื่อดูว่าเส้นกราฟ CPU จาก Host ไหนที่ทำงานเกิน 80% บ้าง
รูปแบบของกราฟ
กราฟที่นำมาใช้สำหรับแสดงค่าของ CPU Usage ก็จะเป็น Period time และ Table เพื่อสามารถแสดงจุด peak ในแต่ละช่วงเวลา และ threshold โดยรวมของ Host ได้
Recommendation :
สำหรับค่า CPU ก็แนะนำ Focus ที่ช่วง 80% — 90% ครับ เราก็ควรเฝ้าระวังได้แล้วครับ — Warning=80 or 85%, Critical=90%
2.2 Memory Usage %
โดยปกติโปรแกรมของเราก็ต้องมีการจอง memory เพื่อใช้ในการทำงานอย่างเช่น การประกาศตัวแปร object แต่หากเกิดเหตุการณ์ memory leak ทำให้ใช้ทรัพยากรจนเครื่องเราทำงานช้าหรือค้างได้ จนไปถึงหยุดการทำงานล่ะ🤯😇👻 เพื่อนๆ อาจจะได้เห็นดาวน์ที่ไม่ได้อยู่บนฟ้า แต่อยู่ตรงหน้าเพื่อนๆ แทนครับ🤩🤩 ดังนั้นเราก็ควรจะต้อง monitor memory ไว้เพื่อดูการใช้ memory ในการทำงานเช่นกัน
รูปแบบของกราฟ
กราฟที่นำมาใช้สำหรับแสดงค่าของ Memory Usage จะเป็นแบบเดียวกับของ CPU เลยครับ เพื่อที่จะดูจุด peak และ threshold โดยรวมของแต่ละ host จึงเลือกกราฟแบบ Period time และ table มาครับ
Recommendation :
สำหรับค่า Memory ก็แนะนำ Focus ที่ช่วง 80% — 90% เหมือนกับ CPU เลยครับ — Warning=80 or 85%, Critical=90%แต่สำหรับ memory ก็ควรดูพฤติกรรมของโปรแกรมของเราด้วยเช่นกัน จะมีบางโปรแกรมที่ทำการ Reserved memory ไว้ใช้งานก่อน หากเครื่องใช้ไม่พอค่อยคืนให้เครื่องใช้ อันนั้นก็ต้องปรับ threshold ที่ควร warning เป็น Memory reserved ของโปรแกรม + OS memory used ถ้าไม่ถึง 80% ก็ใช้ threshold ตามที่ recommend ด้านบนได้เลย ☝☝
2.3 Disk
สำหรับ Disk สิ่งที่เราต้อง monitor ที่ทุกคนนึกออกอย่างแรกๆเลยก็คือ Free space ของ Disk ใช่มั้ยละครับ ในส่วน Disk ผมเพิ่มเติมตามรูปให้คือ
- Disk Used % — เพื่อดูว่า Disk ของเรามี Free space เพียงพอกับการทำงานของเราหรือไม่ หรือน้องพร้อมจะเต็มในไม่ช้าครับ Example: จากตัวอย่าง drive D บน LoadGenD1000001 ของเราก็คือน้องกำลังจะตุยแล้วจร้า😨😱
รูปแบบของกราฟ
สำหรับกราฟที่นำมาโชว์ Disk used ของเราก็จะเป็นแบบ Top list เพื่อมาดูว่า drive หรือ path ไหนของเราใช้มากที่สุด แต่ถ้า Disk มีการใช้งานบ่อยๆ ก็อาจจะเพิ่มกราฟแบบ Period time มาเพื่อช่วยดู trend การใช้งานเพิ่มก็ได้นะครับ
Recommendation :
ปกติผมจะใช้เกณฑ์อยู่ที่ 80% จาก Disk space ทั้งหมด — Warning=80, Critical=90%
- Disk Available — ต้องบอกเลยว่าสำหรับการใช้ Disk Used % เพียงอย่างเดียว ก็มีข้อที่ user ต้องมานั่งคิดอีกว่า ถ้า Disk ของฉันมีขนาดใหญ่การคิดเป็น % มันก็อาจจะมากไปหรือเปล่า🤔🤔 เช่น 80% จาก 2 TiB มันก็คือ 1600 GiB เรายังเหลืออีกตั้ง 400 GiB แหน่ะ ฉะนั้นผมแนะนำให้เพิ่ม Disk Available มาไว้ประกอบด้วย
รูปแบบของกราฟ
ข้อมูลของ Disk available แนะนำใส่เป็นแบบ Table เพราะจะได้นำข้อมูลของ disk available แบบที่คิดเป็น % และ size available ของแต่ละ path มาโชว์ได้แบบรูปด้านล่างครับ
Note : ปกติผมจะนำ Disk Available ไป Calculate กับ Growth rate (Availability = Disk Available/Max Growth rate)เพื่อดูว่า Disk จะสามารถอยู่กับเราได้นานเท่าไหร่
- Disk queue length (avg.) — อันนี้เอาไว้บอกว่า Disk ของเราเกิดปัญหาทำงานทันมั้ย หรือกำลังเกิด Bottlenecks อยู่ ซึ่งค่าที่นำมาแสดงจะเป็นค่า average ของ Disk operation ทั้ง read และ write ที่เกิด queue พูดให้เข้าใจง่ายๆ ก็คือ Disk ของเรา read หรือ write ทันหรือไม่ หรือกำลังต่อคิวกันอยู่
รูปแบบของกราฟ
กราฟสำหรับ Disk queue length แนะนำเป็น Top list นะครับ เพื่อเอามาโชว์ Path หรือ Drive ที่มี Disk queue มากที่สุด
Recommendation :
Threshold ที่หลายๆ สำนักแนะนำก็จะเป็นตั้งแต่ queue ของ Disk มากกว่า 2 นะครับ เพื่อนๆ สามารถดูข้อมูลเพิ่มเติมได้
2.4 Network Interface
ในส่วนนี้เราจะเอาไว้เพื่อ monitor Network Interface (NIC) ของเรา ว่ายังมีสุขภาพที่ดีอยู่หรือไม่ และมีการใช้งานที่หนักหรือไม่🕵️♂️🕵️♀️ ไม่รอช้าขอแนะนำ metric ที่นำมาเสนอในกราฟของ NIC กันดังนี้ครับ
- Connectivity & Retransmission
สำหรับ Connectivity โดยปกติทั่วไปแล้วจะอยู่ที่ threshold 100% แต่ถ้าหาก threshold ลดลงต่ำกว่านั้นอาจจะเกิดจาก TCP connection เกิด refused หรือ time out ขึ้นได้ อีกกรณีที่ threshold เป็น 0% แต่ไม่มีการแจ้งเคสเข้ามา เราอาจจะตีความได้ว่าไม่มี connection เข้ามาเลยก็ได้
สำหรับ Retransmission โดยปกติจะเกิดจากการที่ต้องส่ง packets ที่เสียหายหรือสูญหายอีกครั้ง ทาง Dynatrace แนะนำว่าปกติ threshold ไม่ควรถึง 0.5% บน local network และ 2% บน internet network หรือ cloud-based network
รูปแบบของกราฟ
ผมเลือกใช้กราฟแบบ Table มาแสดงค่า Connectivity & Retransmission ของ network แต่ละ NIC มาแสดงให้ดู
- NIC Received & Sent
สำหรับ metric นี้ ผมเอามาเสริมในส่วน network ขาเข้า-ออกของ host ในระบบของเราว่ามากน้อยแค่ไหนครับ
รูปแบบของกราฟ
เลือกกราฟแบบ Period time และ Top list มาดูช่วง spike ของกราฟและ NIC ตัวท็อปๆ ที่มีการ received/sent สูงๆ
ส่วนที่ 3: Service
มาในส่วนที่จะนำมา monitor หลังบ้านหรือ Backend ของเรากันบ้างนะครับ ข้อมูลในส่วนนี้จะนำไปตอบเคสยอดฮิตที่ว่าทำไม app ช้าและทำไม app ใช้งานไม่ได้ หัวข้อที่นำมาแสดงเป็นกราฟก็จะมี 3 เรื่องหลักๆเลยคือ
- Response Time
- Request Count
- Failure Rate
3.1 Response Time ของ Service Request
เพื่อดูว่า request แต่ละ service ของเราใช้เวลาเท่าไหร่ในการทำงานและทำงานช้าหรือไม่
รูปแบบของกราฟ
Recommendation :
ทีนี้ถ้าพูดถึงเรื่องความช้าผมก็ต้องบอกก่อนว่าความช้าของแต่ละคนนั้นไม่เคยเท่ากัน เป็น threshold ที่มาจากความคาดหวังและความรู้สึกจริงๆนะครับ😂🤣 เพราะฉะนั้นเราควรตั้ง Baseline จาก stat ที่เคย test หรือข้อตกลงร่วมกัน เช่น site ตกลงกันว่า app ควรทำงานไม่เกิน 1 sec.สำหรับ Response time แนะนำให้ดูค่า median มากกว่าดูค่า average เพราะหากเราเจอชุดข้อมูลที่ขาดความสมดุลที่มีค่า Min ต่ำมากๆ ก็จะฉุด Avg. ของเราให้มีค่าต่ำลงได้ — Threshold สำหรับ warning และ critical ดูจาก Baseline ตอน test
3.2 Request count ของ Service Request
เพื่อดูว่า service ของเรามีการใช้งานมากน้อยแค่ไหน บางทีถ้าจำนวน request มากเกินกว่าตอน load test ที่เรารับได้😱 ก็อาจจะเป็นสาเหตุหนึ่งในการที่ทำให้ app ช้าได้
รูปแบบของกราฟ
Recommendation :
ค่า threshold สำหรับ monitor Request count แนะนำให้ตั้งตาม Max limit ที่รับได้ตอน load test
3.3 Failure Rate
ถ้าจะดูปัญหาที่เกิดในส่วนหลังบ้านที่ทำให้ app ทำงานไม่ได้ ก็ต้องดูว่าเกิด Fail request เกิดขึ้นมากน้อยแค่ไหน กราฟนี้จะสามารถบอกเราได้ครับ
- Error 4xx and 5xx — กราฟนี้จะเป็นส่วนเสริมจาก Failure rate จากด้านบนนะครับ☝☝ ว่า Fail ที่เกิดขึ้นเป็น HTTP Error 4xx หรือ 5xx กันแน่ (Error 4xx คือ Error ที่เกิดขึ้นจากฝั่ง client, Error 5xx คือ Error ที่เกิดขึ้นจากฝั่ง Server ของเราเอง) เพื่อนำไป investigate case กันต่อได้ ซึ่ง Error 4xx หรือ 5xx มันจะมีแยกย่อยอีกหลายเลขเลยนะครับ เราอาจจะต้องไป drill down ปัญหาอีกที แต่อย่างที่บอกคือ Dashboard เราพยายามที่ point ปัญหาให้คนที่ดูสามารถ focus กับปัญหาได้ง่ายขึ้น
รูปแบบของกราฟ
ผมเลือกใช้กราฟ 2 แบบในการแสดงข้อมูลนั้นคือ Period time และ Table ก็ด้วยเหตุผลเดียวกัน คือเราจะได้เห็นจุด spike และ threshold โดยรวม
Recommendation :
ซึ่งปกติเราก็ต้องตั้ง threshold ไว้ที่ Failure rate 0% อยู่แล้วใช่มั้ยละครับ เพื่อดูว่าเกิดอะไรขึ้นกับหลังบ้านของเราและดูผลกระทบที่เกิดขึ้นด้วย แต่หากเพื่อนๆ รู้ threshold ที่รับได้ว่าไม่เกิดผลกระทบกับ User และระบบแน่นอนก็สามารถปรับเปลี่ยนได้ครับ
ส่วนที่ 4 : Database
ใน Tier สุดท้ายของ Application ก็ต้องเป็น Database ที่คอยเก็บข้อมูลของลูกค้าหรือ user แม้กระทั่งข้อมูลของตัว Application เองด้วย เพราะฉะนั้นหากขาดส่วนนี้ไป Dashboard ของเราจะ monitor ครบ loop ได้ยังไง เรามาดูกันดีกว่าว่าในส่วนของ Database นี้ ต้อง monitor อะไรบ้างในหน้า Dashboard ของเรา หัวข้อที่นำมาแสดงเป็นกราฟก็จะมี 4 เรื่องหลักๆเลยคือ
- Response Time ของ Database Request
- Request Count ของ Database Request
- Failure Rate ของ Database Request
- Failed Connection
4.1 Response Time ของ Database Request
Counter เอามาใช้ monitor ว่า request database ของเราช้าหรือไม่ แต่ถ้าพูดถึงความช้า ก็เหมือนกับของ service เลยคือต้องดูว่าทาง user เจ้าของ app รับได้แต่ไหนและ user คนใช้งานให้ feedback กลับมาอย่างไร
รูปแบบของกราฟ
เลือกใช้กราฟแบบ Period time และ Table เพื่อดูข้อมูลช่วงเวลาที่มีการ spike ของ response time และ Table มาโชว์ทั้งค่า median และ percentile ที่ 90 ของ response time ของ database request
Recommendation :
กลับมาอีกครั้งในเรื่องของความช้า — เร็ว ซึ่งอันนี้เป็นส่วนของ Database request แต่ก็ไม่ต่างกันกับ Service request เลยครับ เราอาจจะต้องสอบถามข้อมูลเพิ่มเติมจาก User ว่าสามารถรับได้ที่ระยะเวลาเท่าไหร่ ประกอบกับผลการทดสอบว่า Request ปกติใช้เวลาเท่าไหร่⏱⏱
4.2 Request Count ของ Database Request
ดูว่า app มีการยิง request มาที่ Database มากน้อยแค่ไหน ซึ่งถ้า Database รับ request มากๆก็อาจจะทำงานไม่ทันได้เช่นกัน
รูปแบบของกราฟ
เลือกใช้กราฟ Period time และ Table สิครับ จะได้เห็นช่วงเวลาที่ spike ของ request count และจำนวนโดยรวมของ request count ใน timeframe นั้น
Recommendation :
ต้องดูความสามารถของ Database ของเราเลยครับ ว่าสามารถรับ request ได้เท่าไหร่ ซึ่งเพื่อนๆ อาจจะทราบได้จากการ Load test และดูผลกระทบที่ User ยอมรับได้มาประกอบครับ
4.3 Database Connection
ส่วนนี้จะ focus ที่ Database ของเรามี connection เข้ามามากน้อยแค่ไหน และเกิด Fail connection ขึ้นกับ Database หรือไม่
รูปแบบของกราฟ
ถ้า request count เลือกใช้กราฟ Period time และ Table ครับ Failed connection ก็เลือกเหมือนกันเลยครับ จะได้เห็นช่วงเวลาที่ spike ของ Failed และจำนวนโดยรวมของ Failed ใน timeframe นั้น
Recommendation :
ปกติของ Dynatrace ก็จะ monitor ที่ threshold Failed connection อยู่ที่ 5 connection แต่ถ้าเกิด Failed connection กับ Database เรามากๆคงไม่ดีแน่ แนะนำให้ตั้ง 1–5 เป็น threshold ที่เฝ้าระวัง และเตรียมตัว investigate บนเครื่องได้ก่อนเลยครับ🏃♂️🏃♀️
4.4 Failure Rate
ก็คล้ายกับ Error ของ Service แต่เรา filter แต่ส่วนของ Database มาโดยเฉพาะ เพื่อให้คน monitor สามารถนำเคสไปส่งต่อผู้เชี่ยวชาญเฉพาะทางได้ง่ายขึ้น เช่น เกิด Error ที่ request Database ก็ส่งให้ทีม DBA ช่วยตรวจสอบต่อ
รูปแบบของกราฟ
กราฟ Failure rate ผมเลือกใช้แบบ Period time และ Table เพราะจะได้เห็นช่วงเวลาที่เกิด spike และ threshold โดยรวมของ timeframe นั้นด้วยครับ
Recommendation :
ก็แนะนำให้ตั้ง threshold ของ Failure rate ของ Database request ที่ 0% จากนั้นก็ค่อยปรับจาก User experience ว่าโดยปกติจะเกิด Failure rate อยู่ที่ประมาณไหนและไม่มีผลกระทบกับการใช้งานของ User
จากตัวอย่าง Dashboard และกราฟ ที่ยกมาหวังว่าจะช่วยให้เพื่อนๆ สามารถเข้าใจและนำ Dynatrace dashboard ไป monitor ระบบของเพื่อนๆ ได้
ซึ่ง metric ที่นำมาแสดงเป็นตัวอย่างให้เพื่อนๆ ดูเป็นเพียงส่วนหนึ่งของ metric ที่ Dynatrace สามารถจับมาแสดงได้ ยังมี metric อีกมากมายให้เพื่อนๆ เลือกใช้งานนะครับ ถ้าเพื่อนๆ สนใจในเรื่องไหนเพิ่มเติมสามารถ recommend ไว้ได้นะครับ ไว้โอกาสหน้าจะมาแบ่งปันความรู้ดีๆ ให้กันใหม่ครับ ขอบคุณครับ🙏🙏🙏
เพื่อนๆสามารถติดตามข่าวสารของพวกเราได้ที่
Facebook: Sirisoft
Instargram: Sirisoft_official
TikTok: Sirisoft
Youtube: Sirisoft Official
ช่องทางสอบถามข้อมูลและสมัครงานได้ที่
Website: Sirisoft
Line official : @sirisoft
ต้องขอขอบคุณข้อมูลอ้างอิงจากแหล่งต่างๆ ดังนี้
- How to Identify IO Bottlenecks in MS SQL Server
https://www.mssqltips.com/sqlservertip/2329/how-to-identify-io-bottlenecks-in-ms-sql-server/ - How to monitor network communications
https://www.dynatrace.com/support/help/shortlink/network-monitoring
