คู่มือตั้งค่า SigNoz Observability บน Service Mesh ขั้นสูง
เมื่อคุณบริหารระบบ Kubernetes ขนาดใหญ่ที่มีหลายบริการทำงานพร้อมกัน ปัญหาที่เกิดขึ้นมักจะซับซ้อนและยากต่อการติดตามเพราะข้อมูลกระจัดกระจายไปทั่วทั้งระบบ SigNoz เป็นเครื่องมือ Observability ที่ช่วยให้คุณเห็นภาพรวมของสิ่งที่เกิดขึ้นในทั้งระบบ รวมถึงการทำงานของแต่ละบริการและความเชื่อมโยงระหว่างกัน
Service Mesh เช่น Istio นั้นเป็นเลเยอร์พิเศษที่จัดการการสื่อสารระหว่างบริการต่างๆ โดยให้ความสามารถในการควบคุมการไหลของข้อมูล ความปลอดภัย และการติดตาม แต่ถ้าไม่มีเครื่องมือสำหรับสังเกตการณ์ คุณจะไม่รู้ว่าเกิดอะไรขึ้นจริงๆ บทความนี้จะแสดงวิธีการตั้งค่า SigNoz เพื่อให้มองเห็นและตรวจสอบ Service Mesh ของคุณได้อย่างชัดเจน
ข้อดีของการรวม SigNoz กับ Service Mesh คือคุณสามารถเห็นการไหลของคำขอทั้งหมด ความเร็วของการตอบสนอง อัตราข้อผิดพลาด และแม้กระทั่งปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นในการสื่อสารระหว่างบริการ
SigNoz คืออะไร และทำไมจึงสำคัญสำหรับ Service Mesh
SigNoz เป็นแพลตฟอร์ม Observability ที่เป็น Open Source ซึ่งหมายความว่าคุณสามารถดาวน์โหลดและใช้งานได้โดยไม่ต้องจ่ายค่าใบอนุญาต มันถูกออกแบบมาเพื่อรวบรวมและวิเคราะห์ข้อมูลสามประเภทหลัก ได้แก่ Metrics (ตัวเลขที่แสดงประสิทธิภาพ) Traces (เส้นทางของคำขอผ่านบริการต่างๆ) และ Logs (บันทึกข้อความของระบบ)
เมื่อคุณใช้ SigNoz กับ Service Mesh คุณจะได้ประโยชน์จากความสามารถในการมองเห็นการทำงานของทั้งระบบ ตั้งแต่ระดับเครือข่ายไปจนถึงระดับแอปพลิเคชัน นี่เป็นสิ่งสำคัญเพราะปัญหาบางอย่างอาจเกิดขึ้นที่จุดเชื่อมต่อระหว่างบริการ ไม่ใช่ในบริการเดียว
ส่วนประกอบหลักของ SigNoz
SigNoz ประกอบด้วยส่วนต่างๆ หลายส่วนที่ทำงานร่วมกัน OTel Collector เป็นตัวรับข้อมูล Telemetry จากแต่ละบริการ ClickHouse เป็นฐานข้อมูลที่เก็บข้อมูลทั้งหมด Query Service เป็นตัวค้นหาข้อมูล และ Dashboard เป็นอินเทอร์เฟซที่แสดงข้อมูลให้คุณมองเห็น
ความเชื่อมโยงระหว่าง SigNoz และ Istio
Istio ทำหน้าที่เป็นตัวจัดการการสื่อสารระหว่างบริการ มันติดตั้ง Proxy เล็กๆ (เรียกว่า Sidecar) ในแต่ละ Pod เพื่อควบคุมการไหลของข้อมูล Proxy เหล่านี้สามารถส่งข้อมูลเกี่ยวกับการสื่อสารไปยัง SigNoz เพื่อให้คุณเห็นว่าเกิดอะไรขึ้น
ขั้นตอนการติดตั้ง SigNoz บน Kubernetes
การติดตั้ง SigNoz บน Kubernetes นั้นค่อนข้างตรงไปตรงมา เราจะใช้ Helm ซึ่งเป็นเครื่องมือที่ช่วยให้การติดตั้งแอปพลิเคชันบน Kubernetes ง่ายขึ้น
ขั้นตอนแรก เพิ่ม Repository ของ SigNoz
ก่อนอื่นคุณต้องบอกให้ Helm รู้ว่าจะหา SigNoz ได้ที่ไหน เปิด Terminal และพิมพ์คำสั่งต่อไปนี้
helm repo add signoz https://charts.signoz.io
helm repo updateคำสั่งแรกเพิ่ม Repository ของ SigNoz คำสั่งที่สองอัปเดตข้อมูลให้เป็นเวอร์ชันล่าสุด
ขั้นตอนที่สอง ติดตั้ง SigNoz
ตอนนี้เราจะติดตั้ง SigNoz ลงในคลัสเตอร์ Kubernetes ของคุณ
helm install signoz signoz/signoz \
--namespace signoz \
--create-namespaceคำสั่งนี้จะสร้าง Namespace ใหม่ชื่อ signoz และติดตั้ง SigNoz ลงไป หลังจากนั้นคุณสามารถตรวจสอบสถานะของการติดตั้งได้ด้วยคำสั่ง kubectl get pods -n signoz
ขั้นตอนที่สาม ติดตั้ง Istio
ต่อไปเราต้องติดตั้ง Istio ซึ่งเป็น Service Mesh ที่จะจัดการการสื่อสารระหว่างบริการ
สรุปแนวคิด: istioctl install --set profile=demo -y kubectl label namespace default istio-injection=enabled
คำสั่งแรกติดตั้ง Istio โดยใช้โปรไฟล์ demo ซึ่งเหมาะสำหรับการทดลอง คำสั่งที่สองบอกให้ Istio ติดตั้ง Sidecar Proxy โดยอัตโนมัติในทุก Pod ใน Namespace default
การตั้งค่า Istio เพื่อส่งข้อมูลไปยัง SigNoz
หลังจากติดตั้ง SigNoz และ Istio แล้ว เราต้องบอกให้ Istio ส่งข้อมูลไปยัง SigNoz เพื่อให้ SigNoz สามารถเห็นและวิเคราะห์ข้อมูลได้
การกำหนดค่า Telemetry
Istio มีฟีเจอร์ Telemetry ที่ช่วยให้คุณตัดสินใจว่าจะส่งข้อมูลอะไรไปยัง SigNoz คุณสามารถกำหนดให้ส่ง Traces ซึ่งแสดงเส้นทางของคำขอผ่านบริการต่างๆ
การตั้งค่าพื้นฐานคือการสร้าง Telemetry Resource ในคลัสเตอร์ของคุณ ซึ่งจะบอกให้ Istio ส่งข้อมูล Traces ไปยัง OTel Collector ของ SigNoz OTel Collector นี้จะรับข้อมูลและส่งต่อไปยัง ClickHouse เพื่อเก็บไว้
การตั้งค่า OpenTelemetry Collector
OpenTelemetry Collector เป็นตัวกลางที่รับข้อมูล Telemetry จากแหล่งต่างๆ และส่งต่อไปยังที่เก็บข้อมูล SigNoz มี OTel Collector ในตัวอยู่แล้ว ซึ่งหมายความว่าคุณไม่ต้องติดตั้งเพิ่มเติม
สิ่งที่คุณต้องทำคือให้แน่ใจว่า Istio ส่งข้อมูลไปยังที่อยู่ที่ถูกต้องของ OTel Collector ซึ่งมักจะเป็นที่อยู่ภายในคลัสเตอร์ Kubernetes
Dashboard และการติดตาม Metrics
เมื่อ SigNoz และ Istio ทำงานร่วมกันแล้ว คุณสามารถเข้าถึง Dashboard ของ SigNoz เพื่อดูข้อมูลต่างๆ Dashboard นี้จะแสดงข้อมูลสำคัญหลายอย่างที่ช่วยให้คุณเข้าใจสถานะของระบบ
ตัวชี้วัดที่สำคัญในการติดตาม
มีตัวชี้วัดหลายตัวที่คุณควรติดตาม เช่น Request Rate ซึ่งแสดงจำนวนคำขอต่อวินาที Error Rate ซึ่งแสดงเปอร์เซ็นต์ของคำขอที่ล้มเหลว และ Latency ซึ่งแสดงเวลาที่ใช้ในการตอบสนอง
| ตัวชี้วัด | ความหมาย | ค่าปกติ | เมื่อควรตั้งสัญญาณเตือน |
|---|---|---|---|
| Request Rate (RPS) | จำนวนคำขอต่อวินาที | ขึ้นอยู่กับแอปพลิเคชัน | ลดลงกว่า 50% จากปกติ |
| Error Rate | เปอร์เซ็นต์ของคำขอที่ล้มเหลว | ต่ำกว่า 0.5% | สูงกว่า 1% |
| Latency P99 | เวลาที่ 99% ของคำขอตอบสนอง | ต่ำกว่า 200ms | สูงกว่า 500ms |
| mTLS Success Rate | เปอร์เซ็นต์การเชื่อมต่อที่ปลอดภัย | 100% | ต่ำกว่า 99% |
Service Map และการมองเห็นความเชื่อมโยง
หนึ่งในฟีเจอร์ที่มีประโยชน์ที่สุดของ SigNoz คือ Service Map ซึ่งแสดงแผนที่ของบริการทั้งหมดและความเชื่อมโยงระหว่างกัน คุณสามารถมองเห็นว่าบริการใดกำลังติดต่อกับบริการใด และมีปัญหาอะไรเกิดขึ้นในการเชื่อมต่อ
Service Map นี้ถูกสร้างขึ้นโดยอัตโนมัติจากข้อมูล Traces ที่ SigNoz รวบรวม ซึ่งหมายความว่าคุณไม่ต้องตั้งค่าเพิ่มเติม เพียงแค่ปล่อยให้ SigNoz รวบรวมข้อมูล
Trace Explorer และการสืบสอบปัญหา
เมื่อมีปัญหาเกิดขึ้น Trace Explorer จะช่วยให้คุณหาสาเหตุ คุณสามารถค้นหา Traces ที่มีระยะเวลานาน หรือ Traces ที่ล้มเหลว และดูว่าเกิดอะไรขึ้นในแต่ละขั้นตอน
การตั้งค่า Alert เพื่อการตรวจสอบอัตโนมัติ
การตั้งค่า Alert ช่วยให้คุณรู้ทันทีเมื่อมีปัญหาเกิดขึ้น แทนที่จะต้องมองหาปัญหาด้วยตัวเอง
Alert สำหรับ Error Rate
หากอัตราข้อผิดพลาดเพิ่มขึ้นอย่างกระทันหัน นั่นอาจเป็นสัญญาณว่ามีปัญหาบางอย่าง คุณสามารถตั้งให้ SigNoz ส่งการแจ้งเตือนเมื่ออัตราข้อผิดพลาดเกินกว่า 1% เป็นเวลา 5 นาทีต่อเนื่อง
Alert สำหรับ Latency
ถ้าเวลาตอบสนองของระบบเพิ่มขึ้นอย่างกระทันหัน ผู้ใช้อาจรู้สึกว่าระบบช้า คุณสามารถตั้งให้ SigNoz แจ้งเตือนเมื่อ Latency P99 เกินกว่า 500 มิลลิวินาที
Alert สำหรับ Service Down
หากบริการใดหยุดการทำงาน Request Rate จะเป็นศูนย์ คุณสามารถตั้งให้ SigNoz แจ้งเตือนเมื่อ Request Rate เป็นศูนย์เป็นเวลา 2 นาที
Alert สำหรับปัญหา mTLS
mTLS เป็นวิธีการเข้ารหัสการสื่อสารระหว่างบริการ หากมีปัญหากับ mTLS การสื่อสารอาจไม่ปลอดภัย คุณสามารถตั้งให้ SigNoz แจ้งเตือนเมื่อมีการเชื่อมต่อที่ไม่ใช้ mTLS
| ชื่อ Alert | เงื่อนไข | ความสำคัญ | ช่องทางการแจ้งเตือน |
|---|---|---|---|
| High Error Rate | Error Rate > 1% เป็นเวลา 5 นาที | Critical | Slack, PagerDuty |
| High Latency | P99 Latency > 500ms เป็นเวลา 5 นาที | Warning | Slack |
| Service Down | Request Rate = 0 เป็นเวลา 2 นาที | Critical | Slack, PagerDuty, Email |
| mTLS Failure | การเชื่อมต่อที่ไม่ใช้ mTLS | High | Slack #security |
เคล็ดลับและแนวปฏิบัติที่ดี
เมื่อใช้ SigNoz กับ Service Mesh มีหลายเคล็ดลับที่จะช่วยให้คุณได้ประโยชน์สูงสุด
การใช้ Sampling เพื่อประหยัดค่าใช้จ่าย
การรวบรวมข้อมูล Traces ทั้งหมดอาจใช้ทรัพยากรจำนวนมาก โดยเฉพาะในระบบที่มีคำขอจำนวนมาก วิธีแก้ปัญหาคือใช้ Sampling ซึ่งหมายความว่าคุณจะรวบรวมเพียงบางส่วนของข้อมูล เช่น 10% ของ Traces เท่านั้น
วิธีนี้จะช่วยลดปริมาณข้อมูลลง 10 เท่า ซึ่งจะลดค่าใช้จ่ายและการใช้ทรัพยากร แต่คุณยังคงได้ข้อมูลที่เพียงพอเพื่อหาปัญหา
การตั้งค่า TTL สำหรับการเก็บข้อมูล
ClickHouse ซึ่งเป็นฐานข้อมูลของ SigNoz จะเติบโตอย่างรวดเร็ว หากคุณไม่กำหนดว่าจะเก็บข้อมูลนานเท่าใด ดิสก์ของคุณอาจเต็ม
วิธีแก้ปัญหาคือตั้ง TTL (Time To Live) ซึ่งบอกให้ SigNoz ลบข้อมูลเก่าโดยอัตโนมัติ ตัวอย่างเช่น คุณสามารถตั้งให้เก็บข้อมูลเป็นเวลา 7 ถึง 30 วันเท่านั้น
การใช้ Service Map เพื่อค้นหาปัญหาที่ไม่คาดคิด
บางครั้งคุณอาจพบการเชื่อมต่อระหว่างบริการที่คุณไม่รู้ว่าอยู่ Service Map จะช่วยให้คุณเห็นการเชื่อมต่อเหล่านี้ และคุณสามารถตรวจสอบว่ามันเป็นสิ่งที่ตั้งใจหรือไม่
การแยก Namespace ตามสภาพแวดล้อม
เป็นแนวปฏิบัติที่ดีที่จะแยก Namespace ตามสภาพแวดล้อม เช่น dev staging และ prod ด้วยวิธีนี้ คุณสามารถติดตั้ง SigNoz แยกต่างหากสำหรับแต่ละสภาพแวดล้อม และคุณจะไม่เสี่ยงต่อการส่งข้อมูลการทดลองไปยัง Production
การแก้ไขปัญหาทั่วไป
เมื่อตั้งค่า SigNoz กับ Service Mesh คุณอาจพบปัญหาบางอย่าง นี่คือวิธีแก้ไขปัญหาทั่วไปบางอย่าง
ไม่มีข้อมูล Traces ปรากฏใน SigNoz
หากคุณไม่เห็นข้อมูล Traces ในอินเทอร์เฟซของ SigNoz ให้ตรวจสอบว่า OTel Collector ทำงานอยู่หรือไม่ คุณสามารถใช้คำสั่ง kubectl logs เพื่อดูบันทึกของ OTel Collector
นอกจากนี้ ให้ตรวจสอบว่า Istio ส่งข้อมูลไปยังที่อยู่ที่ถูกต้องของ OTel Collector
Latency สูงอย่างไม่ปกติ
หากคุณเห็นว่า Latency สูงขึ้นอย่างไม่ปกติ ให้ดู Trace Explorer เพื่อหาว่าบริการใดใช้เวลานานที่สุด คุณอาจจะพบว่ามีการเรียกใช้ฐานข้อมูลที่ช้าหรือการเรียกใช้บริการอื่นที่ช้า
mTLS ไม่ทำงาน
หากมีปัญหากับ mTLS ให้ตรวจสอบว่า Certificate ของ Istio ยังใช้ได้อยู่หรือไม่ คุณสามารถตรวจสอบวันหมดอายุของ Certificate ได้