เมื่อสองปีที่แล้วฉันได้โพสต์ไว้แล้ว การเฟลโอเวอร์อย่างง่ายสำหรับเว็บไซต์ เกี่ยวกับ โอเค. ขณะนี้มีการพัฒนาโครงการอยู่บ้างและฉันก็เผยแพร่ด้วย ซอร์สโค้ดฝั่งเซิร์ฟเวอร์ okrr ภายใต้ ใบอนุญาตแบบเปิดนั่นเป็นเหตุผลที่ฉันตัดสินใจเขียนบทวิจารณ์สั้น ๆ เกี่ยวกับ Habr

ใครบ้างที่อาจสนใจ

สิ่งนี้อาจเป็นที่สนใจของคุณหากคุณทำงานในทีมเล็กๆ หรือคนเดียว คุณไม่มีการตรวจสอบและคุณไม่แน่ใจว่าจำเป็นจริงๆ หรือไม่ ไม่ว่าคุณจะลองใช้การเฝ้าติดตามอย่างจริงจังยอดนิยม “สำหรับหนุ่มใหญ่” บ้างแล้ว แต่มันก็ “ไม่ได้ผล” สำหรับคุณเลย หรือมันทำงานในการกำหนดค่าที่เกือบจะเป็นค่าเริ่มต้นและไม่ได้เปลี่ยนแปลงชีวิตคุณมากนัก และหากคุณไม่ได้วางแผนที่จะจัดสรรพนักงานทั้งหมด (หรือแม้แต่แผนก) เพื่อตรวจสอบแดชบอร์ดการตรวจสอบอย่างน้อยสองสามชั่วโมงต่อวันหรือกำหนดค่า

ทำไม okrr ถึงไม่ธรรมดา

ต่อไป ฉันจะแสดงคุณลักษณะที่น่าสนใจของ okerra ที่ทำให้แตกต่างจากระบบติดตามอื่นๆ

Okerr คือการตรวจสอบแบบไฮบริด

ในระหว่างการมอนิเตอร์ภายใน “เอเจนต์” กำลังทำงานบนเครื่องที่ถูกมอนิเตอร์ ซึ่งจะส่งข้อมูลไปยังเซิร์ฟเวอร์การมอนิเตอร์ (เช่น พื้นที่ว่างในดิสก์) เมื่ออยู่ภายนอก เซิร์ฟเวอร์จะทำการตรวจสอบผ่านเครือข่าย (เช่น การ Ping หรือความพร้อมใช้งานของเว็บไซต์) แต่ละวิธีก็มีข้อจำกัดของตัวเอง Okerr ใช้ทั้งสองตัวเลือก การตรวจสอบภายในเซิร์ฟเวอร์ดำเนินการโดยเอเจนต์ขนาดเล็กมาก (30Kb) หรือสคริปต์และแอปพลิเคชันของคุณเอง และการตรวจสอบเครือข่ายจะดำเนินการผ่านเซ็นเซอร์ Okrr ในประเทศต่างๆ

okrr ไม่ใช่แค่ซอฟต์แวร์ แต่ยังเป็นบริการอีกด้วย

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

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

แน่นอนว่ามีความเสี่ยงที่เซิร์ฟเวอร์ Oker จะไม่สามารถใช้งานได้ซึ่งเป็นเรื่องจริง (ดังที่คุณทราบ 90% ของความน่าเชื่อถือนั้นได้มาอย่างง่ายดายและ "ฟรี" เสมอ 99% โดยใช้ความพยายามขั้นต่ำและเก้าครั้งต่อมาคือ ยากขึ้นอย่างทวีคูณ) แต่ประการแรก โอกาสที่สิ่งนี้จะเกิดขึ้นจะน้อยกว่า และประการที่สอง ปัญหาอาจไม่มีใครสังเกตเห็นได้ก็ต่อเมื่อมันเกิดขึ้นพร้อมกับปัญหาบนเซิร์ฟเวอร์ของเราเท่านั้น หากเรามีความน่าเชื่อถือ 99.9% และคุณมี 99.9% (ตัวเลขที่ไม่สูงเกินไป) โอกาสที่จะเกิดความล้มเหลวที่ตรวจไม่พบคือ 0.1% ของ 0.1% = 0.0001% การเพิ่มสามเก้าให้กับความน่าเชื่อถือของคุณแทบจะไม่ต้องใช้ความพยายามและไม่มีค่าใช้จ่ายเลยถือเป็นเรื่องดีมาก!

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

Okerr เป็นเรื่องเกี่ยวกับตัวบ่งชี้

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

