มาลองเรียน Observability in Action: Beta รุ่น 1 @SCK Dojo

สำหรับ Course นี้ ถือว่าเป็นความโชคดีของผมครับ บังเอิญเห็น Feed พอดีครับ(พี่มาร์คช่วงนี้ปิดกั้นบ่อย) เลยได้บริจาคช่วยน้ำท่วม + ส่งข้อมูลเข้าเรียนไปครับ และได้เข้าไปเรียนช่วง 26-27 OCT 2024 ครับ

งานอะไรที่เราต้องมีการ "เตือนก่อนวายวอด"

จริงๆชอบคำของ Safe T Cut ผมเลยเอามาใส่ด้วย หลักๆ งานที่มันผิดปกติไปจากงานประจำ (น้อยไป หรือ มากเกินไป) เพราะการล่าช้าที่เกิดขึ้น มันส่งผลกับรายได้ และ อาจจะต้องทำตามข้อกฏหมายมาเกี่ยวข้องด้วย เช่น

• งาน Process Order ที่มีเงื่อนไขทั้งจำนวนที่ตั้ง / ราคาแต่ละ Zone / การเกลี่ยสินค้าในแต่ละร้าน (ควรให้ร้านที่มีโอกาสขายสูงกว่าก่อน ไม่งั้น Stock จม) และอื่นๆ ปกติมันต้องเสร็จตอนตี 3
• จากนั้นคลังจะเอาข้อมูลตรงนี้ ไปให้ทีมหน้างานจัดเตรียม และกระจายของตั้งแต่ตี 4 ถ้างานไม่เสร็จ แต่คนมารอจัดของต่อแล้ว เกิด OT ต้องจ่ายไปด้วย

มีคลิปมาพอดี ลองดูประกอบได้เลย

Monitor คือ อะไร ?

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

• Analyzing Long -Term Trends
• Comparing overtime or experimental group ถ้ามีตัว peak จากปกติ
• Alerting - เตือน
• Building Dashboard - ดูภาพรวม ถ้าจุด A พัง แล้วจะส่งผลอะไรต่อ
• Conduct Ad Hoc Action (debugging) - ไฟไหม้แล้วว

key แยก Symptoms vs causes ให้ออก เพราะ มันมีสถานการณ์หลัก และรองลงมา เช่น
- Symptoms user บอกว่าช้า / บางคนบอกหน้าขาว > ระบบบอกว่า 500
- Causes - คอขวด DB Connection Pool เต็ม

- Black Box / White Box Monitoring

ถ้าเราต้องมาติดตาม เราต้องดูอะไรบ้าง จริงๆต้องดูหมด แต่ต้องเลือกวิธีการให้เหมาะกันมัน โดยที่

• Black Box มองจากข้างนอก เช่น 3rd party จุดที่เราไม่ได้สนใจมาก
• White Box ต้องมีภาพ architecture ก่อนนะ เราจะได้รู้ว่าใส่ตรงไหนได้

- ถ้าต้องดูระบบ หรือ microservice อันนึงเราต้องสนใจอะไรบ้าง

มาที่ App บ้าง เราสนใจอะไรกัน ตอน Discuss ให้ห้องจะได้ 4 กลุ่ม

• Resource: memory / disk / CPU / network > initial / load ปกติ / จะล้น ปกติพวกนี้ทำ Availability Plan กำหนด Cap
• Error: log เช่น httpcode 5xx / 4xx
• Duration: Response Time / Throughput / Latency
• Request Rate: พวก Transaction / Request เมื่อเทียบกะปกติ

โดยปกติจะมีหลายค่ายที่เค้านิยมกัน (เวลาไปหา Dashboard ของ Tools จะสะดวกด้วย ตามนี้)

• 4 Golden Signals (SRE Google)
  - Latency
  - Traffic (พวก Request/Sec)
  - Error
  - Saturation (Resource ของระบบ)
• Use Method
  - utilization (ปกติเป็นไง)
  - Saturation
  - Error
• Red Metric(ไปทาง App)
  - Request Rate
  - Error Rate
  - Duration

พอเราเห็นข้อมูลมากขึ้น อาจจะมีคำถามเพิ่ม หรือเลือกจะ Drill Down ลงไป หลังจากรู้เรื่อง Log แล้ว

Observability คือ อะไร ?

ทำไมถึงมีคำว่า Observability มันมาจากมีคำถาม ดังนี้

• ถ้ามันพังขึ้นมาแล้ว พังจากไหน จำกัด Scope ได้ไหม
• ระบบมันใหญ่ และมียุบหยิบเต็มไป แล้วนิยามของ Healthy มันนับจากไหน ?
• งานจากเดิมมันตรงไป ตรงมา ถามตอบ Sync Ack แต่ตอนนี้งานมัน Distribute ถ้าเกิดปัญหาเราจะไล่ได้ยังไง ?
• มันจะได้รู้ว่า ระบบมี partial failure มีทางเลือกให้ไปต่อได้ไหม

