พิจารณาแนวคิดของการตรวจสอบ Kubernetes ทำความคุ้นเคยกับเครื่องมือ Prometheus และพูดคุยเกี่ยวกับการแจ้งเตือน
หัวข้อการตรวจสอบมีมากมายไม่สามารถแยกออกเป็นบทความเดียวได้ วัตถุประสงค์ของบทความนี้คือเพื่อให้ภาพรวมของเครื่องมือ แนวคิด และแนวทางต่างๆ
เนื้อหาของบทความก็บีบมาจาก . หากคุณต้องการเรียนหลักสูตรเต็ม - ลงทะเบียนเพื่อรับหลักสูตร .
สิ่งที่ได้รับการตรวจสอบในคลัสเตอร์ Kubernetes
ฟิสิคัลเซิร์ฟเวอร์ หากปรับใช้คลัสเตอร์ Kubernetes บนเซิร์ฟเวอร์ คุณจะต้องตรวจสอบความสมบูรณ์ของคลัสเตอร์ Zabbix จัดการงานนี้ หากคุณทำงานร่วมกับเขา คุณไม่จำเป็นต้องปฏิเสธ จะไม่มีความขัดแย้ง Zabbix เป็นผู้ที่ตรวจสอบสถานะของเซิร์ฟเวอร์ของเรา
มาดูการตรวจสอบในระดับคลัสเตอร์กันดีกว่า
ส่วนประกอบเครื่องบินควบคุม: API, Scheduler และอื่นๆ อย่างน้อยที่สุด คุณต้องตรวจสอบให้แน่ใจว่า API ของเซิร์ฟเวอร์หรือ etcd มากกว่า 0 เป็นต้น Etcd สามารถส่งคืนตัววัดจำนวนมาก: โดยดิสก์ที่มันหมุนอยู่ โดยความสมบูรณ์ของคลัสเตอร์ etcd และอื่นๆ
นักเทียบท่า ปรากฏตัวเมื่อนานมาแล้วและทุกคนก็ตระหนักดีถึงปัญหาของมัน: ตู้คอนเทนเนอร์จำนวนมากทำให้เกิดการค้างและปัญหาอื่น ๆ ดังนั้น Docker เองในฐานะระบบจึงควรได้รับการควบคุม อย่างน้อยก็เพื่อความพร้อมใช้งาน
DNS หาก DNS หลุดในคลัสเตอร์ บริการ Discovery ทั้งหมดจะหยุดทำงานหลังจากนั้น การโทรจากพ็อดหนึ่งไปยังอีกพ็อดจะหยุดทำงาน ในทางปฏิบัติของฉันไม่มีปัญหาดังกล่าว แต่ไม่ได้หมายความว่าไม่จำเป็นต้องตรวจสอบสถานะของ DNS เวลาแฝงของคำขอและตัวชี้วัดอื่นๆ สามารถติดตามได้บน CoreDNS
ทางเข้า มีความจำเป็นต้องควบคุมความพร้อมของทางเข้า (รวมถึงตัวควบคุมทางเข้า) เป็นจุดเริ่มต้นเข้าสู่โครงการ
ส่วนประกอบหลักของคลัสเตอร์ถูกรื้อออกแล้ว - ตอนนี้เรามาดูระดับนามธรรมกันดีกว่า
ดูเหมือนว่าแอปพลิเคชันจะทำงานในพ็อด ซึ่งหมายความว่าจำเป็นต้องได้รับการควบคุม แต่ในความเป็นจริงแล้ว ไม่ใช่เลย พ็อดเป็นแบบชั่วคราว: วันนี้จะทำงานบนเซิร์ฟเวอร์เครื่องหนึ่ง พรุ่งนี้จะทำงานบนเซิร์ฟเวอร์อื่น วันนี้มี 10 ตัว พรุ่งนี้ 2 เลยไม่มีใครเฝ้าฝัก ภายในสถาปัตยกรรมไมโครเซอร์วิส การควบคุมความพร้อมใช้งานของแอปพลิเคชันโดยรวมมีความสำคัญมากกว่า โดยเฉพาะตรวจสอบความพร้อมใช้งานของจุดสิ้นสุดบริการ: มีอะไรใช้งานได้บ้าง? หากแอปพลิเคชันพร้อมใช้งาน แล้วจะเกิดอะไรขึ้นในภายหลัง มีกี่แบบจำลอง - นี่เป็นคำถามเกี่ยวกับลำดับที่สอง ไม่จำเป็นต้องตรวจสอบแต่ละอินสแตนซ์
ในระดับสุดท้าย คุณต้องควบคุมการทำงานของแอปพลิเคชัน ใช้การวัดทางธุรกิจ เช่น จำนวนคำสั่งซื้อ พฤติกรรมผู้ใช้ และอื่นๆ
โพร
ระบบที่ดีที่สุดสำหรับการตรวจสอบคลัสเตอร์คือ . ฉันไม่รู้เครื่องมือใดที่สามารถเทียบได้กับ Prometheus ในแง่ของคุณภาพและความสะดวกในการใช้งาน เหมาะสำหรับโครงสร้างพื้นฐานที่ยืดหยุ่น ดังนั้นเมื่อพวกเขาพูดว่า “การตรวจสอบ Kubernetes” พวกเขามักจะหมายถึง Prometheus
มีสองตัวเลือกในการเริ่มต้นใช้งาน Prometheus: เมื่อใช้ Helm คุณสามารถติดตั้ง Prometheus หรือ Prometheus Operator ได้
- โพรมีธีอุสปกติ ทุกอย่างเรียบร้อยดีสำหรับเขา แต่คุณต้องกำหนดค่า ConfigMap - อันที่จริงเขียนไฟล์การกำหนดค่าแบบข้อความเหมือนที่เราเคยทำมาก่อน ก่อนสถาปัตยกรรมไมโครเซอร์วิส
- Prometheus Operator กระจายออกไปเล็กน้อย ซับซ้อนกว่าเล็กน้อยในแง่ของตรรกะภายใน แต่ใช้งานได้ง่ายกว่า: มีออบเจ็กต์ที่แยกจากกัน มีการเพิ่มนามธรรมลงในคลัสเตอร์ ดังนั้นจึงสะดวกกว่ามากในการควบคุมและกำหนดค่า
เพื่อให้เข้าใจถึงผลิตภัณฑ์ ฉันแนะนำให้ติดตั้ง Prometheus ปกติก่อน คุณจะต้องกำหนดค่าทุกอย่างผ่านการกำหนดค่า แต่จะเป็นประโยชน์: คุณจะทราบว่าสิ่งใดเป็นของสิ่งใดและกำหนดค่าอย่างไร ใน Prometheus Operator คุณจะก้าวไปสู่สิ่งที่เป็นนามธรรมที่สูงขึ้นในทันที แม้ว่าคุณจะสามารถเจาะลึกลงไปได้หากต้องการก็ตาม
Prometheus ทำงานร่วมกับ Kubernetes ได้เป็นอย่างดี โดยสามารถเข้าถึงและโต้ตอบกับเซิร์ฟเวอร์ API ได้
Prometheus ได้รับความนิยมซึ่งเป็นเหตุผลว่าทำไมแอปพลิเคชันและภาษาการเขียนโปรแกรมจำนวนมากจึงรองรับ จำเป็นต้องมีการสนับสนุน เนื่องจาก Prometheus มีรูปแบบหน่วยเมตริกของตัวเอง และในการถ่ายโอน คุณต้องมีไลบรารีภายในแอปพลิเคชันหรือผู้ส่งออกสำเร็จรูป และมีผู้ส่งออกดังกล่าวจำนวนไม่น้อย ตัวอย่างเช่น มี PostgreSQL Exporter ซึ่งรับข้อมูลจาก PostgreSQL และแปลงเป็นรูปแบบ Prometheus เพื่อให้ Prometheus สามารถทำงานได้
สถาปัตยกรรมของโพรมีธีอุส
เซิร์ฟเวอร์โพรมีธีอุส คือส่วนหลังซึ่งเป็นสมองของโพรมีธีอุส เมตริกจะถูกจัดเก็บและประมวลผลที่นี่
หน่วยวัดจะถูกจัดเก็บไว้ในฐานข้อมูลอนุกรมเวลา (TSDB) TSDB ไม่ใช่ฐานข้อมูลแยกต่างหาก แต่เป็นแพ็คเกจในภาษา Go ที่ฝังอยู่ใน Prometheus พูดคร่าวๆ ก็คือ ทุกอย่างอยู่ในไบนารี่เดียว
อย่าเก็บข้อมูลใน TSDB เป็นเวลานาน
โครงสร้างพื้นฐานของ Prometheus ไม่เหมาะสำหรับการจัดเก็บตัววัดในระยะยาว ระยะเวลาเก็บรักษาเริ่มต้นคือ 15 วัน คุณสามารถเกินขีดจำกัดนี้ได้ แต่โปรดจำไว้ว่า: ยิ่งคุณจัดเก็บข้อมูลใน TSDB มากเท่าไร และยิ่งคุณเก็บข้อมูลนานเท่าไร ก็จะยิ่งใช้ทรัพยากรมากขึ้นเท่านั้น การจัดเก็บข้อมูลในอดีตใน Prometheus ถือเป็นการปฏิบัติที่ไม่ดี
หากคุณมีปริมาณการรับส่งข้อมูลจำนวนมาก จำนวนตัวชี้วัดคือหลายแสนต่อวินาที ดังนั้นจึงเป็นการดีกว่าที่จะจำกัดพื้นที่เก็บข้อมูลตามพื้นที่ดิสก์หรือตามช่วงเวลา โดยปกติแล้ว “ข้อมูลยอดนิยม” จะถูกจัดเก็บไว้ใน TSDB ซึ่งเป็นหน่วยวัดภายในเวลาเพียงไม่กี่ชั่วโมง สำหรับการจัดเก็บข้อมูลที่ยาวนานขึ้น จะใช้ที่เก็บข้อมูลภายนอกในฐานข้อมูลที่เหมาะสมที่สุดสำหรับสิ่งนี้ เช่น InfluxDB, ClickHouse เป็นต้น ฉันเห็นรีวิวดีๆ เกี่ยวกับ ClickHouse มากขึ้น
Prometheus Server ทำงานบนโมเดลนี้ ดึง: เขาไปหาตัวชี้วัดไปยังจุดสิ้นสุดที่เรามอบให้ พวกเขาพูดว่า: "ไปที่เซิร์ฟเวอร์ API" และเขาจะไปที่นั่นทุก ๆ วินาทีที่ n และรับการวัด
สำหรับอ็อบเจ็กต์ที่มีอายุการใช้งานสั้น (งานหรืองาน cron) ที่สามารถปรากฏขึ้นระหว่างช่วงการขูด จะมีส่วนประกอบ Pushgateway ตัวชี้วัดจากวัตถุระยะสั้นจะถูกผลักเข้าไป: งานเพิ่มขึ้น ดำเนินการ ส่งตัวชี้วัดไปยัง Pushgateway และเสร็จสิ้น หลังจากนั้นไม่นาน Prometheus ก็จะลงมาตามจังหวะของตัวเองและรับตัวชี้วัดเหล่านี้จาก Pushgateway
ในการกำหนดค่าการแจ้งเตือนใน Prometheus จะมีองค์ประกอบแยกต่างหาก - ตัวจัดการการแจ้งเตือน. และกฎการแจ้งเตือน ตัวอย่างเช่น คุณต้องสร้างการแจ้งเตือนหาก API ของเซิร์ฟเวอร์เป็น 0 เมื่อเหตุการณ์เริ่มทำงาน การแจ้งเตือนจะถูกส่งไปยังตัวจัดการการแจ้งเตือนเพื่อดำเนินการจัดส่งต่อไป ตัวจัดการการแจ้งเตือนมีการตั้งค่าเส้นทางที่ค่อนข้างยืดหยุ่น: กลุ่มการแจ้งเตือนหนึ่งสามารถส่งไปยังแชทโทรเลขของผู้ดูแลระบบ อีกกลุ่มหนึ่งส่งไปยังแชทของนักพัฒนา และกลุ่มที่สามส่งไปยังแชทของคนงานโครงสร้างพื้นฐาน สามารถส่งการแจ้งเตือนไปยัง Slack, Telegram, อีเมล และช่องทางอื่นๆ
และสุดท้ายนี้ ฉันจะบอกคุณเกี่ยวกับฟีเจอร์ Prometheus killer - การค้นพบ. เมื่อทำงานกับ Prometheus คุณไม่จำเป็นต้องระบุที่อยู่เฉพาะของวัตถุสำหรับการตรวจสอบ เพียงกำหนดประเภทก็เพียงพอแล้ว นั่นคือคุณไม่จำเป็นต้องเขียน "นี่คือที่อยู่ IP นี่คือพอร์ต - มอนิเตอร์" แต่คุณต้องกำหนดตามหลักการที่จะค้นหาวัตถุเหล่านี้ (เป้าหมาย - เป้าหมาย) ตัว Prometheus จะดึงวัตถุที่จำเป็นขึ้นมาและเพิ่มลงในการตรวจสอบ โดยขึ้นอยู่กับว่าวัตถุใดที่ใช้งานอยู่ในปัจจุบัน
วิธีการนี้เข้ากันได้ดีกับโครงสร้าง Kubernetes ซึ่งทุกอย่างยังลอยอยู่: วันนี้มีเซิร์ฟเวอร์ 10 เครื่อง พรุ่งนี้ 3 เพื่อไม่ให้ระบุที่อยู่ IP ของเซิร์ฟเวอร์ในแต่ละครั้ง พวกเขาเขียนวิธีค้นหาหนึ่งครั้ง - และ Discovering จะดำเนินการ .
ภาษาโพรมีธีอุสเรียกว่า PromQL. เมื่อใช้ภาษานี้ คุณจะได้รับค่าของตัวชี้วัดเฉพาะ จากนั้นแปลงค่าเหล่านั้น สร้างการคำนวณเชิงวิเคราะห์ตามค่าเหล่านั้น
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)เว็บอินเตอร์เฟสของโพรมีธีอุส
Prometheus มีเว็บอินเตอร์เฟสที่ค่อนข้างเรียบง่ายเป็นของตัวเอง เหมาะสำหรับการดีบักหรือการสาธิตเท่านั้น
ในบรรทัด Expression คุณสามารถเขียนแบบสอบถามในภาษา PromQL ได้
แท็บการแจ้งเตือนประกอบด้วยกฎการแจ้งเตือน และมีสถานะ XNUMX สถานะ:
- ไม่ได้ใช้งาน - หากการแจ้งเตือนไม่ทำงานในขณะนี้นั่นคือทุกอย่างเรียบร้อยดีและใช้งานไม่ได้
- รอดำเนินการ - นี่คือหากการแจ้งเตือนใช้งานได้ แต่การส่งยังไม่ผ่าน ความล่าช้าถูกตั้งค่าเพื่อชดเชยการกะพริบของเครือข่าย: หากบริการที่ระบุเพิ่มขึ้นภายในหนึ่งนาที ก็ไม่ควรส่งเสียงเตือน
- การยิงเป็นสถานะที่สามเมื่อการแจ้งเตือนสว่างขึ้นและส่งข้อความ
ในเมนูสถานะ คุณจะพบการเข้าถึงข้อมูลเกี่ยวกับ Prometheus นอกจากนี้ยังมีการเปลี่ยนไปสู่เป้าหมาย (เป้าหมาย) ซึ่งเราได้พูดถึงข้างต้น
สำหรับภาพรวมโดยละเอียดเพิ่มเติมของอินเทอร์เฟซ Prometheus โปรดดู .
บูรณาการกับกราฟาน่า
ในเว็บอินเตอร์เฟสของ Prometheus คุณจะไม่พบกราฟที่สวยงามและเข้าใจได้ซึ่งคุณสามารถสรุปเกี่ยวกับสถานะของคลัสเตอร์ได้ ในการสร้างสิ่งเหล่านี้ Prometheus ได้รวมเข้ากับ Grafana เราได้รับแดชบอร์ดดังกล่าว
การตั้งค่าการรวม Prometheus และ Grafana นั้นไม่ใช่เรื่องยาก คุณสามารถดูคำแนะนำได้ในเอกสารประกอบ: ฉันจะจบเรื่องนี้ด้วย
ในบทความต่อไปนี้ เราจะพูดถึงหัวข้อการตรวจสอบต่อไป: เราจะพูดถึงการรวบรวมและวิเคราะห์บันทึกโดยใช้ Grafana Loki และเครื่องมือทางเลือก
ผู้แต่ง: Marcel Ibraev ผู้ดูแลระบบ Kubernetes ที่ได้รับการรับรอง วิศวกรฝึกหัดในบริษัท วิทยากรและผู้พัฒนาหลักสูตร Slurm
ที่มา: will.com