การมอนิเตอร์ตายแล้วเหรอ? - การติดตามผลระยะยาว

ตั้งแต่ปี 2008 บริษัทของเราดำเนินธุรกิจหลักในด้านการจัดการโครงสร้างพื้นฐานและการสนับสนุนทางเทคนิคตลอด 400 ชั่วโมงสำหรับโครงการเว็บ เรามีลูกค้ามากกว่า 15 ราย ซึ่งคิดเป็นประมาณ 15% ของอีคอมเมิร์ซในรัสเซีย ดังนั้นจึงรองรับสถาปัตยกรรมที่หลากหลายมาก หากมีอะไรตกเราจะต้องซ่อมแซมภายใน XNUMX นาที แต่เพื่อให้เข้าใจว่าเกิดอุบัติเหตุขึ้น คุณต้องติดตามโครงการและตอบสนองต่อเหตุการณ์ที่เกิดขึ้น วิธีการทำเช่นนี้?

ผมเชื่อว่ามีปัญหาในการจัดระบบติดตามตรวจสอบที่เหมาะสม หากไม่มีปัญหาใด ๆ คำพูดของฉันก็จะประกอบด้วยวิทยานิพนธ์เรื่องหนึ่ง: “โปรดติดตั้ง Prometheus + Grafana และปลั๊กอิน 1, 2, 3” น่าเสียดายที่มันไม่ได้ผลเช่นนั้นอีกต่อไป และปัญหาหลักก็คือทุกคนยังคงเชื่อในบางสิ่งที่มีอยู่ในปี 2008 ในแง่ของส่วนประกอบของซอฟต์แวร์

ในส่วนของการจัดระบบการติดตาม ผมจะกล้าพูดว่า... โครงการที่มีความสามารถในการติดตามไม่มีอยู่จริง และสถานการณ์เลวร้ายมากจนหากมีอะไรตกหล่น ก็มีความเสี่ยงที่จะไม่มีใครสังเกตเห็น เพราะทุกคนมั่นใจว่า "ทุกอย่างได้รับการตรวจสอบ"
บางทีทุกอย่างอาจถูกตรวจสอบ แต่อย่างไร?

เราทุกคนเคยพบกับเรื่องราวเช่นนี้: มี Devop คนหนึ่ง ผู้ดูแลระบบบางคนกำลังทำงานอยู่ ทีมพัฒนามาหาพวกเขาแล้วพูดว่า - "เราถูกปล่อยตัวแล้ว คอยติดตามดู" ติดตามอะไร? มันทำงานอย่างไร?

ตกลง. เราติดตามด้วยวิธีที่ล้าสมัย และมันกำลังเปลี่ยนแปลงไป และปรากฎว่าคุณได้ตรวจสอบบริการ A ซึ่งกลายเป็นบริการ B ซึ่งโต้ตอบกับบริการ C แต่ทีมพัฒนาบอกคุณว่า: “ติดตั้งซอฟต์แวร์ ควรตรวจสอบทุกอย่าง!”

แล้วมีอะไรเปลี่ยนแปลงบ้าง? - ทุกอย่างเปลี่ยนไปแล้ว!

2008 ทุกอย่างปกติดี

มีนักพัฒนาสองสามราย หนึ่งเซิร์ฟเวอร์ หนึ่งเซิร์ฟเวอร์ฐานข้อมูล ทุกอย่างไปจากที่นี่ เรามีข้อมูลบางอย่าง เราติดตั้ง zabbix, Nagios, cacti จากนั้นเราก็ตั้งค่าการแจ้งเตือนที่ชัดเจนบน CPU การทำงานของดิสก์ และพื้นที่ดิสก์ นอกจากนี้เรายังทำการตรวจสอบด้วยตนเองสองสามรายการเพื่อให้แน่ใจว่าไซต์ตอบสนองและมีคำสั่งซื้อเข้ามาในฐานข้อมูล เพียงเท่านี้ เราก็ได้รับการปกป้องไม่มากก็น้อย

หากเราเปรียบเทียบปริมาณงานที่ผู้ดูแลระบบทำในการตรวจสอบ 98% ของงานนั้นเป็นไปโดยอัตโนมัติ: ผู้ที่ทำหน้าที่ตรวจสอบจะต้องเข้าใจวิธีติดตั้ง Zabbix วิธีกำหนดค่าและกำหนดค่าการแจ้งเตือน และ 2% - สำหรับการตรวจสอบภายนอก: ไซต์ตอบสนองและร้องขอไปยังฐานข้อมูลว่ามีคำสั่งซื้อใหม่มาถึงแล้ว

2010 ภาระมีการเติบโต

เรากำลังเริ่มขยายขนาดเว็บโดยเพิ่มเครื่องมือค้นหา เราต้องการให้แน่ใจว่าแค็ตตาล็อกผลิตภัณฑ์มีผลิตภัณฑ์ทั้งหมด และการค้นหาผลิตภัณฑ์นั้นก็ใช้ได้ผล ฐานข้อมูลกำลังทำงาน กำลังดำเนินการสั่งซื้อ ไซต์ตอบสนองภายนอกและตอบกลับจากเซิร์ฟเวอร์สองเครื่อง และผู้ใช้ไม่ถูกไล่ออกจากไซต์ในขณะที่มีการปรับสมดุลไปยังเซิร์ฟเวอร์อื่น เป็นต้น มีเอนทิตีมากขึ้น

นอกจากนี้ หน่วยงานที่เกี่ยวข้องกับโครงสร้างพื้นฐานยังคงเป็นหน่วยงานที่ใหญ่ที่สุดในหัวหน้าของผู้จัดการ ยังคงมีความคิดในหัวของฉันว่าคนที่ทำการตรวจสอบคือคนที่จะติดตั้ง zabbix และสามารถกำหนดค่าได้

