คืนสกู๊ตเตอร์ที่หายไป หรือเรื่องราวของการตรวจสอบ IoT หนึ่งรายการ

ปีที่แล้วเราได้เปิดตัวโครงการส่งเสริมการขายเวอร์ชันนำร่องสำหรับ การเช่าสกู๊ตเตอร์ไฟฟ้าแบบกระจายอำนาจ.

เริ่มแรกโปรเจ็กต์นี้เรียกว่า Road-To-Barcelona ​​ต่อมากลายเป็น Road-To-Berlin (ดังนั้น R2B ในภาพหน้าจอ) และสุดท้ายก็เรียกว่า xRide

แนวคิดหลักของโครงการคือ: แทนที่จะมีบริการรถยนต์หรือสกู๊ตเตอร์ให้เช่าแบบรวมศูนย์ (เรากำลังพูดถึงสกู๊ตเตอร์หรือที่รู้จักในชื่อรถจักรยานยนต์ไฟฟ้า ไม่ใช่คิกสกู๊ตเตอร์/สกู๊ตเตอร์) เราต้องการสร้างแพลตฟอร์มสำหรับการเช่าแบบกระจายอำนาจ เกี่ยวกับความยากลำบากที่เราพบ เขียนไว้ก่อนหน้านี้แล้ว.

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

ผู้ใช้ติดตั้งแอปพลิเคชัน iOS หรือ Android บนโทรศัพท์ เข้าหาสกู๊ตเตอร์ที่เขาชอบ หลังจากนั้นโทรศัพท์และสกู๊ตเตอร์ได้สร้างการเชื่อมต่อแบบเพียร์ทูเพียร์ มีการแลกเปลี่ยน ETH และผู้ใช้สามารถเริ่มการขับขี่ได้โดยเปิดสกู๊ตเตอร์ผ่าน โทรศัพท์. เมื่อสิ้นสุดการเดินทาง ยังสามารถชำระเงินสำหรับการเดินทางโดยใช้ Ethereum จากกระเป๋าเงินของผู้ใช้บนโทรศัพท์ได้อีกด้วย

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

โดยทั่วไปแล้วนักบินของเราจะมีหน้าตาเช่นนี้ ซึ่งเปิดตัวในเดือนกันยายนปีที่แล้วในสองเมืองในเยอรมนี: บอนน์และเบอร์ลิน

จากนั้น วันหนึ่ง ในเมืองบอนน์ ในตอนเช้า ทีมสนับสนุนของเรา (ซึ่งประจำอยู่ที่ไซต์งานเพื่อดูแลรักษาสกู๊ตเตอร์ให้ใช้งานได้) ได้รับการแจ้งเตือนว่า หนึ่งในสกู๊ตเตอร์หายไปอย่างไร้ร่องรอย

จะหาและคืนได้อย่างไร?

ในบทความนี้ ผมจะพูดถึงเรื่องนี้ แต่ก่อนอื่น - เกี่ยวกับวิธีที่เราสร้างแพลตฟอร์ม IoT ของเราเอง และวิธีที่เราตรวจสอบมัน

อะไรและทำไมต้องตรวจสอบ: สกู๊ตเตอร์ โครงสร้างพื้นฐาน สถานีชาร์จ

แล้วเราต้องการติดตามอะไรในโครงการของเรา?

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

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

สกู๊ตเตอร์

สกู๊ตเตอร์ของเราคืออะไร และเราต้องการทราบอะไรเกี่ยวกับสกู๊ตเตอร์เหล่านั้น

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

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

แน่นอนว่ายังจำเป็นต้องตรวจสอบสิ่งที่เกิดขึ้นกับส่วนประกอบฮาร์ดแวร์ของเราด้วย:

• บลูทูธทำงานไหม?
• โมดูล GPS ใช้งานได้จริงหรือไม่
  • นอกจากนี้เรายังมีปัญหากับข้อเท็จจริงที่ว่า GPS สามารถส่งพิกัดที่ไม่ถูกต้องและติดขัดได้ และสิ่งนี้สามารถกำหนดได้โดยการตรวจสอบเพิ่มเติมบนสกู๊ตเตอร์เท่านั้น
    และแจ้งฝ่ายสนับสนุนโดยเร็วที่สุดเพื่อแก้ไขปัญหา

และสุดท้าย: การตรวจสอบซอฟต์แวร์ เริ่มต้นด้วยระบบปฏิบัติการและโปรเซสเซอร์ โหลดเครือข่ายและดิสก์ ลงท้ายด้วยการตรวจสอบโมดูลของเราเองที่เฉพาะเจาะจงมากขึ้นสำหรับเรา (โจโลคอม, พวงกุญแจ).

ฮาร์ดแวร์

ส่วน “เหล็ก” ของเราคืออะไร?

เมื่อคำนึงถึงกรอบเวลาที่สั้นที่สุดที่เป็นไปได้และความจำเป็นในการสร้างต้นแบบอย่างรวดเร็ว เราเลือกตัวเลือกที่ง่ายที่สุดสำหรับการใช้งานและการเลือกส่วนประกอบ - Raspberry Pi
นอกจาก Rpi แล้ว เรายังมีบอร์ดแบบกำหนดเอง (ซึ่งเราพัฒนาและสั่งซื้อจากประเทศจีนเพื่อเร่งกระบวนการประกอบของโซลูชันขั้นสุดท้าย) และชุดส่วนประกอบ - รีเลย์ (สำหรับเปิด/ปิดสกู๊ตเตอร์) เครื่องอ่านการชาร์จแบตเตอรี่ โมเด็ม เสาอากาศ ทั้งหมดนี้บรรจุอยู่ในกล่อง “xRide” แบบพิเศษ

ควรสังเกตว่ากล่องทั้งหมดใช้พลังงานจากแบตเตอรีเพิ่มเติมซึ่งจะใช้พลังงานจากแบตเตอรี่หลักของสกู๊ตเตอร์

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

นักเทียบท่า? ลินุกซ์ธรรมดา? และการปรับใช้

กลับไปที่การตรวจสอบกันดีกว่า Raspberry - เรามีอะไรบ้าง?

สิ่งแรกที่เราต้องการใช้เพื่อเร่งกระบวนการปรับใช้ อัปเดต และจัดส่งส่วนประกอบไปยังอุปกรณ์ทางกายภาพคือ Docker

น่าเสียดายที่เห็นได้ชัดอย่างรวดเร็วว่า Docker บน RPi แม้ว่าจะใช้งานได้ แต่ก็มีค่าใช้จ่ายจำนวนมาก โดยเฉพาะอย่างยิ่งในแง่ของการใช้พลังงาน

ความแตกต่างในการใช้ระบบปฏิบัติการ "ดั้งเดิม" แม้ว่าจะไม่ได้แข็งแกร่งนัก แต่ก็ยังเพียงพอสำหรับเราที่จะระวังความเป็นไปได้ที่จะสูญเสียประจุเร็วเกินไป