มันควรคิดตั้งแต่ตอน Design นะ อีก Shift-Left ให้รู้ปัญหาตั้งแต่ตอนออกแบบ รู้เลยว่ามันมีโอกาสเกิดปัญหา จริงๆมันไม่เชิง Design มันน่าจะเป็นการตั้งคำถามไปให้เกิดเอ๊ะ Requirement เพิ่ม ทั้ง Technical / Business

จาก Diagram เราจะรู้ความตอบนึงแล้วว่า Monitoring มันเป็นส่วนนึงของ Observability นะ แต่อีกด้านนอกจากตามเมื่อเกิดปัญหาเรา เรายังสามารถทดสอบ Testing เพื่อให้รู้ว่าระบบเรามันจะตุยในลักษณะไหนได้บ้าง โดยมันมีชื่อเรียก Chaos Testing ลองทำให้บาง Component/ Service พังดู แล้วระบบตอบสนองอย่างไร

แต่การที่เรารู้พฤติกรรมระบบได้นั้น การทำงานแบบเดิม เขียน Log กำหนด Start / End แล้วทำ Centralize Log อาจจะไม่เพียงพอ หรือ มันเยอะไป จนแบบว่าไปงมๆ หายาก เลยมีกำหนดข้อมูลรูปแบบตอนนี้มี 3 แบบ

• Log - ตัวเดิม ท่าเดิมที่เราทำ เป็นข้อมูล Detail สุดๆ เอาไว้หา cause ในแต่ละจุด
• Trace - ข้อมูลการไหลของ request หรือ การ call ในแต่ละ method (จากที่ลองเอง มันขึ้นกับภาษา และ Lib นะ)
• Metric - ข้อมูลสรุป จะได้ไม่ต้องเข้าไปหาใน Log เพิ่ม เช่น
  - Resource อย่าง CPU / Memory
  - App อย่าง Request Per Sec / Error Count (พวก 5xx / 4xx) ถ้า 401/403 บ่อยๆ อาจจกำลังโดนเจาะได้
  หรือ แม้แต่โจทย์ของ Business เช่น ยอดการสั่งรายวัน มันทำได้นะ แต่ต้อง Inject เข้ามาตั้งแต่ช่วง Requirement / Design เลย

ตัว Observability มันจะเป็นข้อมูลที่เอามาช่วยตอบคำถามที่เกริ่นๆไว้ข้างต้น โดยทั้ง Log/Trace/Metric จะถูกเรียกรวมว่า Telemetry คำนี้มีที่มามาจากโรงไฟฟ้าทอยากรู้ metric ต่างของแต่ละโรง ให้ส่งเข้ามาที่ส่วนกลางผ่านสายโทรศัพท์ (Telephone line)

- Observability Stack

• มันมีหลายส่วนฝั่ง App / Workload
• agent มองว่าเป็น Lib ที่ช่วยเอาค่า Telemetry ออกมา
• จากนั้นส่งไปปลายทาง โดย
  - ส่งตรงเข้า DB สำหรับ Telemetry นั้นๆเลย
  - หรือ จะเข้าตัว Collector มาทำหน้าแปลง ตัด Data Pipeline และส่งเข้า DB ปลายทาง
• ส่วน Visualize แสดงผล

สำหรับใน Class นี้ใช้ตัว LGTM Stack

• Logs - ใช้ Loki สำหรับทำ log aggregation + เก็บข้อมูล
• Grafana dashboard - สำหรับแสดงผลสวยๆ
• Tracing - ใช้ Tempo สำหรับ tracing aggregation + เก็บข้อมูล
• Metrics - Mimir สำหรับการจัดเก็บข้อมูล Metric
• OpenTelemetry - Collector ตัวกลาง (Collector) สำหรับรับ และส่งต่อข้อมูลให้ Loki/Tempo/Mimir ฝั่ง App เองไม่ต้องไปรู้จักเยอะด้วย

ตอน LGTM Stack + OpenTelemetry - Collector มามัดรวมเป็น Container Image เดียวเลย เหมาะสำหรับใช้ช่วง Develop ตัวนี้ >> GitHub - grafana/docker-otel-lgtm

ถ้าเป็นเมื่อก่อน ผมต้องทำ Compose ใช้เอง จริงๆก็โมจากของชาวบ้านแหละ 55 อันนี้ GitHub - pingkunga/dotnet23observability

อ๋อ ถ้าทำ Grafana HA ต้องทำ DB แยกนะ //จดไว้ก่อน เผื่อได้ใช้

- Open Telemetry