แต่ในขณะเดียวกันก็มีงานปรากฏในการดำเนินการตรวจสอบภายนอก, การสร้างชุดสคริปต์แบบสอบถามตัวสร้างดัชนีการค้นหา, ชุดสคริปต์เพื่อตรวจสอบว่าการค้นหาเปลี่ยนแปลงไปในระหว่างกระบวนการจัดทำดัชนี, ชุดสคริปต์ที่ตรวจสอบว่าสินค้าถูกโอนไปยัง บริการจัดส่ง ฯลฯ และอื่น ๆ

หมายเหตุ: ฉันเขียน “ชุดสคริปต์” 3 ครั้ง นั่นคือบุคคลที่รับผิดชอบในการตรวจสอบไม่ใช่เพียงผู้ติดตั้ง zabbix อีกต่อไป นี่คือบุคคลที่เริ่มเขียนโค้ด แต่ยังไม่มีอะไรเปลี่ยนแปลงในใจของทีม

แต่โลกกำลังเปลี่ยนแปลง ซับซ้อนมากขึ้นเรื่อยๆ มีการเพิ่มเลเยอร์การจำลองเสมือนและระบบใหม่หลายระบบ พวกเขาเริ่มมีปฏิสัมพันธ์กัน ใครบอกว่า “มีกลิ่นเหมือนไมโครเซอร์วิส” แต่บริการแต่ละรายการยังคงดูเหมือนเป็นเว็บไซต์แยกกัน เราสามารถหันไปใช้และเข้าใจว่าข้อมูลดังกล่าวให้ข้อมูลที่จำเป็นและทำงานได้ด้วยตัวเอง และหากคุณเป็นผู้ดูแลระบบที่มีส่วนร่วมอย่างต่อเนื่องในโครงการที่พัฒนามาเป็นเวลา 5-7-10 ปี ความรู้นี้จะสะสม: ระดับใหม่ปรากฏขึ้น - คุณตระหนักแล้ว อีกระดับหนึ่งปรากฏขึ้น - คุณตระหนักแล้ว...

แต่ไม่ค่อยมีใครร่วมโครงการเป็นเวลา 10 ปี

ประวัติย่อของผู้เฝ้าติดตาม

สมมติว่าคุณเริ่มต้นธุรกิจสตาร์ทอัพใหม่ที่จ้างนักพัฒนา 20 คนทันที เขียนไมโครเซอร์วิส 15 รายการ และคุณเป็นผู้ดูแลระบบที่ได้รับแจ้งว่า: “สร้าง CI/CD โปรด." คุณได้สร้าง CI/CD แล้วจู่ๆ คุณก็ได้ยิน: “เป็นเรื่องยากสำหรับเราที่จะทำงานกับการผลิตแบบ “คิวบ์” โดยไม่เข้าใจว่าแอปพลิเคชันจะทำงานอย่างไร ทำให้เรากลายเป็นกระบะทรายใน "คิวบ์" เดียวกัน
คุณสร้างแซนด์บ็อกซ์ในคิวบ์นี้ พวกเขาบอกคุณทันทีว่า: “เราต้องการฐานข้อมูลสเตจที่อัปเดตทุกวันตั้งแต่การใช้งานจริง เพื่อที่เราจะได้เข้าใจว่ามันใช้งานได้บนฐานข้อมูล แต่ในขณะเดียวกันก็ไม่ทำให้ฐานข้อมูลที่ใช้งานจริงเสียหาย”

คุณอาศัยอยู่ในทั้งหมดนี้ เหลือเวลาอีก 2 สัปดาห์ก่อนการเปิดตัว พวกเขาบอกคุณว่า: "ตอนนี้มาติดตามทั้งหมดนี้กันเถอะ ... " นั่นคือ ตรวจสอบโครงสร้างพื้นฐานของคลัสเตอร์ ตรวจสอบสถาปัตยกรรมไมโครเซอร์วิส ตรวจสอบงานกับบริการภายนอก...

และเพื่อนร่วมงานของฉันก็เอาแผนการปกติออกไปจากหัวแล้วพูดว่า: "ที่นี่ทุกอย่างชัดเจนแล้ว! ติดตั้งโปรแกรมที่จะตรวจสอบทั้งหมดนี้” ใช่ ใช่: ปลั๊กอิน Prometheus + Grafana +
และพวกเขาเสริมว่า “คุณมีเวลาสองสัปดาห์ ตรวจสอบให้แน่ใจว่าทุกอย่างปลอดภัย”

ในหลายโครงการที่เราเห็น มีคน 2 คนถูกจัดสรรเพื่อติดตาม ลองจินตนาการว่าเราต้องการจ้างคนมาเฝ้าดูเป็นเวลา XNUMX สัปดาห์ แล้วเราก็เขียนเรซูเม่ให้เขา บุคคลนี้ควรมีทักษะอะไรบ้าง จากทุกสิ่งที่เราพูดไปแล้ว?

• เขาต้องเข้าใจการติดตามและลักษณะเฉพาะของการดำเนินงานของโครงสร้างพื้นฐานเหล็ก
• เขาจะต้องเข้าใจลักษณะเฉพาะของการตรวจสอบ Kubernetes (และทุกคนต้องการไปที่ "คิวบ์" เพราะคุณสามารถนามธรรมจากทุกสิ่งซ่อนได้เพราะผู้ดูแลระบบจะจัดการกับส่วนที่เหลือ) - ตัวมันเองโครงสร้างพื้นฐานและเข้าใจวิธีตรวจสอบแอปพลิเคชัน ข้างใน.
• เขาต้องเข้าใจว่าบริการต่างๆ สื่อสารกันด้วยวิธีพิเศษ และรู้เฉพาะเจาะจงว่าบริการโต้ตอบกันอย่างไร ค่อนข้างเป็นไปได้ที่จะเห็นโปรเจ็กต์ที่บริการบางอย่างสื่อสารพร้อมกัน เนื่องจากไม่มีวิธีอื่น ตัวอย่างเช่น แบ็กเอนด์จะส่งผ่าน REST ผ่าน gRPC ไปยังบริการแคตตาล็อก รับรายการผลิตภัณฑ์และส่งคืนกลับ คุณไม่สามารถรอที่นี่ และด้วยบริการอื่น ๆ มันทำงานแบบอะซิงโครนัส โอนคำสั่งซื้อไปยังบริการจัดส่ง ส่งจดหมาย ฯลฯ
  คุณคงว่ายมาจากเรื่องทั้งหมดนี้แล้วเหรอ? และผู้ดูแลระบบที่ต้องติดตามเรื่องนี้ก็ยิ่งสับสนมากขึ้น