เหตุผลที่สองคือหนึ่งในไลบรารีพันธมิตรของเราบน Node.js (sic!) ซึ่งเป็นองค์ประกอบเดียวของระบบที่ไม่ได้เขียนด้วย Go/C/C++

ผู้เขียนห้องสมุดไม่มีเวลาจัดทำเวอร์ชันที่ใช้งานได้ในภาษา "พื้นเมือง" ใด ๆ

ไม่เพียงแต่ตัวโหนดจะไม่ใช่โซลูชันที่หรูหราที่สุดสำหรับอุปกรณ์ประสิทธิภาพต่ำเท่านั้น แต่ตัวไลบรารีเองยังต้องการทรัพยากรอย่างมากอีกด้วย

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

OS

ด้วยเหตุนี้ เราจึงเลือกตัวเลือกที่ง่ายที่สุดเป็น OS อีกครั้ง และใช้ Raspbian (Debian build สำหรับ Pi)

เราเขียนซอฟต์แวร์ทั้งหมดของเราใน Go ดังนั้นเราจึงเขียนโมดูลตัวแทนฮาร์ดแวร์หลักในระบบของเราใน Go ด้วย

เขาเป็นผู้รับผิดชอบในการทำงานกับ GPS, Bluetooth, อ่านการชาร์จ, เปิดสกู๊ตเตอร์ ฯลฯ

ปรับใช้

คำถามเกิดขึ้นทันทีเกี่ยวกับความจำเป็นในการใช้กลไกในการส่งการอัปเดตไปยังอุปกรณ์ (OTA) - ทั้งการอัปเดตตัวแทน/แอปพลิเคชันของเราเอง และการอัปเดตระบบปฏิบัติการ/เฟิร์มแวร์เอง (เนื่องจากตัวแทนเวอร์ชันใหม่อาจต้องมีการอัปเดตเคอร์เนล หรือส่วนประกอบของระบบ ไลบรารี ฯลฯ)

หลังจากวิเคราะห์ตลาดมาอย่างยาวนาน ปรากฎว่ามีวิธีแก้ไขปัญหามากมายในการส่งอัปเดตไปยังอุปกรณ์

ตั้งแต่ยูทิลิตี้ที่ค่อนข้างเรียบง่าย ส่วนใหญ่เป็นการอัปเดต/ดูอัลบูต เช่น swupd/SWUpdate/OSTree ไปจนถึงแพลตฟอร์มเต็มรูปแบบ เช่น Mender และ Balena

ก่อนอื่น เราตัดสินใจว่าเราสนใจโซลูชันแบบครบวงจร ดังนั้นตัวเลือกจึงตกอยู่บนแพลตฟอร์มทันที

มาก บาเลน่า ถูกแยกออกเนื่องจากข้อเท็จจริงที่ว่ามันใช้ Docker ตัวเดียวกันภายใน balenaEngine

แต่ฉันทราบว่าถึงอย่างนั้น เราก็ใช้ผลิตภัณฑ์ของตนอย่างต่อเนื่อง Balena Etcher สำหรับเฟิร์มแวร์แฟลชบนการ์ด SD - ยูทิลิตี้ที่ง่ายและสะดวกอย่างยิ่งสำหรับสิ่งนี้

ดังนั้นในที่สุดทางเลือกก็ล้มลง เมนเดอร์. Mender เป็นแพลตฟอร์มที่สมบูรณ์แบบสำหรับการประกอบ ส่งมอบ และติดตั้งเฟิร์มแวร์

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

อนิจจา กำหนดเวลาที่จำกัดของเราหมายความว่าเราถูกบังคับให้ละทิ้งการใช้ Mender และเลือกอันที่ง่ายกว่า

เบิ้ล

ทางออกที่ง่ายที่สุดในสถานการณ์ของเราคือการใช้ Ansible หนังสือสองสามเล่มก็เพียงพอแล้วสำหรับการเริ่มต้น

สาระสำคัญของพวกเขาคือเราเชื่อมต่อจากโฮสต์ (เซิร์ฟเวอร์ CI) ผ่าน ssh ไปยังราสเบอร์รี่ของเราและเผยแพร่การอัปเดตให้พวกเขา

ในตอนแรก ทุกอย่างเรียบง่าย - คุณต้องอยู่ในเครือข่ายเดียวกันกับอุปกรณ์ การเทข้อมูลทำได้ผ่าน Wi-Fi

ในสำนักงาน มีราสเบอรี่ทดสอบหลายสิบตัวที่เชื่อมต่อกับเครือข่ายเดียวกัน อุปกรณ์แต่ละเครื่องมีที่อยู่ IP แบบคงที่ซึ่งระบุไว้ใน Ansible Inventory ด้วย

Ansible ได้ส่งเอเจนต์การตรวจสอบของเราไปยังอุปกรณ์ปลายทาง

3G / LTE

น่าเสียดายที่กรณีการใช้งาน Ansible นี้สามารถทำงานได้ในโหมดการพัฒนาก่อนที่เราจะมีสกู๊ตเตอร์จริงเท่านั้น

เนื่องจากสกู๊ตเตอร์อย่างที่คุณเข้าใจไม่ได้เชื่อมต่อกับเราเตอร์ Wi-Fi ตัวเดียวและรอการอัปเดตผ่านเครือข่ายอยู่ตลอดเวลา

ในความเป็นจริง สกู๊ตเตอร์ไม่สามารถเชื่อมต่อใดๆ ได้เลย ยกเว้นมือถือ 3G/LTE (และแม้จะไม่ใช่ตลอดเวลาก็ตาม)

สิ่งนี้ทำให้เกิดปัญหาและข้อจำกัดมากมายในทันที เช่น ความเร็วในการเชื่อมต่อต่ำและการสื่อสารที่ไม่เสถียร

แต่สิ่งที่สำคัญที่สุดคือในเครือข่าย 3G/LTE เราไม่สามารถพึ่งพา IP แบบคงที่ที่กำหนดให้กับเครือข่ายเพียงอย่างเดียวได้

ผู้ให้บริการซิมการ์ดบางรายแก้ไขได้บางส่วน มีแม้กระทั่งซิมการ์ดพิเศษที่ออกแบบมาสำหรับอุปกรณ์ IoT ที่มีที่อยู่ IP แบบคงที่ แต่เราไม่สามารถเข้าถึงซิมการ์ดดังกล่าวได้และไม่สามารถใช้ที่อยู่ IP ได้

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

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

VPN

เพื่อแก้ไขปัญหานี้ เราเลือก VPN โดยเฉพาะ Wireguard.