เมื่อก่อนหลายๆเจ้ามีทำพวกนี้แยกนะเองนะ เวลาทำตัว Distribute System ลำบากหน่อย แต่ตอนนี้มีมาตรฐานการ Open Telemetry มีทั้งฝั่ง Dev และ Ops เลย

และฝั่ง Dev ถ้าอยากรู้ Sample App มันมีให้เล่นด้วยนะ OpenTelemetry Demo Architecture​ ตอนแรกเข้ามาปีที่แล้วไม่มี T__T

- Share Telemetry

มี 2 แบบ push / pull

• push ให้ app ส่งเข้าไป
• หรือ pull ให้ app เปิด endpoint ไว้ แล้วให้แต่ละ tools อย่าง Prometheus วิ่งเข้ามาดึงเอง

- Sample Telemetry

สำหรับที่เรียนจะเป็นตัวอย่างของ Spring Boot App และใช่ครับ ใช้ Lib ตัวไหน เราเอา Lib หรือ ภาษานั้นไปหา Dashboard ที่คู่กับครับ อย่างของ Spring เป็นตัว Spring Boot 3.x Statistics

แต่มีบางตัวอย่าง เช่น go เค้าไม่ได้เอา Dashboard มาแชร์ ต้องไปดูใน Git ตาม Style ของ Go-Gin gin-metrics: gin metrics for prometheus. เอา Dashboard จาก https://github.com/penglongli/gin-metrics/tree/master/grafana ก่อน import มาแก้ DataSource ใน json ให้เรียบร้อยก่อนนะ

อ๋อ ถ้าเป็น dotnet ผมใช้ตัวนี้ ASP.NET OTEL Metrics

- Exemplars

ก่อนที่เราจะรู้ว่า Exemplars มาดูกันก่อนว่า Log / Trace /Metric มันรู้ได้อย่างไร ว่ามันเกี่ยวข้องกัน โดยที่ตัว

• Log กับ Trace มันจะมี Correlation Id หรือ Trace Id มาเชื่อมว่าข้อมูลในช่วงเวลานั้นๆ ระหว่าง Trace กับ Log มีอะไรที่เกี่ยวข้องกันบ้าง
• ส่วน Metric มันอาจะจ Link Trace Id เป๊ะๆ เพราะมันเป็นค่าๆนึงตาม Sampling มาแปะ ข้อมูลเลยอาจจะไม่ล้อกัน

ตัว Grafana เอาข้อมูลส่วนนี้มาแสดงผล และเชื่อมโยงกันให้ เราสามารถกด Click จาก Trace > Log หรือ กลับกันก็ได้นะ แต่มี Issue แต่ละ Lib ตัว Key/Label อาจจะไม่เหมือนกัน TraceId / Trace_id

Exemplars ข้อมูล Telemetry ตัวไหนที่ค่ามันโดดๆ มันจะขึ้น Data Point นั้นมาให้เรา Drill Down ไปต่อได้นั่นเองครับ

ถ้าอยาก Link ข้อมูลกัน ต้องมากำหนดค่าที่ Data Source ก่อน

1. Data Source > Exemplars กด Add

2. มาเลือก Internal Link และกำหนดข้อมูลที่เชื่อมกัน ตัว Key/Label อาจจะไม่เหมือนกัน TraceId / Trace_id ที่นี้เวลาดูใน Dashboard มันจะมีปุ่มให้ Link ไป

Ref: https://grafana.com/docs/grafana/latest/fundamentals/exemplars/

Key Takeaways

มีหลายส่วน แต่จดมาครบไหม สรุปจาก Lab ที่ได้ลองมาครับ

• แต่ละภาษาเอง อาจจะต้องรอตัว Lib OpenTelemetry Implement ขึ้นมาครับ อย่างพวกภาษาที่มี บ ดังๆหนุนอย่าง Spring (Java) / dotnet ตัว Log / Trace / Metric มีครบแล้ว
  แต่บางภาษาอย่าง Go / Typescript / JavaScript ยังไม่ครบ ณ เวลานี้
• รวมถึงการ Config บางภาษายัดมาให้ แต่บางภาษาให้เขียนลงไปเอง อย่าง Go อาจจะมองว่าไป Auto หมด อาจจะกิน Memory เลยไม่ Auto ใส่ให้แต่แรก
  แต่ถ้าลง Detail ระดับ Method ผมเข้าใจว่าต้องเขียนเองนะ ไม่งั้น Trace บวมแน่ๆ
• นอกจาก Log ที่ต้องตกลงมาตรฐานกันได้ หรือ ไปทำตัวแปลงที่ Collector ตัว Metric เอง มีปัญหาเรื่องการกำหนดชื่อเหมือนกัน ทำให้ค่าเดียวกัน ที่มาจากคนละภาษา / framework มันเอาเข้าไปแสดงที่ Dashboard ไม่ได้ ต้องมาปรับแต่ง ตอนนี้กำลังตกลง Semantic Name กันอยู่