• เขาจะต้องสามารถวางแผนและวางแผนได้อย่างถูกต้อง - เมื่องานเพิ่มมากขึ้น
• เขาจึงต้องสร้างกลยุทธ์จากบริการที่สร้างขึ้นเพื่อทำความเข้าใจวิธีการติดตามโดยเฉพาะ เขาต้องการความเข้าใจเกี่ยวกับสถาปัตยกรรมของโครงการและการพัฒนา + ความเข้าใจในเทคโนโลยีที่ใช้ในการพัฒนา

โปรดจำไว้ว่าเป็นกรณีปกติ: บริการบางอย่างอยู่ใน PHP, บริการบางอย่างอยู่ใน Go, บริการบางอย่างอยู่ใน JS พวกเขาทำงานร่วมกัน นี่คือที่มาของคำว่า "ไมโครเซอร์วิส": มีระบบต่างๆ มากมายที่นักพัฒนาไม่สามารถเข้าใจโครงการโดยรวมได้ ส่วนหนึ่งของทีมเขียนบริการใน JS ที่ทำงานด้วยตัวเองและไม่รู้ว่าส่วนที่เหลือของระบบทำงานอย่างไร อีกส่วนหนึ่งเขียนบริการด้วย Python และไม่รบกวนการทำงานของบริการอื่น ๆ โดยบริการจะถูกแยกออกจากพื้นที่ของตนเอง อย่างที่สามคือการเขียนบริการด้วย PHP หรืออย่างอื่น
ทั้ง 20 คนนี้แบ่งออกเป็น 15 บริการ และมีผู้ดูแลระบบเพียงคนเดียวเท่านั้นที่ต้องเข้าใจทั้งหมดนี้ หยุด! เราเพิ่งแบ่งระบบออกเป็น 15 ไมโครเซอร์วิส เพราะมีคน 20 คนไม่เข้าใจทั้งระบบ

แต่ก็ต้องติดตามกันต่อไป...

ผลลัพธ์เป็นอย่างไร? เป็นผลให้มีคนคนหนึ่งที่มาพร้อมกับทุกสิ่งที่ทีมนักพัฒนาทั้งหมดไม่สามารถเข้าใจได้และในขณะเดียวกันเขาก็ต้องรู้และสามารถทำสิ่งที่เราระบุไว้ข้างต้นได้ - โครงสร้างพื้นฐานฮาร์ดแวร์, โครงสร้างพื้นฐาน Kubernetes เป็นต้น

ฉันจะพูดอะไรได้... ฮูสตัน เรามีปัญหาแล้ว

การตรวจสอบโครงการซอฟต์แวร์สมัยใหม่ถือเป็นโครงการซอฟต์แวร์ในตัวเอง

จากความเชื่อผิดๆ ว่าการตรวจสอบคือซอฟต์แวร์ เราจึงพัฒนาความเชื่อเรื่องปาฏิหาริย์ แต่ปาฏิหาริย์อนิจจาไม่เกิดขึ้น คุณไม่สามารถติดตั้ง zabbix และคาดหวังให้ทุกอย่างทำงานได้ ไม่มีประโยชน์ที่จะติดตั้ง Grafana และหวังว่าทุกอย่างจะเรียบร้อย เวลาส่วนใหญ่จะใช้เวลาในการจัดการตรวจสอบการทำงานของบริการและการโต้ตอบซึ่งกันและกันตรวจสอบวิธีการทำงานของระบบภายนอก ในความเป็นจริง 90% ของเวลาจะไม่ถูกใช้ไปกับการเขียนสคริปต์ แต่เพื่อการพัฒนาซอฟต์แวร์ และควรได้รับการจัดการโดยทีมงานที่เข้าใจงานของโครงการ
หากในสถานการณ์เช่นนี้ มีบุคคลหนึ่งถูกติดตาม ภัยพิบัติก็จะเกิดขึ้น ซึ่งเป็นสิ่งที่เกิดขึ้นทุกที่

ตัวอย่างเช่น มีบริการหลายอย่างที่สื่อสารระหว่างกันผ่าน Kafka คำสั่งซื้อมาถึงเราส่งข้อความเกี่ยวกับคำสั่งซื้อไปที่คาฟคา มีบริการรับฟังข้อมูลเกี่ยวกับการสั่งซื้อและจัดส่งสินค้า มีบริการรับฟังข้อมูลเกี่ยวกับการสั่งซื้อและส่งจดหมายถึงผู้ใช้ จากนั้นบริการต่างๆ มากมายก็ปรากฏขึ้น และเราเริ่มสับสน