ลูกค้า (สกู๊ตเตอร์) เมื่อเริ่มต้นระบบเชื่อมต่อกับเซิร์ฟเวอร์ VPN และสามารถเชื่อมต่อกับพวกเขาได้ อุโมงค์นี้ใช้เพื่อส่งการอัปเดต

ตามทฤษฎีแล้ว สามารถใช้อุโมงค์เดียวกันในการตรวจสอบได้ แต่การเชื่อมต่อดังกล่าวซับซ้อนกว่าและเชื่อถือได้น้อยกว่าการพุชแบบธรรมดา

ทรัพยากรคลาวด์

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

ที่ให้ไว้

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

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

ภาพสุดท้ายมีลักษณะเช่นนี้

การเลือกสแต็ค

ดังนั้นเราจึงต้องเผชิญกับคำถามในการเลือกสแต็กการตรวจสอบ

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

มีโซลูชั่นการตรวจสอบที่หลากหลาย เริ่มตั้งแต่ระบบที่ครบครันเช่น Nagios, icinga หรือ Zabbix และปิดท้ายด้วยโซลูชั่นสำเร็จรูปสำหรับการจัดการฟลีท

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

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

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

ด้วยเหตุนี้ เราไม่ได้มุ่งมั่นที่จะรวบรวมแพลตฟอร์มการตรวจสอบทั้งหมดด้วยตนเอง แต่กำลังมองหาสแต็ก "สำเร็จรูป" ที่ใช้งานได้ดีที่สุด เพียงแต่มีความสามารถในการกำหนดค่าได้อย่างยืดหยุ่นเท่านั้น

(ข)เอลค์?

วิธีแก้ปัญหาแรกที่ได้รับการพิจารณาจริง ๆ คือสแต็ก ELK ที่รู้จักกันดี
อันที่จริงควรเรียกว่า BELK เพราะทุกอย่างเริ่มต้นด้วย Beats - https://www.elastic.co/what-is/elk-stack

แน่นอนว่า ELK เป็นหนึ่งในโซลูชันที่มีชื่อเสียงและมีประสิทธิภาพมากที่สุดในด้านการตรวจสอบ และยิ่งกว่านั้นในการรวบรวมและประมวลผลบันทึก

เราตั้งใจว่าจะใช้ ELK เพื่อรวบรวมบันทึกและการจัดเก็บตัววัดที่ได้รับจาก Prometheus ในระยะยาว

สำหรับการแสดงภาพคุณสามารถใช้ Grafan

ที่จริงแล้ว สแต็ก ELK ใหม่สามารถรวบรวมหน่วยวัดได้อย่างอิสระ (หน่วยเมตริก) และ Kibana ก็สามารถแสดงหน่วยวัดได้เช่นกัน

แต่ถึงกระนั้น ELK ก็เริ่มเติบโตจากบันทึก และจนถึงตอนนี้ฟังก์ชันการทำงานของหน่วยวัดก็มีข้อเสียร้ายแรงหลายประการ:

• ช้ากว่าโพรมีธีอุสอย่างเห็นได้ชัด
• รวมตัวอยู่ในสถานที่น้อยกว่าโพรมีธีอุสมาก
• เป็นการยากที่จะตั้งค่าการแจ้งเตือนสำหรับพวกเขา
• เมตริกใช้พื้นที่มาก
• การตั้งค่าแดชบอร์ดด้วยหน่วยเมตริกใน Kiban นั้นซับซ้อนกว่าใน Grafan มาก

โดยทั่วไป ตัววัดใน ELK นั้นมีน้ำหนักมากและยังไม่สะดวกเท่ากับโซลูชันอื่นๆ ซึ่งปัจจุบันมีมากกว่าแค่ Prometheus: TSDB, Victoria Metrics, Cortex ฯลฯ เป็นต้น แน่นอนว่า ฉันอยากได้โซลูชันแบบออลอินวันที่สมบูรณ์แบบทันที แต่ในกรณีของเมตริกบีท มีข้อเสียมากเกินไป

และสแต็ก ELK เองก็มีช่วงเวลาที่ยากลำบากหลายประการ:

• มันหนักและบางครั้งก็หนักมากหากคุณรวบรวมข้อมูลจำนวนมากพอสมควร
• คุณต้อง "รู้วิธีทำอาหาร" - คุณต้องปรับขนาด แต่การทำเช่นนี้ไม่ใช่เรื่องเล็กน้อย
• เวอร์ชันฟรีที่แยกออกมา - เวอร์ชันฟรีไม่มีการแจ้งเตือนตามปกติ และในขณะที่เลือกก็ไม่มีการตรวจสอบสิทธิ์

ต้องบอกว่าช่วงนี้จุดสุดท้ายดีขึ้นแล้ว นอกจากนี้ เอาต์พุตใน X-pack โอเพ่นซอร์ส (รวมถึงการรับรองความถูกต้อง) รูปแบบการกำหนดราคาเองก็เริ่มมีการเปลี่ยนแปลง

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

โลกิ - กราฟาน่า - โพรมีธีอุส

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

น่าเสียดายที่ในช่วงเวลาเริ่มต้นโครงการนำร่องการขาย (กันยายน - ตุลาคม 19) โลกิยังอยู่ในเวอร์ชันเบต้า 0.3-0.4 และในขณะที่เริ่มการพัฒนานั้นไม่ถือเป็นโซลูชันด้านการผลิต เลย

ฉันยังไม่มีประสบการณ์ในการใช้ Loki ในโครงการจริงจัง แต่ฉันบอกได้เลยว่า Promtail (ตัวแทนสำหรับรวบรวมบันทึก) ใช้งานได้ดีกับทั้งโลหะเปลือยและพ็อดใน kubernetes

ติ๊ก

บางทีทางเลือกที่มีคุณสมบัติครบถ้วนที่คุ้มค่าที่สุด (เท่านั้น?) สำหรับสแต็ก ELK ในตอนนี้สามารถเรียกว่าสแต็ก TICK เท่านั้น - Telegraf, InfluxDB, Chronograf, Kapacitor

ฉันจะอธิบายส่วนประกอบทั้งหมดด้านล่างโดยละเอียดยิ่งขึ้น แต่แนวคิดทั่วไปคือ:

• Telegraf - ตัวแทนสำหรับรวบรวมเมตริก
• InfluxDB - ฐานข้อมูลเมตริก
• Kapacitor - โปรเซสเซอร์เมตริกแบบเรียลไทม์สำหรับการแจ้งเตือน
• Chronograf - แผงเว็บสำหรับการแสดงภาพ

สำหรับ InfluxDB, Kapacitor และ Chronograf มีแผนภูมิหางเสืออย่างเป็นทางการที่เราใช้ในการปรับใช้

ควรสังเกตว่าใน Influx 2.0 เวอร์ชันล่าสุด (เบต้า) Kapacitor และ Chronograf กลายเป็นส่วนหนึ่งของ InfluxDB และไม่มีแยกกันอีกต่อไป