• พวก Metric จะมีปัญหา Correlation ระหว่าง Log / Trace เพราะ Metric มัน เป็นสรุปของเลขชุดนึง แต่ Log / Trace มัน Per Call / Request ดังนั้น ตอนนี้มันเลยเป็นการ Sampling มาแปะ ข้อมูลเลยอาจจะไม่ล้อกัน
• ดู พวก Performance ใช้ Percentile ดีกว่า Average (จริงๆน่าจะพวก metric อื่นๆด้วยนะ เอาไป Apply ได้นะ)
  - Percentile สนว่าการแจกแจง (Distribution) ของข้อมูล
  - ถ้าเอา mean หรือ Average มาใช้ มันจะพวกดึง ถ้าดึงขึ้นมันจะกลายเป็นว่าเราไม่เห็นปัญหา
• Average ไม่เหมาะ มันมีเคสแบบพวกดึง mean
• เวลาทำงานจริงใช้ทั้ง หลายมุม
  - Central Dashboard เห็นทุก Service (Request/Sec, Latency)
  - Focus Dashboard เอาไว้ Drill Down ลงไป เพราะ แต่ละภาษา / กลุ่มทาง Business ของมัน ของมัน
  ภาษา spring / dotnet / express
  กลุ่มทาง Business เช่น billing / order
  Note: พวก Dashboard ต้องมาปรับตาม metric ของแต่ละภาษา
• Trace มันเยอะมาก ดังนั้นเราจะไม่เก็บ 100% จะทำ sampling เอา จะเก็บไว้กี่ % อาจจะ 20% ถ้าจะเอาหมดก็ได้ แต่รอบการ Retention จะถี่ขึ้น เพราะมันแพง ยิ่งระบบมันใหญ่ จาก Tracing เล็กๆ จะเป็น Distribute Tracing หายากกว่าเดิม ถ้าไม่ได้ Design กันไว้ก่อน
• Sampling ที่ไหนดี
  ยกตัวอย่าง เช่น Client ตัว App มันใช้ CPU เยอะ และถ้ามีหลาย Service มันจะรู้ได้ไงว่า A / B Sampling ที่ Link กัน Collector แต่จะเอาที่ไหน
  - tail_sampling ถ้าตายจาก head จะหลุดไป
  - head_sampling ถ้าไม่ไปไม่ถึง อาจจะหายไปเลย ยังไม่ดีที่สุด อาจจะเริ่มจาก tail แล้วมาดู จากนั้น ค่อยเอาส่วนหัวมาเติม
• Observability มันทำได้ทุกที่ ตั้งแต่ Dev / Test / Prod พวก Infra / Config เราเตรียม Declarative ไว้ ทำให้แต่ละ env มัน Consistency กัน จะได้เห็นปัญหาตั้งแต่ตอนแรกๆด้วย
• นอกจาก App เราแล้วมีตัวอีนด้วยนะ ที่เราต้องทำ Observability เช่น DB / Queue / Reverse Proxy (nginx / traffic) เป็นต้น
• การทำ Observability หรือ Montioring แบบเดิม การแก้ปัญหา อาจจะไม่ต้องมาทำ Workflow ใหม่ เขียน Code เพิ่มก็ได้นะ เห็นปัญหาแล้ว เช่น Business บอก ช่วงวันเลขคู่ มีจัดโปรโมชันในบางกลุ่ม รู้อยู่แล้วว่ามี Request ในหมวดนั้นๆเยอะ เราสามารถทำ pre-process แทนก็ได้
• Retention กำหนดเสมอ มอง 2 level
  - Detail พวก Log / Trace เช่น 180 วันตาม พรบ คอม
  - Long Term (Metric) - ในงาน warehouse (sum up) เผื่อมีถามในอนาคต เช่น อาจจะโดนถามปีที่แล้ว
  สุดท้ายต้องตกลงกับทาง Business ว่าจะดูย้อนไปกี่ปี
• อ๋อมีเพื่อนใน Course แนะนำหนังสือด้วย เอามาแปะไว้ Amazon.com: Cloud-Native Observability with OpenTelemetry: Learn to gain visibility into systems by combining tracing, metrics, and logging with OpenTelemetry: 9781801077705: Boten, Alex: Books
• Miro: OBSERVABILITY-IN-ACTION-OCT-2024 - Miro

Observability - ทำให้เรามี data มาตามหาสาเหตุ ถ้ามันมีอะไรที่ต่างไปจากปกติ และแก้ปัญหาได้เร็ว หรือรู้ก่อน แล้วปรับตัวทัน