และหากคุณให้ข้อมูลนี้แก่ผู้ดูแลระบบและนักพัฒนาในขั้นตอนที่ยังเหลือเวลาไม่นานก่อนที่จะเผยแพร่ บุคคลนั้นจะต้องเข้าใจโปรโตคอลทั้งหมดนี้ เหล่านั้น. โครงการขนาดนี้ใช้เวลานานพอสมควร และควรคำนึงถึงการพัฒนาระบบด้วย
แต่บ่อยครั้งโดยเฉพาะในสตาร์ทอัพเราจะเห็นว่าการติดตามผลถูกเลื่อนออกไปในภายหลังอย่างไร “ตอนนี้เราจะสร้าง Proof of Concept เราจะเปิดตัวพร้อมกับมัน ปล่อยให้มันพัง - เราพร้อมที่จะเสียสละ แล้วเราจะติดตามมันทั้งหมด” เมื่อ (หรือถ้า) โครงการเริ่มสร้างรายได้ ธุรกิจต้องการเพิ่มคุณสมบัติเพิ่มเติม - เนื่องจากได้เริ่มทำงานแล้ว ดังนั้นจึงจำเป็นต้องเปิดตัวเพิ่มเติม! และคุณมาถึงจุดที่คุณต้องตรวจสอบทุกอย่างก่อนหน้านี้ก่อน ซึ่งใช้เวลาไม่ 1% แต่มากกว่านั้นมาก อย่างไรก็ตาม นักพัฒนาจะต้องมีการตรวจสอบ และง่ายกว่าที่จะให้พวกเขาทำงานกับฟีเจอร์ใหม่ๆ เป็นผลให้มีการเขียนคุณสมบัติใหม่ ทุกอย่างพังทลายและคุณอยู่ในภาวะหยุดชะงักอย่างไม่มีที่สิ้นสุด

แล้วจะติดตามโครงการตั้งแต่เริ่มต้นได้อย่างไร และจะทำอย่างไรหากคุณได้รับโครงการที่ต้องติดตาม แต่คุณไม่รู้ว่าจะเริ่มจากตรงไหน?

ก่อนอื่นคุณต้องวางแผน

การพูดนอกเรื่องโคลงสั้น ๆ: บ่อยครั้งมากที่เริ่มต้นด้วยการตรวจสอบโครงสร้างพื้นฐาน ตัวอย่างเช่น เรามี Kubernetes เริ่มต้นด้วยการติดตั้ง Prometheus ด้วย Grafana ติดตั้งปลั๊กอินสำหรับตรวจสอบ "คิวบ์" ไม่เพียงแต่นักพัฒนาเท่านั้น แต่ผู้ดูแลระบบยังมีแนวทางปฏิบัติที่โชคร้ายดังนี้: “เราจะติดตั้งปลั๊กอินนี้ แต่ปลั๊กอินอาจรู้วิธีดำเนินการ” ผู้คนชอบเริ่มต้นด้วยสิ่งที่เรียบง่ายและตรงไปตรงมา มากกว่าที่การกระทำที่สำคัญ และการตรวจสอบโครงสร้างพื้นฐานเป็นเรื่องง่าย

ขั้นแรก ตัดสินใจว่าคุณต้องการติดตามอะไรและอย่างไร จากนั้นเลือกเครื่องมือ เนื่องจากคนอื่นไม่สามารถคิดแทนคุณได้ และพวกเขาควรทำอย่างไร? คนอื่นคิดกับตัวเองเกี่ยวกับระบบสากล - หรือไม่ได้คิดเลยเมื่อเขียนปลั๊กอินนี้ และเพียงเพราะปลั๊กอินนี้มีผู้ใช้ 5 รายไม่ได้หมายความว่าจะมีประโยชน์ใดๆ บางทีคุณอาจกลายเป็นคนที่ 5001 เพียงเพราะก่อนหน้านี้มีคน 5000 คนอยู่แล้ว

หากคุณเริ่มตรวจสอบโครงสร้างพื้นฐานและแบ็กเอนด์ของแอปพลิเคชันของคุณหยุดตอบสนอง ผู้ใช้ทั้งหมดจะสูญเสียการเชื่อมต่อกับแอปพลิเคชันมือถือ ข้อผิดพลาดจะปรากฏขึ้น พวกเขาจะมาหาคุณแล้วพูดว่า “แอปพลิเคชันใช้งานไม่ได้ คุณมาทำอะไรที่นี่” - “เรากำลังติดตาม” — “คุณจะตรวจสอบได้อย่างไรถ้าคุณไม่เห็นว่าแอปพลิเคชันไม่ทำงาน!”

1. ฉันเชื่อว่าคุณต้องเริ่มการตรวจสอบจากจุดเริ่มต้นของผู้ใช้อย่างแน่นอน หากผู้ใช้ไม่เห็นว่าแอปพลิเคชันกำลังทำงานอยู่ แสดงว่ามันล้มเหลว และระบบติดตามควรแจ้งเตือนเรื่องนี้ก่อน
2. และเมื่อนั้นเราจึงจะสามารถตรวจสอบโครงสร้างพื้นฐานได้ หรือทำแบบคู่ขนานกัน ง่ายกว่าด้วยโครงสร้างพื้นฐาน - ในที่สุดเราก็สามารถติดตั้ง zabbix ได้
3. และตอนนี้คุณต้องไปที่รากของแอปพลิเคชันเพื่อทำความเข้าใจว่าจุดไหนใช้งานไม่ได้

แนวคิดหลักของฉันคือการติดตามผลควรควบคู่ไปกับกระบวนการพัฒนา หากคุณเบี่ยงเบนความสนใจของทีมตรวจสอบไปทำงานอื่น (การสร้าง CI/CD, แซนด์บ็อกซ์, การปรับโครงสร้างโครงสร้างพื้นฐาน) การตรวจสอบจะเริ่มล่าช้าและคุณอาจตามการพัฒนาไม่ทัน (หรือไม่ช้าก็เร็วคุณจะต้องหยุดการพัฒนา)

ทุกอย่างตามระดับ

นี่คือวิธีที่ฉันเห็นการจัดระบบการตรวจสอบ