โทรเลข

โทรเลข เป็นตัวแทนที่มีน้ำหนักเบามากสำหรับการรวบรวมตัวชี้วัดบนเครื่องสถานะ

เขาสามารถตรวจสอบทุกสิ่งได้มากมายตั้งแต่ Nginx ไปยัง
เซิร์ฟเวอร์ Minecraft.

มีข้อดีหลายประการ:

• รวดเร็วและมีน้ำหนักเบา (เขียนด้วยภาษา Go)
  • กินทรัพยากรในปริมาณขั้นต่ำ
• พุชเมตริกตามค่าเริ่มต้น
• รวบรวมตัวชี้วัดที่จำเป็นทั้งหมด
  • ตัวชี้วัดของระบบโดยไม่มีการตั้งค่าใดๆ
  • การวัดฮาร์ดแวร์ เช่น ข้อมูลจากเซ็นเซอร์
  • การเพิ่มตัวชี้วัดของคุณเองนั้นง่ายมาก
• มีปลั๊กอินมากมายนอกกรอบ
• รวบรวมบันทึก

เนื่องจากการวัดแบบพุชเป็นสิ่งจำเป็นสำหรับเรา ข้อดีอื่นๆ ทั้งหมดจึงมีมากกว่าการเพิ่มเติมที่น่าพึงพอใจ

การรวบรวมบันทึกโดยตัวแทนเองก็สะดวกมากเช่นกัน เนื่องจากไม่จำเป็นต้องเชื่อมต่อยูทิลิตี้เพิ่มเติมสำหรับบันทึกการบันทึก

Influx มอบประสบการณ์ที่สะดวกที่สุดในการทำงานกับบันทึกหากคุณใช้ syslog.

โดยทั่วไปแล้ว Telegraf เป็นตัวแทนที่ดีเยี่ยมในการรวบรวมหน่วยวัด แม้ว่าคุณจะไม่ได้ใช้สแต็ก ICK ที่เหลือก็ตาม

หลายๆ คนข้ามวิธีนี้กับ ELK และฐานข้อมูลอนุกรมเวลาอื่นๆ เพื่อความสะดวก เนื่องจากสามารถเขียนการวัดได้เกือบทุกที่

InfluxDB

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

InfluxDB เขียนด้วยภาษา Go และดูเหมือนว่าจะทำงานเร็วกว่ามากเมื่อเทียบกับ ELK บนคลัสเตอร์ของเรา (ไม่ใช่ที่ทรงพลังที่สุด)

ข้อดีที่ยอดเยี่ยมประการหนึ่งของ Influx ก็คือ API ที่สะดวกและครบครันสำหรับการสืบค้นข้อมูล ซึ่งเราใช้อย่างกระตือรือร้น

ข้อเสีย - $$$ หรือการปรับขนาด?

TICK stack มีข้อเสียเปรียบเพียงข้อเดียวที่เราค้นพบ นั่นก็คือ ที่รัก. มากไปกว่านั้น.

เวอร์ชันที่ต้องชำระเงินมีอะไรบ้าง แต่เวอร์ชันฟรีไม่มี?

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

กล่าวคือ คุณสามารถเพิ่มคลัสเตอร์ที่มีความพร้อมใช้งานสูงได้เฉพาะในเท่านั้น รุ่นองค์กร.

หากคุณต้องการ HA ที่ครบถ้วน คุณจะต้องจ่ายเงินหรือใช้ไม้ค้ำยัน มีวิธีแก้ปัญหาสำหรับชุมชนสองสามอย่าง - ตัวอย่างเช่น influxdb-ฮ่า ดูเหมือนเป็นวิธีแก้ปัญหาที่มีความสามารถ แต่มีเขียนไว้ว่าไม่เหมาะสำหรับการผลิตเช่นกัน
ไหลบ่าเข้ามา-พวย - โซลูชันง่ายๆ ที่มีการสูบข้อมูลผ่าน NATS (จะต้องปรับขนาดด้วย แต่สามารถแก้ไขได้)

น่าเสียดายที่ทั้งคู่ดูเหมือนจะถูกทอดทิ้ง - ไม่มีข้อผูกมัดใหม่ ฉันคิดว่าปัญหาคือการเปิดตัว Influx 2.0 เวอร์ชันใหม่ในไม่ช้าซึ่งหลายสิ่งจะแตกต่างออกไป (ไม่มีข้อมูลเกี่ยวกับ ปรับขนาดอยู่ในนั้น)

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

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

วิคตอเรีย เมตริกส์?

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

มีฐานข้อมูลอนุกรมเวลาจำนวนมาก แต่ฐานข้อมูลที่มีแนวโน้มมากที่สุดคือ Victoria Metrics ซึ่งมีข้อดีหลายประการ:

• รวดเร็วและง่ายดายอย่างน้อยก็ตามผลลัพธ์ เกณฑ์มาตรฐาน
• มีเวอร์ชันคลัสเตอร์ซึ่งตอนนี้มีบทวิจารณ์ที่ดีด้วยซ้ำ
  • เธอสามารถแบ่งส่วนได้
• รองรับโปรโตคอล InfluxDB

เราไม่ได้ตั้งใจที่จะสร้างสแต็กแบบกำหนดเองโดยสมบูรณ์โดยอิงจาก Victoria และความหวังหลักก็คือเราสามารถใช้สแต็กนี้แทน InfluxDB แบบดรอปอินได้

น่าเสียดายที่สิ่งนี้เป็นไปไม่ได้ แม้ว่าโปรโตคอล InfluxDB จะได้รับการสนับสนุน แต่ก็ใช้ได้กับการวัดการบันทึกเท่านั้น - มีเพียง Prometheus API เท่านั้นที่พร้อมใช้งาน "ภายนอก" ซึ่งหมายความว่าไม่สามารถตั้งค่า Chronograf บนโปรโตคอลได้

ยิ่งไปกว่านั้น รองรับเฉพาะค่าตัวเลขสำหรับเมตริก (เราใช้ค่าสตริงสำหรับเมตริกที่กำหนดเอง - เพิ่มเติมในส่วนนั้น แผงธุรการ).

ด้วยเหตุผลเดียวกัน VM ไม่สามารถจัดเก็บบันทึกได้เหมือนกับที่ Influx ทำ

นอกจากนี้ ควรสังเกตว่าในขณะที่ค้นหาโซลูชันที่ดีที่สุด Victoria Metrics ยังไม่ได้รับความนิยมมากนัก เอกสารประกอบมีขนาดเล็กกว่ามากและฟังก์ชันการทำงานอ่อนแอลง
(ฉันจำคำอธิบายโดยละเอียดของเวอร์ชันคลัสเตอร์และการแบ่งส่วนไม่ได้)