ตัวบ่งชี้ Okrr แต่ละตัวมีเงื่อนไขในตัวที่จะเปลี่ยนสถานะ (ใน Zabbix สิ่งนี้เรียกว่าทริกเกอร์) ตัวอย่างเช่น ค่าเฉลี่ยการโหลดไม่ควรเกิน 2 (แน่นอนว่าสามารถกำหนดค่าได้) และสำหรับการตรวจสอบภายในแต่ละครั้ง (ค่าเฉลี่ยโหลด, ไม่มีดิสก์, ... ) จะมีหน่วยงานเฝ้าระวัง หากเราไม่ได้รับการยืนยันตามเวลาที่กำหนดด้วยเหตุผลบางประการ ระบบจะบันทึกข้อผิดพลาดและส่งการแจ้งเตือน

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

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

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

ความปลอดภัย

คงจะน่าเสียดายถ้าคุณตั้งค่าการตรวจสอบเพื่อเพิ่มความน่าเชื่อถือ แต่ผลที่ตามมาคือคุณถูกโจมตีผ่านเครือข่ายและมีช่องโหว่ของเครือข่ายค่อนข้างมากในเครื่องมือตรวจสอบต่างๆ (Zabbix, Nagios).

ตัวแทน (okerrmod จาก package โอเค เกิดเหตุขัดข้อง) ที่ทำงานบนระบบไม่ใช่เซิร์ฟเวอร์เครือข่าย แต่เป็นไคลเอนต์ ดังนั้นจึงไม่มีพอร์ตเปิดเพิ่มเติมบนเซิร์ฟเวอร์ที่ได้รับการตรวจสอบ ไคลเอนต์ทำงานได้อย่างง่ายดายหลังไฟร์วอลล์หรือ NAT และเป็นเรื่องยากมาก (ฉันจะบอกว่า "เป็นไปไม่ได้") ที่จะแฮ็กผ่านเครือข่าย เนื่องจากโดยหลักการแล้ว มันไม่ฟังเครือข่าย เบ้า.

ครอบคลุมการตรวจสอบเต็มรูปแบบ

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

การตรวจสอบภายนอก

ค่อนข้างเป็นชุดทั่วไป:

ปิง
http สถานะ
ตรวจสอบความถูกต้องและความใหม่ของใบรับรอง SSL (จะแจ้งเตือนหากกำลังจะหมดอายุ)
เปิดพอร์ต TCP และแบนเนอร์ที่อยู่ด้านบน
http grep (หน้า [ต้องไม่] มีข้อความบางอย่าง)
sha1 hash เพื่อตรวจจับการเปลี่ยนแปลงหน้า
DNS (ระเบียน DNS ต้องมีค่าเฉพาะ)
WHOIS (จะเตือนหากโดเมนกำลังจะเสีย)
Antispam DNSBL (โฮสต์ตรวจสอบกับบัญชีดำป้องกันสแปมมากกว่า 50 รายการในคราวเดียว)

การตรวจสอบภายใน

นอกจากนี้ เป็นชุดมาตรฐานที่ค่อนข้างดี (แต่ขยายได้ง่าย)

df (พื้นที่ว่างในดิสก์)
โหลดเฉลี่ย
opentcp (เปิดซ็อกเก็ตการฟัง TCP - จะแจ้งให้ทราบหากมีบางอย่างเริ่มต้นหรือล้มเหลว)
สถานะการออนไลน์ - เพียงสถานะการออนไลน์บนเซิร์ฟเวอร์ จะแจ้งให้ทราบหากมีการเปลี่ยนแปลง (เช่น เซิร์ฟเวอร์โอเวอร์โหลด)
ลูกค้า_ip
dirsize - เราใช้มันเพื่อติดตามเมื่อไฟล์ rootf ของเครื่องเสมือนของเราเกินขนาดที่อนุญาต โดยไม่ต้องมีข้อจำกัดที่เข้มงวด และขนาดของโฮมไดเร็กตอรี่ของผู้ใช้
ว่างเปล่าและไม่ว่างเปล่า - ตรวจสอบไฟล์ที่ควรว่างเปล่า (หรือไม่ว่างเปล่า) ตัวอย่างเช่น บันทึกข้อผิดพลาดของเซิร์ฟเวอร์ okrr ควรว่างเปล่า และหากมีบรรทัดอยู่ในนั้น ฉันจะได้รับการแจ้งเตือนและตรวจสอบ แต่ mail.log บนเมลเซิร์ฟเวอร์ไม่ควรว่างเปล่า (N นาทีหลังจากการหมุนเวียน) และบางครั้งก็ว่างเปล่าสำหรับเราหลังจากการอัปเดตระบบ เมื่อ logrotate ไม่สามารถรีสตาร์ท rsyslog ได้อย่างถูกต้อง
linecount - จำนวนบรรทัดในไฟล์ (เช่น wc -l) เราใช้มันแทนช่องว่างที่นุ่มนวลกว่า เมื่อบันทึกข้อผิดพลาดยังคงเพิ่มขึ้นได้ แต่จะช้าเท่านั้น (เช่น Googlebot เข้าถึงหน้าที่ปิดไปบางหน้า) มีการจำกัด 2 บรรทัดใน 20 นาที หากสูงกว่านี้จะมีการแจ้งเตือน