1) ระดับการสมัคร:

• การตรวจสอบตรรกะทางธุรกิจของแอปพลิเคชัน
• การติดตามตัวชี้วัดด้านสุขภาพของการบริการ
• การตรวจสอบบูรณาการ

2) ระดับโครงสร้างพื้นฐาน:

• การตรวจสอบระดับการเรียบเรียง;
• การตรวจสอบซอฟต์แวร์ระบบ
• การตรวจสอบระดับเหล็ก

3) ระดับการใช้งานอีกครั้ง - แต่เป็นผลิตภัณฑ์ทางวิศวกรรม:

• การรวบรวมและตรวจสอบบันทึกแอปพลิเคชัน
• เอพีเอ็ม;
• การติดตาม

4) การแจ้งเตือน:

• การจัดระบบเตือนภัย
• การจัดระบบหน้าที่
• การจัด “ฐานความรู้” และขั้นตอนการทำงานสำหรับการประมวลผลเหตุการณ์

มันเป็นสิ่งสำคัญ: เราไปถึงการแจ้งเตือนไม่ใช่หลังจากนั้น แต่ทันที! ไม่จำเป็นต้องเริ่มการตรวจสอบและ "ในภายหลัง" เพื่อดูว่าใครจะได้รับการแจ้งเตือน ท้ายที่สุดแล้ว งานในการตรวจสอบคืออะไร: เพื่อทำความเข้าใจว่ามีบางอย่างผิดปกติในระบบตรงไหน และเพื่อให้คนที่เหมาะสมทราบเกี่ยวกับเรื่องนี้ หากคุณปล่อยไว้จนถึงที่สุด คนที่เหมาะสมจะรู้ว่ามีบางอย่างผิดปกติเพียงแต่เรียกว่า “ไม่มีอะไรได้ผลสำหรับเรา”

Application Layer - การตรวจสอบลอจิกทางธุรกิจ

ที่นี่เรากำลังพูดถึงการตรวจสอบข้อเท็จจริงที่ว่าแอปพลิเคชันนั้นใช้งานได้สำหรับผู้ใช้

ระดับนี้ควรทำในระหว่างขั้นตอนการพัฒนา ตัวอย่างเช่น เรามี Prometheus แบบมีเงื่อนไข โดยไปที่เซิร์ฟเวอร์ที่ทำการตรวจสอบ ดึงตำแหน่งข้อมูล และตำแหน่งข้อมูลจะไปตรวจสอบ API

เมื่อมักถูกขอให้ตรวจสอบหน้าแรกเพื่อให้แน่ใจว่าไซต์ใช้งานได้ โปรแกรมเมอร์จะมอบหมายเลขอ้างอิงที่สามารถดึงได้ทุกครั้งที่ต้องการเพื่อให้แน่ใจว่า API นั้นใช้งานได้ และโปรแกรมเมอร์ในขณะนี้ยังคงรับและเขียน /api/test/helloworld
วิธีเดียวที่จะทำให้แน่ใจว่าทุกอย่างใช้งานได้? - เลขที่!

• การสร้างเช็คดังกล่าวถือเป็นหน้าที่ของนักพัฒนาเป็นหลัก การทดสอบหน่วยควรเขียนโดยโปรแกรมเมอร์ที่เขียนโค้ด เพราะหากคุณรั่วไหลไปยังผู้ดูแลระบบ “เพื่อน นี่คือรายการโปรโตคอล API สำหรับฟังก์ชันทั้ง 25 รายการ โปรดตรวจสอบทุกอย่าง!” - ไม่มีอะไรจะได้ผล
• หากคุณพิมพ์คำว่า “hello world” จะไม่มีใครรู้ว่า API ควรและใช้งานได้ การเปลี่ยนแปลง API ทุกครั้งจะต้องนำไปสู่การเปลี่ยนแปลงการตรวจสอบ
• หากคุณประสบปัญหาดังกล่าวอยู่แล้ว ให้หยุดฟีเจอร์และจัดสรรนักพัฒนาที่จะเขียนเช็คเหล่านี้ หรือยอมรับการขาดทุน ยอมรับว่าไม่มีการตรวจสอบสิ่งใดและจะล้มเหลว

เคล็ดลับทางเทคนิค:

• อย่าลืมจัดระเบียบเซิร์ฟเวอร์ภายนอกเพื่อจัดระเบียบการตรวจสอบ - คุณต้องแน่ใจว่าโครงการของคุณสามารถเข้าถึงได้จากโลกภายนอก
• จัดระเบียบการตรวจสอบทั่วทั้งโปรโตคอล API ไม่ใช่แค่ปลายทางแต่ละจุด
• สร้างจุดปลายโพรพร้อมผลการทดสอบ

ชั้นแอปพลิเคชัน - การตรวจสอบตัวชี้วัดสุขภาพ

ตอนนี้เรากำลังพูดถึงการวัดผลด้านสุขภาพภายนอกของการบริการ

เราตัดสินใจว่าเราจะตรวจสอบ "การจัดการ" ทั้งหมดของแอปพลิเคชันโดยใช้การตรวจสอบภายนอก ซึ่งเราเรียกจากระบบการตรวจสอบภายนอก แต่สิ่งเหล่านี้คือ "ตัวจัดการ" ที่ผู้ใช้ "มองเห็น" เราต้องการให้แน่ใจว่าบริการของเราใช้งานได้จริง มีเรื่องราวที่ดีกว่าที่นี่: K8 มีการตรวจสุขภาพ ดังนั้นอย่างน้อย "คิวบ์" ก็สามารถมั่นใจได้ว่าบริการกำลังทำงานอยู่ แต่เช็คครึ่งหนึ่งที่ฉันเคยเห็นมีข้อความเดียวกันว่า "สวัสดีชาวโลก" เหล่านั้น. ดังนั้นเขาจึงดึงออกหนึ่งครั้งหลังจากใช้งาน เขาตอบว่าทุกอย่างเรียบร้อยดี - เท่านั้นเอง และบริการหากมี API ของตัวเอง ก็จะมีจุดเข้าใช้งานจำนวนมากสำหรับ API เดียวกันนั้น ซึ่งจำเป็นต้องได้รับการตรวจสอบด้วย เนื่องจากเราต้องการทราบว่าบริการดังกล่าวใช้งานได้ และเรากำลังติดตามมันอยู่ข้างในอยู่แล้ว