การเลือกฐาน

ด้วยเหตุนี้ จึงตัดสินใจว่าสำหรับโปรแกรมนำร่อง เรายังคงจำกัดตัวเองอยู่เพียงโหนด InfluxDB เดียว

มีเหตุผลหลักหลายประการสำหรับการเลือกนี้:

• เราชอบฟังก์ชันทั้งหมดของ TICK stack มาก
• เราจัดการเพื่อปรับใช้มันแล้วและมันก็ทำงานได้ดีมาก
• กำหนดเวลากำลังจะหมดลงและเหลือเวลาไม่มากในการทดสอบตัวเลือกอื่นๆ
• เราไม่ได้คาดหวังว่าจะมีภาระหนักขนาดนี้

ในช่วงแรกของการทดลองนำร่องเรามีสกู๊ตเตอร์ไม่มากนัก และการทดสอบระหว่างการพัฒนาไม่พบปัญหาด้านประสิทธิภาพใดๆ

ดังนั้นเราจึงตัดสินใจว่าสำหรับโปรเจ็กต์นี้ โหนด Influx หนึ่งโหนดจะเพียงพอสำหรับเราโดยไม่จำเป็นต้องปรับขนาด (ดูข้อสรุปในตอนท้าย)

เราได้ตัดสินใจเลือกสแต็กและฐานแล้ว - ตอนนี้เกี่ยวกับส่วนประกอบที่เหลือของสแต็ก TICK

คาปาซิเตอร์

Kapacitor เป็นส่วนหนึ่งของ TICK stack ซึ่งเป็นบริการที่สามารถตรวจสอบหน่วยวัดที่เข้าสู่ฐานข้อมูลแบบเรียลไทม์และดำเนินการต่างๆ ตามกฎได้

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

นั่นคือวิธีที่เราใช้มันสำหรับการแจ้งเตือน เราตั้งค่าการแจ้งเตือน Slack เมื่อสกู๊ตเตอร์รุ่นใดรุ่นหนึ่งออฟไลน์ และทำเช่นเดียวกันกับเครื่องชาร์จอัจฉริยะและส่วนประกอบโครงสร้างพื้นฐานที่สำคัญ

ทำให้สามารถตอบสนองต่อปัญหาได้อย่างรวดเร็ว พร้อมรับการแจ้งเตือนว่าทุกอย่างกลับมาเป็นปกติแล้ว

ตัวอย่างง่ายๆ: แบตเตอรี่เพิ่มเติมสำหรับจ่ายไฟให้กับ "กล่อง" ของเราพังหรือหมดพลังงานด้วยเหตุผลบางประการ เพียงติดตั้งแบตเตอรี่ใหม่หลังจากนั้นไม่นานเราควรได้รับการแจ้งเตือนว่าฟังก์ชันการทำงานของสกู๊ตเตอร์ได้รับการกู้คืนแล้ว

ใน Influx 2.0 Kapacitor กลายเป็นส่วนหนึ่งของ DB

โครโนกราฟ

ฉันได้เห็นโซลูชัน UI ที่แตกต่างกันมากมายสำหรับการตรวจสอบ แต่ฉันสามารถพูดได้ว่าในแง่ของฟังก์ชันการทำงานและ UX นั้นไม่มีอะไรเทียบได้กับ Chronograf

เราเริ่มใช้ TICK stack ซึ่งน่าแปลกที่มี Grafan เป็นเว็บอินเตอร์เฟส
ฉันจะไม่อธิบายฟังก์ชั่นของมัน ทุกคนรู้ดีถึงความเป็นไปได้ในการตั้งค่าอะไรก็ตาม

อย่างไรก็ตาม Grafana ยังคงเป็นเครื่องดนตรีสากลโดยสมบูรณ์ ในขณะที่ Chronograf ได้รับการออกแบบมาเพื่อใช้กับ Influx เป็นหลัก

และแน่นอนว่า ด้วยเหตุนี้ Chronograf จึงสามารถมีฟังก์ชันที่ชาญฉลาดหรือสะดวกยิ่งขึ้นได้มาก

บางทีความสะดวกหลักในการทำงานกับ Chronograf ก็คือคุณสามารถดูภายใน InfluxDB ของคุณผ่าน Explore

ดูเหมือนว่า Grafana จะมีฟังก์ชันการทำงานที่เกือบจะเหมือนกัน แต่ในความเป็นจริง การตั้งค่าแดชบอร์ดใน Chronograf สามารถทำได้ด้วยการคลิกเมาส์เพียงไม่กี่ครั้ง (ในขณะเดียวกันก็ดูการแสดงภาพที่นั่น) ในขณะที่ใน Grafana คุณจะยังคงมีไม่ช้าก็เร็ว เพื่อแก้ไขการกำหนดค่า JSON (แน่นอนว่า Chronograf อนุญาตให้อัปโหลด dashas ที่กำหนดค่าด้วยมือของคุณและแก้ไขเป็น JSON หากจำเป็น - แต่ฉันไม่เคยต้องแตะมันเลยหลังจากสร้างมันบน UI)

Kibana มีความสามารถที่สมบูรณ์ยิ่งขึ้นในการสร้างแดชบอร์ดและการควบคุมสำหรับพวกเขา แต่ UX สำหรับการดำเนินการดังกล่าวนั้นซับซ้อนมาก

จะต้องอาศัยความเข้าใจที่ดีในการสร้างแดชบอร์ดที่สะดวกสบาย และแม้ว่าฟังก์ชันการทำงานของแดชบอร์ด Chronograf จะน้อยกว่า แต่การสร้างและปรับแต่งแดชบอร์ดเหล่านั้นก็ง่ายกว่ามาก

แดชบอร์ดเองนอกเหนือจากสไตล์การมองเห็นที่สวยงามแล้ว จริงๆ แล้วไม่แตกต่างจากแดชบอร์ดใน Grafana หรือ Kibana:

นี่คือลักษณะของหน้าต่างแบบสอบถาม:

สิ่งสำคัญที่ควรทราบ เหนือสิ่งอื่นใดคือการทราบประเภทของฟิลด์ในฐานข้อมูล InfluxDB ตัวโครโนกราฟเองก็สามารถช่วยคุณในการเขียน Query หรือการเลือกฟังก์ชันการรวมที่ถูกต้อง เช่น ค่าเฉลี่ย ได้โดยอัตโนมัติ

และแน่นอนว่า Chronograf สะดวกที่สุดในการดูบันทึก ดูเหมือนว่านี้:

ตามค่าเริ่มต้น บันทึก Influx ได้รับการปรับแต่งเพื่อใช้ syslog และดังนั้นจึงมีพารามิเตอร์ที่สำคัญ - ความรุนแรง