การตรวจสอบภายในที่น่าสนใจ

หากคุณอ่านแบบ "แนวทแยง" จนถึงจุดนี้ ตอนนี้การอ่านอย่างละเอียดจะน่าสนใจยิ่งขึ้น

การสำรองข้อมูล

มอนิเตอร์การสำรองข้อมูลในไดเร็กทอรี ไฟล์สำรองข้อมูลของเรามีชื่อเช่น “ServerName-20200530.tar.gz” สำหรับแต่ละเซิร์ฟเวอร์ใน okrr ตัวบ่งชี้ ServerName-DATE.tar.gz จะถูกสร้างขึ้น (วันที่จริงจะเปลี่ยนเป็นบรรทัด “DATE”) มีการตรวจสอบการมีอยู่ของข้อมูลสำรองใหม่และขนาดของข้อมูลด้วย (เช่น ต้องไม่น้อยกว่า 90% ของข้อมูลสำรองก่อนหน้า)

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

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

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

maxfilesz

ติดตามขนาดของไฟล์ที่ใหญ่ที่สุด (โดยทั่วไปคือ: /var/log/*) วิธีนี้ช่วยให้คุณตรวจพบปัญหาที่คาดเดาไม่ได้ เช่น รหัสผ่านแบบ Brute Force หรือการส่งสแปมผ่านเซิร์ฟเวอร์

สถานะรัน/รันไลน์

นี่คือโมดูลพร็อกซีที่สำคัญสองโมดูลสำหรับการรันโปรแกรมอื่นบนเซิร์ฟเวอร์ Runstatus รายงานโค้ดการออกโปรแกรมไปยังตัวบ่งชี้ ตัวอย่างเช่น okerr ไม่ (ต้องการ) โมดูลเพื่อตรวจสอบว่าบริการ systemd กำลังทำงานอยู่ ทำได้ผ่าน runstatus (ดูด้านล่าง) Runline - รายงานไปยังเซิร์ฟเวอร์ถึงบรรทัดที่โปรแกรมสร้าง ตัวอย่างเช่น, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" ในการกำหนดค่า Runline บนเซิร์ฟเวอร์ของเราจะสร้างตัวบ่งชี้ชื่อเซิร์ฟเวอร์: อุณหภูมิพร้อมอุณหภูมิโปรเซสเซอร์

SQL

ดำเนินการสืบค้นตัวเลขไปยัง MySQL และรายงานผลลัพธ์ไปยังตัวบ่งชี้ ในกรณีง่ายๆ คุณสามารถทำได้ เช่น "SELECT 1" - ซึ่งจะตรวจสอบว่า DBMS โดยรวมใช้งานได้หรือไม่

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

โปรดทราบว่าไม่สำคัญว่าจะเกิดเหตุการณ์เช่นนี้ขึ้นด้วยสาเหตุที่คาดเดาไม่ได้อะไร:

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

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

ตัวชี้วัดเชิงตรรกะ

อนุญาตให้ใช้นิพจน์บูลีน (ไวยากรณ์ Python) ผ่านโมดูล ตรวจสอบ(บทความเกี่ยวกับฮาเบร). ข้อมูลจากโครงการและตัวบ่งชี้พร้อมสำหรับการแสดงออก ตัวอย่างเช่น ในบทเกี่ยวกับการตรวจสอบ SQL ข้างต้น คุณอาจสังเกตเห็นจุดอ่อน - ในระหว่างวันเราสามารถขายได้ 100 รายการต่อชั่วโมง แต่ในเวลากลางคืน - 20 รายการ ซึ่งเป็นเรื่องปกติ ไม่ใช่ปัญหา ฉันควรทำอย่างไรดี? ตัวบ่งชี้จะตื่นตระหนกตลอดเวลาในเวลากลางคืน

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

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

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

ตัวอย่างข้างต้นไม่ใช่ฟังก์ชันที่ใช้งานได้ดี ไม่ใช่คุณลักษณะบางอย่างที่ต้องเปิดใช้งานและกำหนดค่า Okerra ไม่มีฟังก์ชั่นเหล่านี้ทั้งหมด แต่มีโมดูลลอจิคัลที่ให้คุณใช้ฟังก์ชั่นนี้ (ประมาณในภาษาการเขียนโปรแกรม - หากเรามีตัวดำเนินการทางคณิตศาสตร์เราไม่จำเป็นต้องมีฟังก์ชั่นพิเศษสำหรับการคำนวณภาษีมูลค่าเพิ่ม 20% จากภาษาคุณสามารถทำเองได้ตลอดเวลาเพื่อให้เหมาะกับความต้องการของคุณ)

Logic Indicator อาจเป็นหนึ่งในไม่กี่หัวข้อที่ค่อนข้างซับซ้อนใน okerr แต่ข่าวดีก็คือคุณไม่จำเป็นต้องเชี่ยวชาญมันจนกว่าจะจำเป็น แต่ในขณะเดียวกัน พวกเขาก็ขยายขีดความสามารถอย่างมาก ขณะเดียวกันก็ทำให้ระบบค่อนข้างเรียบง่าย

เพิ่มเช็คของคุณเอง

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

การตรวจสอบค่าแรงขั้นต่ำทำได้ผ่านโมดูล สถานะรัน:

บรรทัดนี้ในการกำหนดค่า สถานะรัน จะแจ้งให้คุณทราบหากจู่ๆ /bin/true ไม่เริ่มต้นหรือส่งคืนสิ่งอื่นที่ไม่ใช่ 0

true_OK=/bin/true

แค่บรรทัดเดียว - และนี่ก็น้อยแล้ว ขยาย ฟังก์ชั่นโอเค

แม้ว่าการตรวจสอบดังกล่าวจะมีคุณค่าอยู่แล้ว: หากเซิร์ฟเวอร์ของคุณล่มกะทันหัน ตัวบ่งชี้ที่เกี่ยวข้องบนเซิร์ฟเวอร์ okerr จะไม่ได้รับการอัปเดตตามเวลาที่กำหนด และหลังจากเวลาผ่านไป การแจ้งเตือนจะปรากฏขึ้น

การตรวจสอบนี้จะแจ้งให้ทราบว่าเซิร์ฟเวอร์ apache2 ขัดข้อง (คุณไม่มีทางรู้เลย...):

apache_OK="systemctl is-active --quiet apache2"

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

ยากกว่า - คุณสามารถเขียนโมดูลของคุณเอง (ในภาษาใดก็ได้) สำหรับ okrrmod ในกรณีที่ง่ายที่สุดจะมีลักษณะดังนี้:

#!/usr/bin/python3

print("STATUS: OK")

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

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

โดยจะอัปเดตตัวบ่งชี้หลายตัวในคราวเดียว (คั่นด้วยบรรทัดว่าง) สร้างตัวบ่งชี้เหล่านั้นหากจำเป็น ระบุรายละเอียดการตรวจสอบ และแท็กที่ทำให้ง่ายต่อการค้นหาตัวบ่งชี้ที่จำเป็นในแดชบอร์ด

มีบอทโทรเลข @OkerrBot. คุณไม่จำเป็นต้องทำให้โทรศัพท์ของคุณยุ่งเหยิงด้วยแอปพลิเคชันแยกต่างหาก (ฉันไม่ชอบสิ่งนั้นสำหรับ Pyaterochka คุณต้องมีแอปพลิเคชันหนึ่งแผนที่สำหรับ Lenta อีกแอปพลิเคชันหนึ่งสำหรับ MTS ที่สามและอื่น ๆ สำหรับทุกคนทุกคนทุกคน) โทรเลขเดียวก็เพียงพอแล้ว คุณสามารถรับการแจ้งเตือนได้ทันที ตรวจสอบสถานะของโครงการ และออกคำสั่งให้ตรวจสอบตัวบ่งชี้ที่เป็นปัญหาทั้งหมดอีกครั้งผ่านทางโทรเลข เราออกจากโรงละคร/เครื่องบิน ไม่ได้จับชีพจรเป็นเวลาสองชั่วโมง เปิดโทรศัพท์ กดปุ่มเดียวในแชทบอท และตรวจสอบให้แน่ใจว่าทุกอย่างเรียบร้อยดี

หน้าสถานะ

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

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

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

ที่นี่ ทบทวนอีก 10 โครงการที่ช่วยให้คุณสามารถสร้างหน้าสถานะได้. นี่คือตัวอย่างลักษณะของหน้าโครงการเหล่านี้ หลาม и Dropbox. หน้าสถานะโอเคร.

ล้มเหลว

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

ความต้องการของระบบต่ำ

สำหรับเซิร์ฟเวอร์ Okrr เราใช้เครื่องที่มี RAM ตั้งแต่ 2Gb สำหรับเซ็นเซอร์เครือข่าย 512Mb ก็เพียงพอแล้ว โดยทั่วไปส่วนของไคลเอนต์เกือบจะเป็นศูนย์ (ถุงพลาสติก โอเค เกิดเหตุขัดข้อง น้ำหนัก 26 Kb แต่ต้องใช้ Python3 และไลบรารีมาตรฐาน) ไคลเอนต์รันจากสคริปต์ cron ดังนั้นจึงมีการใช้หน่วยความจำถาวรเป็นศูนย์ ในบรรดาเครื่องที่เราตรวจสอบ เรามีเซ็นเซอร์ (VPS ราคาถูกสุดๆ พร้อม RAM 512Mb) และ Raspberry Pi เป็นไปได้แม้ว่าจะไม่มีส่วนของไคลเอ็นต์ก็ตาม ส่งการอัปเดตผ่านทาง curl! (ดูด้านล่าง)

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

API และการบูรณาการเข้ากับซอฟต์แวร์ที่เป็นกรรมสิทธิ์

สถาปัตยกรรมที่เรียบง่ายและเปิดกว้าง okrr มีอันที่ค่อนข้างเรียบง่าย APIซึ่งง่ายต่อการทำงานด้วย ต้องการสร้างตัวบ่งชี้ 1000 รายการหรือไม่? หนึ่งเชลล์สคริปต์ที่มี 3-4 บรรทัดจะทำสิ่งนี้ ต้องการกำหนดค่าตัวบ่งชี้ 1000 ตัวใหม่หรือไม่? มันยังง่ายมาก ตัวอย่างเช่น เราต้องการตรวจสอบใบรับรอง HTTPS ทั้งหมดของเราจากเซ็นเซอร์ของรัสเซียอีกครั้ง:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

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

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

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

นี่คือโค้ด (ตัวย่อ) ในบอทโทรเลขของเรา:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

มีไลบรารีสำหรับอัพเดตตัวบ่งชี้จากโปรแกรม Python โอเค เกิดเหตุขัดข้องสำหรับภาษาอื่น ๆ ไม่มีไลบรารี แต่คุณสามารถเรียกสคริปต์ okerrupdate หรือส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์ okerr ได้

Oker ช่วยเราได้อย่างไร

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

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

การตรวจสอบ

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

ใบรับรอง SSL เกือบจะทันทีหลังจากเปิดตัว ให้เข้ารหัส ลูกค้าของเราเริ่มมอบใบรับรอง SSL ฟรีให้กับลูกค้า (ประมาณหนึ่งพันรายการ) และมันก็กลายเป็นนรกสำหรับการบริหาร! ความจริงก็คือไซต์นั้น "ใช้งานได้จริง" ลูกค้าขอให้พวกเขาทำอะไรบางอย่างเป็นระยะ ๆ โปรแกรมเมอร์ก็ทำ พวกเขาสามารถถ่ายโอนไซต์ไปยัง DocumentRoot อื่นได้อย่างอิสระโดยสมบูรณ์ หรือเพิ่มการเขียนซ้ำแบบไม่มีเงื่อนไขให้กับการกำหนดค่าโฮสต์เสมือน โดยปกติแล้ว หลังจากนี้ การต่ออายุใบรับรองอัตโนมัติจะใช้งานไม่ได้ ตอนนี้เราได้เพิ่มโฮสต์ SSL ทั้งหมดลงใน okerr โดยอัตโนมัติผ่านยูทิลิตี้ที่มีประโยชน์อื่น ๆ ของเราจากแพ็คเกจ a2conf. มาเปิดตัวกันเลย a2okerr.py — และหากมีไซต์ใหม่หลายไซต์ปรากฏบนเซิร์ฟเวอร์ ไซต์เหล่านั้นก็จะปรากฏใน okrr โดยอัตโนมัติ หากจู่ๆ ด้วยเหตุผลบางอย่าง ใบรับรองไม่ได้รับการต่ออายุ สามสัปดาห์ก่อนที่ใบรับรองจะหมดอายุ เราก็รู้แล้ว และเราจะหาคำตอบว่าเหตุใดจึงไม่อัปเดต เช่น สุนัขตัวนี้ a2certbot.py จากแพ็คเกจเดียวกัน - ช่วยได้มากในเรื่องนี้ (จะตรวจสอบปัญหาที่เป็นไปได้มากที่สุดทันที - และเขียนสิ่งที่ตรวจสอบได้ดีและจุดที่น่าจะมีปัญหามากที่สุด)

เราตรวจสอบวันหมดอายุของโดเมนทั้งหมดของเรา และเมลเซิร์ฟเวอร์ของเราทั้งหมดที่ส่งเมลก็ได้รับการตรวจสอบจากบัญชีดำที่แตกต่างกันมากกว่า 50 รายการด้วย (และบางครั้งก็ตกอยู่ในนั้น) คุณรู้ไหมว่าเซิร์ฟเวอร์เมลของ Google ก็อยู่ในบัญชีดำเช่นกัน สำหรับการทดสอบตัวเอง เราได้เพิ่ม mail-wr1-f54.google.com ไปยังเซิร์ฟเวอร์ที่ได้รับการตรวจสอบ และยังคงอยู่ในบัญชีดำของ SORBS! (นี่เป็นเรื่องเกี่ยวกับคุณค่าของ "แอนตี้สแปมเมอร์")

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

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

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

แต่มีอีกกรณีหนึ่ง...

คุณรู้ไหมว่าใน Debian 9 (Stretch) ยอดนิยมเช่นแพ็คเกจยอดนิยมเช่น phpmyadmin ยังคงอยู่ (เป็นเวลาหลายเดือน!) อยู่ในสถานะที่มีช่องโหว่? (CVE-2019-6798). เมื่อช่องโหว่เกิดขึ้น เราก็จะปกปิดมันอย่างรวดเร็วด้วยวิธีต่างๆ แต่ฉันตั้งค่าการตรวจสอบหน้าตัวติดตามความปลอดภัยใน okrr เพื่อทราบว่าโซลูชันที่ “สวยงาม” จะออกมาเมื่อใด (ผ่านผลรวม SHA1 ของเนื้อหา) ตัวบ่งชี้ทำให้ฉันกระตุกหลายครั้ง หน้าเปลี่ยนไป แต่อย่างที่คุณเห็น ยังคง (ตั้งแต่เดือนมกราคม 2019!) ไม่ได้ระบุว่าปัญหาได้รับการแก้ไขแล้ว บางทีอาจมีคนรู้ว่าปัญหาคืออะไรที่แพ็คเกจสำคัญดังกล่าวยังคงมีความเสี่ยงมานานกว่าหนึ่งปี?

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

สองสามครั้งมีสถานการณ์ที่ปัญหาเกิดขึ้นแล้วหายไปเอง (อาจจะคุ้นเคยกับทุกคน?) เมื่อคุณสังเกตเห็น เมื่อคุณตรวจสอบ และไม่มีอะไรต้องตรวจสอบ ทุกอย่างทำงานได้ดีอยู่แล้ว แต่แล้วมันก็แตกอีกครั้ง เราเคยประสบเหตุการณ์เช่นนี้เกิดขึ้นกับผลิตภัณฑ์ที่เราอัปโหลดไปยัง Amazon Marketplace (MWS) ในบางจุด สินค้าคงคลังที่โหลดไม่ถูกต้อง (ปริมาณสินค้าไม่ถูกต้องและราคาไม่ถูกต้อง) เราคิดออกแล้ว แต่เพื่อที่จะเข้าใจเรื่องนี้ สิ่งสำคัญคือต้องค้นหาปัญหาทันที น่าเสียดายที่ MWS เช่นเดียวกับบริการอื่นๆ ของ Amazon ช้าเล็กน้อย ดังนั้นจึงมีความล่าช้าอยู่เสมอ แต่ถึงกระนั้น อย่างน้อยเราก็สามารถเข้าใจความเชื่อมโยงระหว่างปัญหากับสคริปต์ที่ทำให้เกิดปัญหาได้คร่าวๆ อย่างน้อย (เราได้ตรวจสอบแล้ว ติดขัดอยู่ ไปยัง okrr และตรวจสอบว่าได้รับการแจ้งเตือนทันที)

เมื่อเร็ว ๆ นี้ กรณีที่น่าสนใจได้ถูกเพิ่มเข้าไปในคอลเลกชันโดยผู้ให้บริการโฮสต์ชาวยุโรปรายใหญ่และมีราคาแพง ซึ่งลูกค้าของเราใช้ ทันใดนั้นเซิร์ฟเวอร์ทั้งหมดของเราก็หายไปจากเรดาร์! ประการแรก ลูกค้าเอง (เร็วกว่า okerra!) สังเกตเห็นว่าไซต์ที่เขาทำงานด้วยไม่ได้เปิดอยู่จึงได้ออกตั๋วเกี่ยวกับเรื่องนี้ แต่ไม่ใช่แค่ไซต์เดียวเท่านั้นที่ล่ม แต่ทั้งหมด! (นาตาชา เราทิ้งทุกอย่างไปแล้ว!) ที่นี่ Okerr เริ่มส่งการพันเท้าแบบยาวพร้อมสัญญาณบ่งชี้ทั้งหมดที่ส่องสว่างสำหรับเขา ตื่นตระหนก ตื่นตระหนก เราวิ่งเป็นวงกลม (เราจะทำอะไรได้อีก) จากนั้นทุกอย่างก็ลุกขึ้น ปรากฎว่ามีการบำรุงรักษาตามปกติในศูนย์ข้อมูล (ทุกๆ หลายปี) และแน่นอนว่าเราควรได้รับคำเตือน แต่มีปัญหาบางอย่างเกิดขึ้นกับพวกเขาและพวกเขาไม่ได้เตือนเรา หัวใจวายมากขึ้น หัวใจวายน้อยลง แต่หลังจากกู้คืนทุกอย่างแล้ว คุณจะต้องตรวจสอบทุกอย่างอีกครั้ง! ฉันจินตนาการไม่ออกว่าฉันจะทำมันด้วยมือของฉันได้อย่างไร Okerr ทดสอบทุกอย่างภายในไม่กี่นาที ปรากฎว่าเซิร์ฟเวอร์ส่วนใหญ่ใช้งานไม่ได้ชั่วคราวแต่ก็ใช้งานได้ บ้างก็บรรทุกของหนักเกินไป แต่ก็ยืนหยัดได้เท่าที่ควร จากการสูญเสียทั้งหมด เราได้สูญเสียข้อมูลสำรองไปสองรายการ ซึ่งตามข้อมูลมงกุฎควรจะถูกสร้างขึ้นและโหลดในขณะที่กล้วยเต็มกำลังดำเนินอยู่ ฉันไม่ได้สนใจที่จะสร้างมันขึ้นมาเลย เพียงหนึ่งวันต่อมาก็มีการแจ้งเตือนว่าทุกอย่างเรียบร้อยดี มีข้อมูลสำรองปรากฏขึ้น ฉันชอบตัวอย่างนี้มาก เพราะ okerr กลับกลายเป็นว่ามีประโยชน์มากในสถานการณ์ที่เราไม่เคยคิดล่วงหน้าด้วยซ้ำ แต่นั่นคือจุดประสงค์ของการติดตาม - เพื่อต่อต้านสิ่งที่คาดเดาไม่ได้

สำหรับเซ็นเซอร์ Okerr เราใช้โฮสติ้งที่ถูกที่สุดเท่าที่จะเป็นไปได้ (โดยที่คุณภาพและความน่าเชื่อถือไม่สำคัญ พวกเขารับประกันซึ่งกันและกัน) เมื่อเร็ว ๆ นี้เราพบโฮสติ้งที่ดีมากและราคาถูกสุด ๆ เกณฑ์มาตรฐานนั้นยอดเยี่ยมมาก แต่... บางครั้งปรากฎว่าการเชื่อมต่อขาออกจากเครื่องเสมือนนั้นทำจาก IP อื่น (ใกล้เคียง) ปาฏิหาริย์ โมดูล Client_ip ด้วย https://diagnostic.opendns.com/myip ได้รับ IP ผิด และจากบันทึกเซิร์ฟเวอร์ของตัวบ่งชี้ เป็นที่ชัดเจนว่าการอัปเดตมาจาก IP ใกล้เคียงนี้ด้วย มาจัดการกับการสนับสนุนตอนนี้ เป็นเรื่องดีที่เราสังเกตเห็นสิ่งนี้ในยามสงบ แต่ตัวอย่างเช่น มักเกิดขึ้นที่การเข้าถึงได้รับการลงทะเบียนตามรายการสีขาวของ IP และหากบางครั้งเซิร์ฟเวอร์กะพริบเช่นนี้ในช่วงเวลาสั้น ๆ คุณสามารถลองจับปัญหานี้ได้เป็นเวลานาน

อีกประการหนึ่ง – เนื่องจากเรากำลังพูดถึงโฮสติ้ง VPS – เรามักจะใช้โฮสติ้งที่มีราคาไม่แพง (hetzner, ovh, scaleway) ฉันชอบมันมากทั้งในแง่ของการวัดประสิทธิภาพและความเสถียร เรายังใช้ Amazon EC2 ที่มีราคาแพงกว่ามากสำหรับโปรเจ็กต์อื่นๆ ด้วย ต้องขอบคุณ okrr ที่ทำให้เราได้รับความคิดเห็นจากข้อมูลของเราเอง พวกเขาทั้งสองล้ม และฉันจะไม่บอกว่าจากการสังเกตของเราเป็นระยะเวลานาน โฮสติ้งราคาถูกอย่าง hetzner กลับกลายเป็นว่ามีเสถียรภาพน้อยกว่า EC2 อย่างเห็นได้ชัด ดังนั้น หากคุณไม่ได้เชื่อมโยงกับคุณสมบัติอื่นๆ ของ Amazon เหตุใดจึงต้องจ่ายเพิ่ม? 🙂

ทำอะไรต่อไป

หากในขั้นตอนนี้ฉันยังไม่ทำให้คุณกลัวจาก Okerr ก็ลองดูสิ! คุณสามารถไปที่ลิงค์นี้โดยตรง บัญชีทดลอง okr (คลิกเลย!) แต่โปรดจำไว้ว่าทุกคนมีบัญชีทดลองเพียงบัญชีเดียวเท่านั้น ดังนั้นหากคุณทำอะไรบางอย่าง บุคคลอื่นในบัญชีเดียวกันอาจรบกวนคุณในเวลาเดียวกัน หรือ (ดีกว่า) ลงทะเบียนผ่านลิงค์ไปที่ นอกสถานที่ - ทุกอย่างเรียบง่ายโดยไม่มี SMS หากคุณไม่ต้องการใช้อีเมลจริงของคุณ คุณสามารถใช้อีเมลแบบใช้แล้วทิ้งได้ เช่น mailinator (ฉันขอแนะนำ getnada.com). บัญชีดังกล่าวอาจถูกลบเมื่อเวลาผ่านไป แต่ก็สามารถทดสอบได้

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

จากเอกสารประกอบ - ก่อนอื่นเลย วิกิพีเดีย ทางฝั่งเซิร์ฟเวอร์และบนไคลเอนต์ (ตกลง wiki). แต่หากมีบางอย่างไม่ชัดเจน โปรดเขียนถึงฝ่ายสนับสนุน (ที่) okrr.com หรือทิ้งตั๋วไว้ - เราจะพยายามแก้ไขทุกอย่างอย่างรวดเร็ว

หากคุณใช้มันอย่างจริงจังและขีดจำกัดที่เพิ่มขึ้นเหล่านี้ยังไม่เพียงพอ เขียนถึงฝ่ายสนับสนุนแล้วเราจะเพิ่มให้ (ฟรี)

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

เราต้องการให้โครงการนี้เริ่มต้นขึ้น เพื่อให้โลกมีความน่าเชื่อถือมากขึ้นต้องขอบคุณเรา ขอบคุณซอฟต์แวร์และบริการฟรีที่ทำให้โลกเป็นมิตรมากขึ้นและมีการพัฒนาแบบไดนามิกมากขึ้น แหล่งที่มาสามารถเก็บไว้ใน GitHub ฟรี สำหรับเมลคุณสามารถใช้ Gmail ฟรีได้ เราใช้ฟรี Freshworks สำหรับการสนับสนุน สำหรับสิ่งนี้ คุณไม่จำเป็นต้องจ่ายค่าเซิร์ฟเวอร์ คุณไม่จำเป็นต้องดาวน์โหลดและกำหนดค่า และคุณไม่จำเป็นต้องแก้ไขปัญหาการดำเนินงานต่างๆ ทุกโปรเจ็กต์ใหม่ ทุกทีมจะมีเมล พื้นที่เก็บข้อมูล และ CRM ทันที และทั้งหมดนี้มีคุณภาพสูงมากและฟรีทันที เราต้องการให้การตรวจสอบเหมือนกัน - บริษัทและโครงการขนาดเล็กสามารถใช้ Oker ได้ฟรี และแม้แต่ในขั้นตอนแรกเกิดและการเติบโตก็มีความน่าเชื่อถือเทียบเท่ากับโครงการที่จริงจังสำหรับผู้ใหญ่

ที่มา: will.com

ภาพรวมของระบบการตรวจสอบแบบไฮบริดของ Okerr