วิธีดำเนินการนี้อย่างถูกต้องในทางเทคนิค: แต่ละบริการเปิดเผยจุดสิ้นสุดเกี่ยวกับประสิทธิภาพปัจจุบัน และในกราฟของ Grafana (หรือแอปพลิเคชันอื่น ๆ) เราจะเห็นสถานะของบริการทั้งหมด

• การเปลี่ยนแปลง API ทุกครั้งจะต้องนำไปสู่การเปลี่ยนแปลงการตรวจสอบ
• สร้างบริการใหม่ทันทีด้วยตัวชี้วัดด้านสุขภาพ
• ผู้ดูแลระบบสามารถมาหานักพัฒนาและขอให้ “เพิ่มคุณสมบัติสองสามอย่างให้ฉันเพื่อที่ฉันจะได้เข้าใจทุกอย่างและเพิ่มข้อมูลเกี่ยวกับสิ่งนี้ลงในระบบการตรวจสอบของฉัน” แต่นักพัฒนามักจะตอบว่า "เราจะไม่เพิ่มอะไรอีกสองสัปดาห์ก่อนการเปิดตัว"
  ให้ผู้จัดการฝ่ายพัฒนาทราบว่าจะมีการสูญเสียดังกล่าวให้ฝ่ายบริหารของผู้จัดการฝ่ายพัฒนาทราบด้วย เพราะเมื่อทุกอย่างพังก็ยังมีคนโทรไปเรียกร้องให้ติดตาม “บริการที่หลุดตลอด” (ค)
• อย่างไรก็ตาม จัดสรรนักพัฒนาให้เขียนปลั๊กอินสำหรับ Grafana ซึ่งจะเป็นความช่วยเหลือที่ดีสำหรับผู้ดูแลระบบ

Application Layer - การตรวจสอบการรวมระบบ

การตรวจสอบการรวมระบบมุ่งเน้นไปที่การตรวจสอบการสื่อสารระหว่างระบบที่มีความสำคัญทางธุรกิจ

ตัวอย่างเช่น มีบริการ 15 รายการที่สื่อสารระหว่างกัน ไซต์เหล่านี้ไม่ได้แยกจากกันอีกต่อไป เหล่านั้น. เราไม่สามารถดึงบริการได้ด้วยตัวเอง รับ /helloworld และเข้าใจว่าบริการกำลังทำงานอยู่ เนื่องจากบริการเว็บสั่งซื้อจะต้องส่งข้อมูลเกี่ยวกับการสั่งซื้อไปยังรถบัส - จากรถบัส บริการคลังสินค้าจะต้องได้รับข้อความนี้และดำเนินการต่อไป และบริการกระจายอีเมล์จะต้องดำเนินการเรื่องนี้ต่อไปด้วยวิธีการใด เป็นต้น

ดังนั้นเราจึงไม่สามารถเข้าใจได้โดยเจาะลึกบริการแต่ละอย่างว่าทุกอย่างใช้งานได้ เพราะเรามีรถบัสที่ทุกสิ่งสื่อสารและโต้ตอบกัน
ดังนั้นขั้นตอนนี้ควรทำเครื่องหมายขั้นตอนของบริการทดสอบสำหรับการโต้ตอบกับบริการอื่นๆ เป็นไปไม่ได้ที่จะจัดระเบียบการตรวจสอบการสื่อสารโดยการตรวจสอบนายหน้าข้อความ หากมีการบริการที่ออกข้อมูลและบริการที่ได้รับข้อมูลนั้น เมื่อตรวจสอบโบรกเกอร์ เราจะเห็นเฉพาะข้อมูลที่บินจากด้านหนึ่งไปอีกด้านหนึ่งเท่านั้น แม้ว่าเราจะจัดการตรวจสอบการโต้ตอบของข้อมูลนี้ภายใน - ที่ผู้ผลิตบางรายโพสต์ข้อมูล, มีคนอ่านมัน, โฟลว์นี้ยังคงไปที่ Kafka - สิ่งนี้ยังคงไม่ให้ข้อมูลแก่เราหากบริการหนึ่งส่งข้อความในเวอร์ชันเดียว แต่บริการอื่นไม่คาดคิดเวอร์ชันนี้จึงข้ามไป เราไม่รู้เรื่องนี้ เนื่องจากบริการจะบอกเราว่าทุกอย่างใช้งานได้

สิ่งที่ฉันแนะนำให้ทำ:

• สำหรับการสื่อสารแบบซิงโครนัส: จุดสิ้นสุดจะส่งคำขอไปยังบริการที่เกี่ยวข้อง เหล่านั้น. เราใช้ตำแหน่งข้อมูลนี้ ดึงสคริปต์ภายในบริการ ซึ่งจะไปยังทุกจุดแล้วบอกว่า "ฉันสามารถดึงไปที่นั่นได้ และดึงไปที่นั่น ฉันสามารถดึงไปที่นั่นได้..."
• สำหรับการสื่อสารแบบอะซิงโครนัส: ข้อความขาเข้า - จุดสิ้นสุดจะตรวจสอบบัสเพื่อดูข้อความทดสอบและแสดงสถานะการประมวลผล
• สำหรับการสื่อสารแบบอะซิงโครนัส: ข้อความขาออก - จุดสิ้นสุดจะส่งข้อความทดสอบไปยังบัส