กราฟด้านบนมีประโยชน์อย่างยิ่ง โดยคุณจะเห็นข้อผิดพลาดที่เกิดขึ้นบนกราฟและสีจะแสดงอย่างชัดเจนทันทีหากความรุนแรงนั้นสูงกว่า

หลายครั้งที่เราพบจุดบกพร่องที่สำคัญด้วยวิธีนี้ โดยจะเข้าไปดูบันทึกของสัปดาห์ที่แล้วและเห็นจุดสีแดงพุ่งสูงขึ้น

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

เราเปิดใช้งานสิ่งนี้มาระยะหนึ่งแล้ว แต่ในกระบวนการเตรียมนักบินปรากฎว่าเราได้รับข้อผิดพลาดค่อนข้างมาก (รวมถึงระบบเช่นความไม่พร้อมใช้งานของเครือข่าย LTE) ซึ่ง "สแปม" ช่อง Slack ด้วย มากโดยไม่ก่อให้เกิดปัญหาใด ๆ ทั้งสิ้น ประโยชน์มหาศาล

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

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

การรับรอง

เป็นที่น่าสังเกตว่า Chronograf รองรับ OAuth และ OIDC ในการตรวจสอบสิทธิ์

วิธีนี้สะดวกมาก เนื่องจากช่วยให้คุณสามารถแนบเข้ากับเซิร์ฟเวอร์ของคุณและสร้าง SSO เต็มรูปแบบได้อย่างง่ายดาย

ในกรณีของเรา เซิร์ฟเวอร์คือ พวงกุญแจ — มันถูกใช้เพื่อเชื่อมต่อกับการตรวจสอบ แต่เซิร์ฟเวอร์เดียวกันก็ใช้ในการตรวจสอบสกู๊ตเตอร์และคำขอไปยังแบ็คเอนด์ด้วย

“ผู้ดูแลระบบ”

องค์ประกอบสุดท้ายที่ฉันจะอธิบายคือ “แผงผู้ดูแลระบบ” ที่เขียนขึ้นเองใน Vue
โดยพื้นฐานแล้วมันเป็นเพียงบริการแบบสแตนด์อโลนที่แสดงข้อมูลสกู๊ตเตอร์จากฐานข้อมูล ไมโครเซอร์วิส และข้อมูลตัวชี้วัดของเราเองจาก InfluxDB พร้อมๆ กัน

นอกจากนี้ ฟังก์ชันการดูแลระบบหลายอย่างยังถูกย้ายไปที่นั่น เช่น การรีบูตฉุกเฉินหรือการเปิดล็อคสำหรับทีมสนับสนุนจากระยะไกล

มีแผนที่ด้วย ฉันได้กล่าวไปแล้วว่าเราเริ่มต้นด้วย Grafana แทนที่จะเป็น Chronograf เพราะสำหรับแผนที่ Grafana นั้นมีอยู่ในรูปแบบของปลั๊กอินซึ่งเราสามารถดูพิกัดของสกูตเตอร์ได้ น่าเสียดายที่ความสามารถของวิดเจ็ตแผนที่สำหรับ Grafana นั้นมีจำกัดมาก และด้วยเหตุนี้ การเขียนเว็บแอปพลิเคชันของคุณเองพร้อมแผนที่ในเวลาไม่กี่วันจึงง่ายกว่ามาก เพื่อที่จะไม่เพียงแค่เห็นพิกัดในขณะนี้เท่านั้น แต่ยังแสดงด้วย เส้นทางที่สกู๊ตเตอร์ใช้ สามารถกรองข้อมูลบนแผนที่ ฯลฯ (ฟังก์ชันการทำงานทั้งหมดที่เราไม่สามารถกำหนดค่าในแดชบอร์ดแบบธรรมดาได้)

ข้อดีอย่างหนึ่งที่กล่าวไปแล้วของ Influx คือความสามารถในการสร้างหน่วยวัดของคุณเองได้อย่างง่ายดาย
ซึ่งช่วยให้สามารถใช้งานได้หลากหลายสถานการณ์

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

แน่นอนว่าเกณฑ์ที่สำคัญที่สุดสำหรับเราคือสภาพการทำงานของสกู๊ตเตอร์ - อันที่จริง Influx จะตรวจสอบสิ่งนี้เองและแสดงด้วย "ไฟสีเขียว" ในส่วนโหนด

นี้จะกระทำโดยฟังก์ชัน คนตาย — เราใช้มันเพื่อทำความเข้าใจประสิทธิภาพของกล่องของเราและส่งการแจ้งเตือนเดียวกันเหล่านั้นไปยัง Slack

อย่างไรก็ตามเราตั้งชื่อสกูตเตอร์ตามชื่อตัวละครจาก The Simpsons - มันสะดวกมากที่จะแยกแยะพวกมันออกจากกัน

และโดยทั่วไปแล้ววิธีนี้จะสนุกกว่า วลีเช่น "พวก Smithers ตายแล้ว!" ได้ยินอยู่ตลอดเวลา

เมตริกสตริง

สิ่งสำคัญคือ InfluxDB ช่วยให้คุณสามารถจัดเก็บไม่เพียงแต่ค่าตัวเลข เช่นเดียวกับกรณีของ Victoria Metrics

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

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

เป็นผลให้ API การชาร์จยังห่างไกลจากอุดมคติ แต่ปัญหาหลักคือเราไม่สามารถเข้าใจสถานะของพวกเขาได้เสมอไป

นี่คือจุดที่ Influx มาช่วยเหลือ เราเพียงแค่เขียนสถานะสตริงที่มาหาเราในฟิลด์ฐานข้อมูล InfluxDB โดยไม่มีการเปลี่ยนแปลง

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

เมื่อปรากฏในภายหลัง สถานะนี้จะถูกส่งไปหนึ่งครั้งหลังจากขาดการเชื่อมต่อ หากเครื่องชาร์จไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ได้หลังจากพยายามหลายครั้ง

ดังนั้น หากเราใช้เฉพาะชุดค่าคงที่ เราอาจไม่เห็นการเปลี่ยนแปลงเหล่านี้ในเฟิร์มแวร์ในเวลาที่เหมาะสม

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

นอกเหนือจากการวัดตามปกติแล้ว เรายังบันทึกข้อมูลตำแหน่ง GPS ใน InfluxDB อีกด้วย สิ่งนี้มีประโยชน์อย่างเหลือเชื่อในการตรวจสอบตำแหน่งของสกู๊ตเตอร์ในแผงผู้ดูแลระบบของเรา
ในความเป็นจริง เรารู้อยู่เสมอว่าสกู๊ตเตอร์อยู่ที่ไหนและอยู่ที่ไหนในเวลาที่เราต้องการ

สิ่งนี้มีประโยชน์มากสำหรับเราเมื่อเรากำลังมองหาสกู๊ตเตอร์ (ดูข้อสรุปในตอนท้าย)

การตรวจสอบโครงสร้างพื้นฐาน

นอกจากสกู๊ตเตอร์แล้ว เรายังต้องตรวจสอบโครงสร้างพื้นฐานทั้งหมดของเรา (ค่อนข้างกว้างขวาง)

สถาปัตยกรรมทั่วไปมีลักษณะดังนี้:

หากเราเน้นสแต็กการตรวจสอบเพียงอย่างเดียว จะมีลักษณะดังนี้:

สิ่งที่เราต้องการตรวจสอบในระบบคลาวด์คือ:

• ฐานข้อมูล
• พวงกุญแจ
• ไมโครเซอร์วิส

เนื่องจากบริการคลาวด์ทั้งหมดของเราอยู่ใน Kubernetes การรวบรวมข้อมูลเกี่ยวกับสถานะของ Kubernetes จึงเป็นเรื่องดี

โชคดีที่ Telegraf สามารถรวบรวมตัวชี้วัดจำนวนมากเกี่ยวกับสถานะของคลัสเตอร์ Kubernetes ได้ตั้งแต่แกะกล่อง และ Chronograf ก็นำเสนอแดชบอร์ดที่สวยงามสำหรับสิ่งนี้ทันที

เราตรวจสอบประสิทธิภาพของพ็อดและการใช้หน่วยความจำเป็นหลัก ในกรณีที่ล้มจะมีการแจ้งเตือนใน Slack

การติดตามพ็อดใน Kubernetes มีสองวิธี: DaemonSet และ Sidecar
ทั้งสองวิธีมีการอธิบายโดยละเอียด ในโพสต์บล็อกนี้.

เราใช้ Telegraf Sidecar และนอกเหนือจากตัวชี้วัดแล้ว ยังได้รวบรวมบันทึกพ็อดอีกด้วย

ในกรณีของเรา เราต้องแก้ไขบันทึก แม้ว่า Telegraf จะสามารถดึงบันทึกจาก Docker API ได้ แต่เราต้องการให้คอลเลกชันบันทึกที่เหมือนกันกับอุปกรณ์ปลายทางของเราและกำหนดค่า syslog สำหรับคอนเทนเนอร์สำหรับสิ่งนี้ บางทีวิธีแก้ปัญหานี้อาจไม่สวยงาม แต่ก็ไม่มีการตำหนิใดๆ เกี่ยวกับงานของมัน และบันทึกก็แสดงได้ดีใน Chronograf

เฝ้าติดตาม???

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

แม้ว่า Telegraf จะสามารถส่งตัวชี้วัดของตัวเองหรือรวบรวมตัวชี้วัดจากฐานข้อมูล InfluxDB เพื่อส่งไปยัง Influx เดียวกันหรือที่อื่นได้อย่างง่ายดาย

ผลการวิจัย

เราได้ข้อสรุปอะไรจากผลลัพธ์ของโครงการนำร่อง

คุณจะติดตามได้อย่างไร?

ก่อนอื่นเลย TICK stack ตอบสนองความคาดหวังของเราอย่างเต็มที่และให้โอกาสแก่เรามากกว่าที่เราคาดไว้ในตอนแรก

มีฟังก์ชันทั้งหมดที่เราต้องการอยู่แล้ว ทุกสิ่งที่เราทำกับมันทำงานได้โดยไม่มีปัญหา

การปฏิบัติ

ปัญหาหลักของ TICK stack ในเวอร์ชันฟรีคือการขาดความสามารถในการปรับขนาด นี่ไม่ใช่ปัญหาสำหรับเรา

เราไม่ได้รวบรวมข้อมูล/ตัวเลขน้ำหนักบรรทุกที่แน่นอน แต่เรารวบรวมข้อมูลจากสกู๊ตเตอร์ประมาณ 30 คันในแต่ละครั้ง

แต่ละคนรวบรวมตัวชี้วัดมากกว่าสามโหล ในเวลาเดียวกัน ก็มีการรวบรวมบันทึกจากอุปกรณ์ต่างๆ การรวบรวมและส่งข้อมูลเกิดขึ้นทุกๆ 10 วินาที

สิ่งสำคัญคือต้องทราบว่าหลังจากผ่านไปหนึ่งสัปดาห์ครึ่งของนักบิน เมื่อ "แผลในวัยเด็ก" ส่วนใหญ่ได้รับการแก้ไขและปัญหาที่สำคัญที่สุดได้รับการแก้ไขแล้ว เราต้องลดความถี่ในการส่งข้อมูลไปยังเซิร์ฟเวอร์เพื่อ 30 วินาที. สิ่งนี้มีความจำเป็นเนื่องจากการรับส่งข้อมูลบนซิมการ์ด LTE ของเราเริ่มหายไปอย่างรวดเร็ว

ปริมาณการใช้ข้อมูลส่วนใหญ่ถูกใช้โดยบันทึก ตัววัดเอง แม้จะมีช่วงเวลา 10 วินาที แต่ก็ไม่ได้ทำให้เสียเปล่าเลย

ด้วยเหตุนี้ หลังจากผ่านไประยะหนึ่ง เราจึงปิดการใช้งานการรวบรวมบันทึกบนอุปกรณ์โดยสิ้นเชิง เนื่องจากปัญหาเฉพาะนั้นชัดเจนอยู่แล้วแม้ว่าจะไม่มีการเก็บรวบรวมอย่างต่อเนื่องก็ตาม

ในบางกรณี หากยังจำเป็นต้องดูบันทึก เราก็เชื่อมต่อผ่าน WireGuard ผ่าน VPN

นอกจากนี้ ฉันจะเพิ่มเติมด้วยว่าแต่ละสภาพแวดล้อมที่แยกจากกันถูกแยกออกจากกัน และโหลดที่อธิบายไว้ข้างต้นเกี่ยวข้องกับสภาพแวดล้อมการใช้งานจริงเท่านั้น

ในสภาพแวดล้อมการพัฒนา เราได้ยกอินสแตนซ์ InfluxDB แยกต่างหากขึ้นมาซึ่งจะรวบรวมข้อมูลอย่างต่อเนื่องทุกๆ 10 วินาที และเราไม่ได้ประสบปัญหาด้านประสิทธิภาพใดๆ

TICK - เหมาะสำหรับโครงการขนาดเล็กถึงขนาดกลาง

จากข้อมูลนี้ ฉันจะสรุปได้ว่าสแต็ก TICK เหมาะสำหรับโปรเจ็กต์ที่มีขนาดค่อนข้างเล็กหรือโปรเจ็กต์ที่ไม่คาดว่าจะมี HighLoad ใดๆ อย่างแน่นอน

หากคุณไม่มีพ็อดนับพันหรือเครื่องหลายร้อยเครื่อง แม้แต่อินสแตนซ์ InfluxDB ตัวเดียวก็สามารถจัดการโหลดได้ดี