ตามปกติแล้ว: เรามีบริการที่ส่งข้อมูลลงในบัส เรามาใช้บริการนี้และขอให้คุณแจ้งให้เราทราบเกี่ยวกับความสมบูรณ์ของการบูรณาการ และหากบริการจำเป็นต้องสร้างข้อความที่อื่นเพิ่มเติม (WebApp) ก็จะสร้างข้อความทดสอบนี้ และถ้าเราเรียกใช้บริการในด้าน OrderProcessing ก่อนอื่นจะโพสต์สิ่งที่สามารถโพสต์ได้อย่างอิสระ และหากมีบางสิ่งที่ต้องพึ่งพา ก็จะอ่านชุดข้อความทดสอบจากบัส เข้าใจว่าสามารถประมวลผลได้ รายงานและ หากจำเป็นให้โพสต์เพิ่มเติมและเกี่ยวกับเรื่องนี้เขาพูดว่า - ทุกอย่างโอเค ฉันยังมีชีวิตอยู่

บ่อยครั้งเราได้ยินคำถามที่ว่า “เราจะทดสอบสิ่งนี้กับข้อมูลการต่อสู้ได้อย่างไร?” ตัวอย่างเช่น เรากำลังพูดถึงบริการสั่งซื้อแบบเดียวกัน คำสั่งจะส่งข้อความไปยังโกดังที่สินค้าถูกตัดออกไป: เราไม่สามารถทดสอบสิ่งนี้กับข้อมูลการรบได้ เพราะ "สินค้าของฉันจะถูกตัดออก!" วิธีแก้ไข: วางแผนการทดสอบทั้งหมดนี้ตั้งแต่เริ่มแรก คุณยังมีการทดสอบหน่วยที่สร้างการเยาะเย้ย ดังนั้นให้ทำในระดับลึกกว่านี้โดยจะมีช่องทางการสื่อสารที่ไม่ส่งผลเสียต่อการดำเนินธุรกิจ

ระดับโครงสร้างพื้นฐาน

การตรวจสอบโครงสร้างพื้นฐานเป็นสิ่งที่ได้รับการพิจารณามานานแล้วในการตรวจสอบตัวเอง

• การตรวจสอบโครงสร้างพื้นฐานสามารถและควรเปิดตัวเป็นกระบวนการที่แยกจากกัน
• คุณไม่ควรเริ่มต้นด้วยการตรวจสอบโครงสร้างพื้นฐานสำหรับโปรเจ็กต์ที่กำลังดำเนินอยู่ แม้ว่าคุณต้องการทำเช่นนั้นจริงๆ ก็ตาม นี่คือความเจ็บปวดสำหรับ Devop ทุกคน “ก่อนอื่น ฉันจะตรวจสอบคลัสเตอร์ ฉันจะตรวจสอบโครงสร้างพื้นฐาน” - เช่น ขั้นแรก มันจะตรวจสอบสิ่งที่อยู่ด้านล่าง แต่จะไม่เข้าไปในแอปพลิเคชัน เนื่องจากแอปพลิเคชันเป็นสิ่งที่เข้าใจยากสำหรับ devops มันรั่วไหลมาหาเขา และเขาไม่เข้าใจว่ามันทำงานอย่างไร แต่เขาเข้าใจโครงสร้างพื้นฐานและเริ่มต้นด้วยมัน แต่ไม่ - คุณต้องตรวจสอบแอปพลิเคชันก่อนเสมอ
• อย่าไปเกินจำนวนการแจ้งเตือน เมื่อพิจารณาถึงความซับซ้อนของระบบสมัยใหม่ การแจ้งเตือนต่างๆ ก็มีการบินอยู่ตลอดเวลา และคุณต้องใช้ชีวิตอยู่กับการแจ้งเตือนกลุ่มนี้ และบุคคลที่รับสายเมื่อดูการแจ้งเตือนถัดไปนับร้อยรายการจะตัดสินใจว่า "ฉันไม่ต้องการที่จะคิดเกี่ยวกับมัน" การแจ้งเตือนควรแจ้งเฉพาะเรื่องสำคัญเท่านั้น

ระดับการใช้งานเป็นหน่วยธุรกิจ

ประเด็นสำคัญ:

• เอลค์. นี่คือมาตรฐานอุตสาหกรรม หากคุณไม่ได้รวบรวมบันทึกด้วยเหตุผลบางประการ ให้เริ่มดำเนินการทันที
• เอพีเอ็ม. APM ภายนอกเป็นวิธีปิดการตรวจสอบแอปพลิเคชันอย่างรวดเร็ว (NewRelic, BlackFire, Datadog) คุณสามารถติดตั้งสิ่งนี้ได้ชั่วคราวเพื่อทำความเข้าใจว่าเกิดอะไรขึ้นกับคุณอย่างน้อยที่สุด
• การติดตาม ในไมโครเซอร์วิสหลายสิบรายการ คุณต้องติดตามทุกสิ่ง เนื่องจากคำขอนั้นไม่ได้อยู่เพียงลำพังอีกต่อไป การเพิ่มในภายหลังเป็นเรื่องยากมาก ดังนั้นจึงเป็นการดีกว่าที่จะกำหนดเวลาการติดตามการพัฒนาทันที - นี่คืองานและยูทิลิตี้ของนักพัฒนา หากคุณยังไม่ได้ดำเนินการให้ดำเนินการ! ดูเยเกอร์/ซิปกิ้น

การแจ้งเตือน