ในบางกรณี คุณอาจพอใจกับ Influx Relay ที่เป็นโซลูชัน High Availability ดั้งเดิม

และแน่นอนว่าไม่มีใครหยุดคุณจากการตั้งค่ามาตราส่วน “แนวตั้ง” และจัดสรรเซิร์ฟเวอร์ที่แตกต่างกันสำหรับตัวชี้วัดประเภทต่างๆ

หากคุณไม่แน่ใจเกี่ยวกับโหลดที่คาดหวังในบริการตรวจสอบ หรือรับประกันว่าจะมี/จะมีสถาปัตยกรรมที่ "หนักมาก" ฉันไม่แนะนำให้ใช้ TICK Stack เวอร์ชันฟรี

แน่นอนว่าวิธีแก้ปัญหาง่ายๆ ก็คือการซื้อ อินฟลักซ์ ดีบี เอ็นเตอร์ไพรส์ - แต่ที่นี่ฉันไม่สามารถแสดงความคิดเห็นได้เนื่องจากตัวฉันเองไม่คุ้นเคยกับรายละเอียดปลีกย่อย นอกจากจะมีราคาแพงมากและไม่เหมาะกับบริษัทขนาดเล็กอย่างแน่นอน

ในกรณีนี้ วันนี้ ฉันขอแนะนำให้มองหาการรวบรวมตัววัดผ่าน Victoria Metrics และบันทึกโดยใช้ Loki

จริงอยู่ ฉันจะจองอีกครั้งว่า Loki/Grafana สะดวกน้อยกว่ามาก (เนื่องจากความสามารถรอบด้านมากกว่า) มากกว่า TICK สำเร็จรูป แต่ฟรี

มันเป็นสิ่งสำคัญ: ข้อมูลทั้งหมดที่อธิบายไว้ที่นี่เกี่ยวข้องกับเวอร์ชัน Influx 1.8 ในขณะนี้ Influx 2.0 กำลังจะออก

แม้ว่าฉันจะไม่มีโอกาสลองใช้ในสภาพการต่อสู้และเป็นการยากที่จะสรุปเกี่ยวกับการปรับปรุง แต่อินเทอร์เฟซก็ดีขึ้นอย่างแน่นอน สถาปัตยกรรมได้รับการปรับปรุงให้ง่ายขึ้น (ไม่มีคาปาซิเตอร์และโครโนกราฟ)
เทมเพลตปรากฏขึ้น (“ฟีเจอร์นักฆ่า” - คุณสามารถติดตามผู้เล่นใน Fortnite และรับการแจ้งเตือนเมื่อผู้เล่นคนโปรดของคุณชนะเกม). แต่น่าเสียดายที่ในขณะนี้เวอร์ชัน 2 ไม่มีสิ่งสำคัญที่เราเลือกเวอร์ชันแรก - ไม่มีการรวบรวมบันทึก

ฟังก์ชั่นนี้จะปรากฏใน Influx 2.0 ด้วย แต่เราไม่พบกำหนดเวลาใด ๆ แม้แต่กำหนดเวลาโดยประมาณก็ตาม

จะไม่สร้างแพลตฟอร์ม IoT ได้อย่างไร (ตอนนี้)

ในท้ายที่สุด หลังจากเปิดตัวโครงการนำร่อง เราก็ได้รวบรวม IoT Stack ที่ครบครันของเราเอง โดยไม่มีทางเลือกอื่นที่เหมาะสมกับมาตรฐานของเรา

อย่างไรก็ตาม ล่าสุดมีให้บริการในเวอร์ชันเบต้าแล้ว OpenBalena — น่าเสียดายที่เธอไม่อยู่ที่นั่นเมื่อเราเริ่มทำโปรเจ็กต์นี้

เราพอใจกับผลลัพธ์ที่ได้และแพลตฟอร์มที่ใช้ Ansible + TICK + WireGuard ที่เราประกอบขึ้นมาเอง แต่วันนี้ ฉันขอแนะนำให้พิจารณา Balena ให้ละเอียดยิ่งขึ้น ก่อนที่จะลองสร้างแพลตฟอร์ม IoT ของคุณเองด้วยตัวเอง

เพราะท้ายที่สุดแล้ว มันก็สามารถทำสิ่งที่เราทำเกือบทั้งหมดได้ และ OpenBalena เป็นบริการฟรีและเป็นโอเพ่นซอร์ส

บริษัทรู้วิธีไม่เพียงแต่ส่งการอัปเดตเท่านั้น แต่ยังรวมถึง VPN ในตัวและปรับแต่งเพื่อใช้ในสภาพแวดล้อม IoT อีกด้วย

และเมื่อไม่นานมานี้ พวกเขาก็ได้เปิดตัว ฮาร์ดแวร์ซึ่งเชื่อมต่อกับระบบนิเวศได้อย่างง่ายดาย

เฮ้ แล้วสกู๊ตเตอร์ที่หายไปล่ะ?

สกู๊ตเตอร์ "ราล์ฟ" จึงหายไปอย่างไร้ร่องรอย

เรารีบวิ่งไปดูแผนที่ใน “แผงผู้ดูแลระบบ” ของเราทันที พร้อมด้วยข้อมูลตัวชี้วัด GPS จาก InfluxDB

ด้วยข้อมูลการตรวจสอบ เราระบุได้อย่างง่ายดายว่าสกู๊ตเตอร์ออกจากลานจอดรถประมาณ 21:00 น. ของวันสุดท้าย ขับรถประมาณครึ่งชั่วโมงไปยังบางพื้นที่ และจอดจนถึงตี 5 ข้างบ้านชาวเยอรมันบางแห่ง

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

อย่างไรก็ตาม เจ้าของบ้านก็รู้สึกประหลาดใจกับสิ่งนี้เช่นกัน เนื่องจากเมื่อคืนเขาได้ขี่สกู๊ตเตอร์คันนี้จากที่ทำงานกลับบ้านจริงๆ

ปรากฎว่าพนักงานช่วยเหลือคนหนึ่งมาถึงในตอนเช้าและหยิบสกู๊ตเตอร์ขึ้นมา เมื่อเห็นว่าแบตเตอรี่เสริมของแบตเตอรี่หมดเกลี้ยงจึงพา (เดินเท้า) ไปที่ลานจอดรถ และแบตเตอรี่เพิ่มเติมล้มเหลวเนื่องจากความชื้น

เราขโมยสกู๊ตเตอร์ไปจากตัวเราเอง อีกอย่างผมไม่รู้ว่าใครและอย่างไรจึงจะแก้ไขปัญหาคดีตำรวจได้ แต่การเฝ้าติดตามก็ดำเนินไปด้วยดี...

ที่มา: will.com