• การจัดระบบการแจ้งเตือน: ในเงื่อนไขการตรวจสอบสิ่งต่าง ๆ ควรมีระบบรวมสำหรับการส่งการแจ้งเตือน คุณสามารถทำได้ใน Grafana ในฝั่งตะวันตก ทุกคนใช้ PagerDuty การแจ้งเตือนควรมีความชัดเจน (เช่น มาจากไหน...) และแนะนำให้ควบคุมว่าจะได้รับการแจ้งเตือนเลย
• การจัดระบบหน้าที่: ไม่ควรส่งการแจ้งเตือนถึงทุกคน (ทุกคนจะโต้ตอบในฝูงชน หรือไม่มีใครโต้ตอบ) นักพัฒนายังต้องพร้อมรับสาย: อย่าลืมกำหนดขอบเขตความรับผิดชอบ ให้คำแนะนำที่ชัดเจน และเขียนลงไปว่าใครที่จะโทรในวันจันทร์และวันพุธ และใครที่จะโทรในวันอังคารและวันศุกร์ (ไม่เช่นนั้นพวกเขาจะไม่โทรหาใครเลยแม้แต่ใน กรณีเกิดปัญหาใหญ่ - พวกเขาจะกลัวคุณตื่นหรือรบกวน : โดยทั่วไปคนไม่ชอบโทรไปปลุกคนอื่นโดยเฉพาะตอนกลางคืน) และอธิบายว่าการขอความช่วยเหลือไม่ใช่ตัวบ่งชี้ถึงความไร้ความสามารถ (“ฉันขอความช่วยเหลือ แปลว่าฉันเป็นคนทำงานไม่ดี”) สนับสนุนการขอความช่วยเหลือ
• การจัดระเบียบ "ฐานความรู้" และขั้นตอนการทำงานสำหรับการประมวลผลเหตุการณ์: สำหรับเหตุการณ์ร้ายแรงแต่ละเหตุการณ์ ควรวางแผนการชันสูตรพลิกศพ และควรบันทึกการดำเนินการที่จะแก้ไขเหตุการณ์ไว้เป็นมาตรการชั่วคราว และทำให้เป็นการปฏิบัติที่การเตือนซ้ำ ๆ ถือเป็นบาป พวกเขาจำเป็นต้องได้รับการแก้ไขในงานโค้ดหรือโครงสร้างพื้นฐาน

กองเทคโนโลยี

ลองจินตนาการว่าสแต็คของเราเป็นดังนี้:

• การรวบรวมข้อมูล - Prometheus + Grafana;
• การวิเคราะห์บันทึก - ELK;
• สำหรับ APM หรือ Tracing - Jaeger (Zipkin)

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

ประเด็นทางเทคนิคบางประการที่ฉันเห็นทุกที่เมื่อเร็ว ๆ นี้:

Prometheus ถูกผลักเข้าไปใน Kubernetes - ใครเป็นคนคิดเรื่องนี้ขึ้นมา! หากคลัสเตอร์ของคุณล่ม คุณจะทำอย่างไร? หากคุณมีคลัสเตอร์ที่ซับซ้อนอยู่ภายใน ก็ควรจะมีระบบการตรวจสอบบางอย่างภายในคลัสเตอร์ และบางส่วนภายนอกซึ่งจะรวบรวมข้อมูลจากภายในคลัสเตอร์

ภายในคลัสเตอร์ เรารวบรวมบันทึกและทุกสิ่งทุกอย่าง แต่ระบบติดตามต้องอยู่ภายนอก บ่อยครั้งมากในคลัสเตอร์ที่ติดตั้ง Promtheus ภายใน ยังมีระบบที่ทำการตรวจสอบการทำงานของไซต์ภายนอกอีกด้วย จะเกิดอะไรขึ้นหากการเชื่อมต่อกับโลกภายนอกขาดหายไปและแอปพลิเคชันไม่ทำงาน ปรากฎว่าทุกอย่างเรียบร้อยดีภายใน แต่ไม่ได้ทำให้สิ่งต่าง ๆ ง่ายขึ้นสำหรับผู้ใช้

ผลการวิจัย

• การติดตามการพัฒนาไม่ใช่การติดตั้งโปรแกรมอรรถประโยชน์ แต่เป็นการพัฒนาผลิตภัณฑ์ซอฟต์แวร์ 98% ของการเฝ้าสังเกตในปัจจุบันคือการเขียนโค้ด การเข้ารหัสในบริการ การเข้ารหัสการตรวจสอบภายนอก การตรวจสอบบริการภายนอก แค่นั้นเอง
• อย่าเสียเวลาของนักพัฒนาในการตรวจสอบ: อาจใช้เวลาถึง 30% ของงานของพวกเขา แต่ก็คุ้มค่า
• อย่าเพิ่งกังวลว่าคุณไม่สามารถตรวจสอบบางสิ่งบางอย่างได้ เพราะบางสิ่งมีวิธีการคิดที่แตกต่างไปจากเดิมอย่างสิ้นเชิง คุณไม่ใช่โปรแกรมเมอร์ และงานติดตามก็เป็นหน้าที่ของพวกเขาจริงๆ
• หากโครงการกำลังทำงานอยู่และไม่ได้รับการตรวจสอบ (และคุณเป็นผู้จัดการ) ให้จัดสรรทรัพยากรสำหรับการตรวจสอบ
• หากผลิตภัณฑ์อยู่ในการผลิตแล้ว และคุณเป็นผู้พัฒนาที่ได้รับคำสั่งให้ "ตั้งค่าการตรวจสอบ" - พยายามอธิบายให้ฝ่ายบริหารทราบว่าฉันเขียนทั้งหมดนี้เกี่ยวกับอะไร

นี่เป็นรายงานฉบับขยายในการประชุม Saint Highload++

หากคุณสนใจแนวคิดและความคิดของฉันเกี่ยวกับเรื่องนี้และหัวข้อที่เกี่ยวข้อง คุณสามารถทำได้ที่นี่ อ่านช่อง 🙂

ที่มา: will.com