مروری بر سیستم نظارت هیبریدی Okerr

دو سال پیش من قبلاً یک پست گذاشته بودم failover ساده برای یک وب سایت در okerr. اکنون پروژه در حال توسعه است و من هم منتشر کردم کد منبع سمت سرور okerr تحت مجوز باز، به همین دلیل تصمیم گرفتم این بررسی کوتاه را در Habr بنویسم.

مروری بر سیستم نظارت هیبریدی Okerr
[ اندازه کامل ]

به کسانی که ممکن است علاقه داشته باشد

اگر در یک تیم کوچک یا به تنهایی کار می کنید، ممکن است برای شما جالب باشد. شما نظارتی ندارید و مطمئن نیستید که واقعاً به آن نیاز دارید یا خیر. یا برخی از مانیتورینگ‌های جدی محبوب «برای پسران بزرگ» را امتحان کرده‌اید، اما به نوعی برای شما «نبود»، یا در پیکربندی تقریباً پیش‌فرض کار می‌کند و زندگی شما را تغییر چندانی نکرده است. و همچنین - اگر قطعاً قصد ندارید کل کارمند (یا حتی یک بخش) را برای نظارت بر داشبورد نظارت حداقل چند ساعت در روز اختصاص دهید یا آن را پیکربندی کنید.

چرا okerr غیر معمول است

در ادامه ویژگی های جالب okera را نشان خواهم داد که آن را از سایر سیستم های نظارت متمایز می کند.

Okerr یک نظارت ترکیبی است

در حین نظارت داخلی، یک "عامل" بر روی ماشین های نظارت شده در حال اجرا است که داده ها را به سرور نظارت (به عنوان مثال، فضای آزاد دیسک) منتقل می کند. هنگامی که خارجی است، سرور بررسی هایی را از طریق شبکه انجام می دهد (به عنوان مثال، پینگ یا در دسترس بودن وب سایت). هر رویکرد محدودیت های خود را دارد. Okerr از هر دو گزینه استفاده می کند. بررسی های داخل سرورها توسط یک عامل بسیار سبک (30 کیلوبایت) یا اسکریپت ها و برنامه های کاربردی خودتان انجام می شود و بررسی های شبکه از طریق سنسورهای okerr در کشورهای مختلف انجام می شود.

okerr فقط یک نرم افزار نیست، بلکه یک سرویس است

بخش سرور هر نظارتی بزرگ و پیچیده است، نصب و پیکربندی آن دشوار است و به منابع نیاز دارد. با okerr می توانید سرور مانیتورینگ خود را نصب کنید (رایگان و منبع باز است)، یا به سادگی می توانید از بخش مشتری استفاده کنید و از خدمات سرور ما استفاده کنید. همچنین رایگان.

اگر نظارت به شما امکان می دهد کمبود قابلیت اطمینان در سرورها و برنامه ها را جبران کنید و آن را بپوشانید، یک سوال فلسفی مطرح می شود - نگهبان کیست؟ نظارت چگونه به ما در مورد مشکلی می‌گوید اگر خودش بنا به دلایلی، جداگانه یا همراه با سایر منابع شما «مرده» باشد (مثلاً کانال مرکز داده سقوط کرد)؟ هنگام استفاده از سرویس خارجی okerr - این مشکل حل شده است - حتی اگر کل مرکز داده با سرورهای شما بدون برق باشد یا توسط زامبی ها مورد حمله قرار گیرد، یک هشدار دریافت خواهید کرد.

البته، این خطر وجود دارد که خود سرور okerr در دسترس نباشد، این درست است (همانطور که می دانید، 90٪ قابلیت اطمینان همیشه به سادگی و "رایگان" به دست می آید، 99٪ با حداقل تلاش، و هر 99.9 مورد بعدی به طور تصاعدی دشوارتر است). اما اولاً احتمال این اتفاق کمتر است و ثانیاً این مشکل ممکن است تنها در صورتی که با مشکلاتی در سرورهای ما همزمان باشد مورد توجه قرار نگیرد. اگر ما 99.9٪ قابلیت اطمینان داشته باشیم، و شما 0.1٪ (اعداد نه خیلی زیاد) داشته باشید، پس احتمال شکست کشف نشده 0.1٪ از 0.0001٪ = XNUMX٪ است. تقریباً بدون زحمت و بدون هزینه، سه عدد به قابلیت اطمینان خود اضافه کنید، بسیار خوب است!

یکی دیگر از مزایای نظارت به عنوان یک سرویس این است که یک ارائه دهنده هاست یا استودیو وب می تواند سرور okerr را نصب کند و دسترسی به مشتریان را به عنوان یک سرویس اضافی پولی یا رایگان فراهم کند. رقبای شما فقط هاست و وب سایت دارند، اما شما میزبانی قابل اعتماد با نظارت دارید.

Okerr در مورد شاخص ها است

نشانگر یک "لامپ" است. دو حالت اصلی دارد - سبز (OK) یا قرمز (ERR). این پروژه شامل بسیاری از شاخص های گروه بندی شده (به عنوان مثال، توسط سرور) است. در صفحه اصلی پروژه بلافاصله می بینید که یا همه چیز سبز است (و می توانید آن را ببندید) یا چیزی قرمز روشن است و باید اصلاح شود. هنگام انتقال بین این حالت ها، یک هشدار ارسال می شود. روزی یک بار در حالی که آن را راه اندازی می کنید، خلاصه ای از پروژه ارسال می شود.

مروری بر سیستم نظارت هیبریدی Okerr

هر نشانگر okerr دارای شرایط داخلی است که در آن حالت تغییر می کند (در Zabbix به این یک ماشه می گویند). به عنوان مثال، میانگین بار نباید بیشتر از 2 باشد (البته، این قابل تنظیم است). و برای هر چک داخلی (میانگین بار، بدون دیسک، ...) یک نگهبان وجود دارد. اگر به دلایلی تایید موفقیت آمیز را در زمان مقرر دریافت نکردیم، یک خطا ثبت شده و یک هشدار ارسال می شود.

الگوی کار معمول ما این است که صبح‌ها ایمیل‌ها را چک می‌کنیم و خلاصه را در میان نامه‌های دیگر نگاه می‌کنیم (ما آن را در شروع کار برنامه‌ریزی می‌کنیم). اگر همه چیز در آن خوب باشد، کارهای مهم دیگری انجام می دهیم (اما برای ایمن بودن، می توانیم به سرعت به داشبورد okerra نگاه کنیم و مطمئن شویم که همه چیز در این لحظه سبز است). اگر هشداری برسد، واکنش نشان می دهیم.

البته می توان به سادگی نشانگرهای "اطلاعاتی" را نگه داشت (برای مشاهده تصویر شبکه از مانیتورینگ)، اما همه چیز برای ایجاد ساده، آسان و سریع نشانگرهایی به طور خاص برای نظارت خودکار و ارسال هشدار انجام می شود.

هدفی که okerr را برای آن راه اندازی می کنید در هشدارها است، به طوری که می توانید در یک دقیقه یک نشانگر ایجاد کنید، می تواند یک سال "خواب" کند، فقط به روز رسانی ها را بپذیرد، و وقتی یک سال بعد چیزی خراب شد، روشن می شود و می فرستد. یک هشدار . دقیقه ای که یک بار برای ایجاد یک نشانگر صرف کردید نتیجه داد؛ شما بلافاصله قبل از هر کس دیگری در مورد مشکل مطلع شدید. ممکن است قبل از اینکه کسی متوجه شود آن را درست کرده باشند. چیزی که سریع مطرح می شود، افتاده به حساب نمی آید!

امنیت

شرم آور است اگر به خاطر افزایش قابلیت اطمینان، نظارت را راه اندازی کنید، اما در نتیجه، از طریق شبکه مورد حمله قرار می گیرید و آسیب پذیری های شبکه بسیار زیادی در ابزارهای نظارتی مختلف وجود دارد (Zabbix, Nagios).

عامل (okerrmod از بسته okerrupdate) در حال اجرا در سیستم یک سرور شبکه نیست، بلکه یک سرویس گیرنده است. بنابراین، هیچ پورت باز اضافی روی سرور نظارت شده وجود ندارد، مشتری به راحتی در پشت فایروال یا NAT کار می کند و هک کردن شبکه بسیار دشوار است (من می گویم "غیرممکن") ، زیرا در اصل به شبکه گوش نمی دهد. سوکت

پوشش نظارتی کامل

اکنون قانون ما این است که در مورد تمام مشکلات فنی از okerr یاد می گیریم. اگر به طور ناگهانی قانون نقض شد (okerr در مورد وقوع قریب الوقوع آن هشدار نداده است (در صورت امکان) یا قبلاً رخ داده است) - ما چک ها را به okerr اضافه می کنیم.

چک های خارجی

یک مجموعه کاملا معمولی:

  • پینگ
  • وضعیت http
  • بررسی اعتبار و تازگی گواهی SSL (اگر در شرف انقضا باشد هشدار می دهد)
  • پورت TCP و بنر روی آن را باز کنید
  • http grep (صفحه [نباید] حاوی متن خاصی باشد)
  • sha1 برای دریافت تغییرات صفحه هش می کند.
  • DNS (رکورد DNS باید مقدار خاصی داشته باشد)
  • WHOIS (اگر دامنه در شرف خراب شدن باشد هشدار می دهد)
  • Antispam DNSBL (بررسی میزبان در برابر 50+ لیست سیاه آنتی اسپم به طور همزمان)

چک های داخلی

همچنین، یک مجموعه نسبتاً استاندارد (اما به راحتی قابل افزایش است).

  • df (فضای دیسک آزاد)
  • متوسط ​​بار
  • opentcp (پریزهای گوش دادن TCP را باز کنید - در صورت شروع یا خرابی چیزی به شما اطلاع می دهد)
  • آپتایم - فقط زمان کار روی سرور. اگر تغییر کرده باشد (یعنی سرور بیش از حد بارگذاری شده است) اطلاع خواهد داد.
  • client_ip
  • dirsize - ما از آن برای ردیابی زمانی که روت‌ف‌های ماشین مجازی ما از اندازه مجاز فراتر می‌روند، بدون اعمال محدودیت‌های سخت، و اندازه فهرست‌های اصلی کاربر استفاده می‌کنیم.
  • خالی و غیر خالی - نظارت بر فایل هایی که باید خالی (یا خالی نباشند). مثلا لاگ خطای خود سرور okerr خالی باشه و اگه حتی یه خط توش باشه اعلان میگیرم و چک میکنم. اما mail.log در سرور ایمیل نباید خالی باشد (N دقیقه پس از چرخش). و گاهی اوقات پس از به روز رسانی سیستم برای ما خالی بود، زمانی که logrotate نمی توانست rsyslog را به درستی راه اندازی مجدد کند.
  • linecount - تعداد خطوط در فایل (مانند wc -l). ما از آن به عنوان جایگزینی نرم‌تر برای خالی استفاده می‌کنیم، زمانی که گزارش خطا هنوز می‌تواند رشد کند، اما به آرامی (به عنوان مثال، Googlebot برخی از صفحات بسته را مشاهده می‌کند). محدودیت 2 خط در 20 دقیقه وجود دارد. اگر بالاتر باشد، یک هشدار وجود دارد

بررسی های داخلی جالب

اگر تا این مرحله «مورب» خوانده‌اید، اکنون خواندن با دقت بیشتر جالب‌تر خواهد بود.

پشتیبان گیری

پشتیبان‌گیری را در دایرکتوری نظارت می‌کند. فایل های پشتیبان ما دارای نام هایی مانند "ServerName-20200530.tar.gz" هستند. برای هر سرور در okerr، نشانگر ServerName-DATE.tar.gz ایجاد می شود (تاریخ واقعی به خط "DATE" تغییر می کند). وجود یک نسخه پشتیبان تازه و اندازه آن نیز نظارت می شود (مثلاً نمی تواند کمتر از 90٪ از نسخه پشتیبان قبلی باشد).

چه کاری باید انجام شود تا یک نسخه پشتیبان جدید پس از شروع ایجاد و قرار دادن آن در این فهرست، ردیابی شود؟ هیچ چی! این یک رویکرد بسیار راحت است زمانی که شما نیاز به انجام "هیچ کاری" دارید زیرا:

  • انجام "هیچ چیز" بسیار سریع است، در زمان صرفه جویی می کند
  • فراموش کردن "هیچ کاری" سخت است
  • انجام "هیچ" اشتباه، با یک خطا، دشوار است. هیچ چیز قابل اطمینان ترین روش نیست

اگر به طور ناگهانی فایل های پشتیبان تازه ظاهر نشدند، یک هشدار وجود خواهد داشت. به عنوان مثال، اگر یکی از سرورها را غیرفعال کرده باشید و دیگر نیازی به پشتیبان گیری نباشد، باید نشانگر را حذف کنید (از طریق رابط وب یا از پوسته از طریق API).

maxfilesz

اندازه بزرگترین فایل ها را ردیابی می کند (معمولا: /var/log/*). این به شما امکان می دهد مشکلات غیرقابل پیش بینی، به عنوان مثال، گذرواژه های brute force یا ارسال هرزنامه از طریق سرور را پیدا کنید.

runstatus/runline

اینها دو ماژول پروکسی مهم برای اجرای برنامه های دیگر بر روی سرور هستند. Runstatus کد خروج از برنامه را به نشانگر گزارش می دهد. به عنوان مثال، okerr ماژولی برای بررسی اینکه آیا سرویس های systemd در حال اجرا هستند (نیازی ندارد). این کار از طریق runstatus انجام می شود (به زیر مراجعه کنید). Runline - خطی را که برنامه تولید می کند به سرور گزارش می دهد. مثلا، temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" در پیکربندی Runline در سرور ما یک نشانگر نام سرور: دما با دمای پردازنده ایجاد می کند.

SQL

یک پرس و جو عددی را در MySQL اجرا می کند و نتیجه را به نشانگر گزارش می دهد. در یک مورد ساده، می توانید به عنوان مثال "SELECT 1" را انجام دهید - این کار بررسی می کند که DBMS به طور کلی کار می کند.

اما یک برنامه بسیار جالب تر، به عنوان مثال، ردیابی تعداد سفارشات در یک فروشگاه آنلاین است. اگر می دانید که در هر ساعت 100 یا بیشتر سفارش دارید، می توانید حداقل محدودیت را روی 100 یا 80 تنظیم کنید. سپس اگر فروش شما به طور ناگهانی کاهش یابد، یک هشدار دریافت خواهید کرد و می توانید آن را بفهمید.

توجه داشته باشید که مهم نیست به چه دلیل غیرقابل پیش بینی این اتفاق افتاده است:

  • سرور به سادگی در دسترس نیست (بدون برق یا بدون شبکه)، و هشدار از این واقعیت است که نشانگر "فاسد" بود.
  • سرور با چیزی بیش از حد بارگذاری شده است، به کندی کار می کند یا بسته ها از بین می روند، برای کاربران ناخوشایند است و آنها بدون خرید ترک می کنند.
  • سرور در لیست های هرزنامه گنجانده شده است و ایمیل از آن پذیرفته نمی شود، کاربران نمی توانند ثبت نام کنند
  • بودجه کمپین تبلیغاتی تمام شده است، بنرها نمی چرخند.

دلایل مختلفی می تواند وجود داشته باشد و همه آنها را نمی توان از قبل پیش بینی کرد و از نظر فنی ردیابی آن دشوار است. اما می توانید به راحتی پارامتر نهایی (سفارش ها) را کنترل کنید و از آنها تشخیص دهید که وضعیت مشکوک است و مستحق رسیدگی است.

شاخص های منطقی

استفاده از عبارات بولی ( نحو پایتون) را از طریق یک ماژول اجازه می دهد اعتبار بخشیدن(مقاله در Habré). داده های پروژه و شاخص های آن برای بیان در دسترس هستند. به عنوان مثال، در فصل مربوط به بررسی SQL در بالا، ممکن است متوجه یک نقطه ضعف شده باشید - در طول روز می توانیم 100 فروش در ساعت داشته باشیم، اما در شب - 20، و این رایج است، مشکلی نیست. باید چکار کنم؟ نشانگر به طور مداوم در شب وحشت می کند.

شما می توانید دو نشانگر، روز و شب ایجاد کنید. هر دو را "ساکت" کنید (آنها هشدار ارسال نمی کنند). و یک اندیکاتور منطقی ایجاد کنید که باید نشانگر روز قبل از ساعت 20:00 اوکی باشد و بعد از ساعت 20:00 کافی است که نشانگر شب اوکی باشد.

مثال دیگر استفاده از اندیکاتور منطقی است تشدید. به عنوان مثال، یک مدیر پروژه اشتراک هشدارها را لغو می کند (نیازی به انجام این کار ندارد، مدیران باید به مشکلات عادی پاسخ دهند)، اما مشترک یک نشانگر منطقی می شود که اگر هر یک از شاخص های پروژه در مدت زمان تعیین شده اصلاح نشود قرمز می شود.

همچنین امکان تعیین زمان مجاز برای کار به عنوان مثال از ساعت 3 تا 5 صبح وجود دارد. برای ما مهم نیست که سرورها و سایت ها در این مدت از کار بیفتند. اما ساعت 5:00 باید کار کنند. اگر آنها در هر زمان دیگری کار نمی کنند - هشدار. نشانگر منطقی همچنین به شما امکان می دهد افزونگی سرور را در نظر بگیرید. اگر 5 وب سرور دارید، مدیران می توانند در هر زمان 1-2 سرور را خاموش کنند. اما اگر کمتر از 3 از 5 سرور در نبرد وجود داشته باشد، یک هشدار وجود دارد.

مثال‌های بالا توابع oker نیستند، نه برخی از ویژگی‌هایی که باید فعال و پیکربندی شوند. Okerra همه این توابع را ندارد، اما یک ماژول منطقی وجود دارد که به شما امکان می دهد این عملکرد را پیاده سازی کنید (تقریباً مانند یک زبان برنامه نویسی - اگر عملگرهای حسابی داشته باشیم، پس برای محاسبه 20٪ مالیات بر ارزش افزوده نیازی به تابع خاصی نداریم. از زبان، شما همیشه می توانید آن را خودتان انجام دهید و آن را مطابق با نیازهای خود انجام دهید).

Logic Indicator احتمالاً یکی از معدود موضوعات نسبتاً پیچیده در okerr است، اما خبر خوب این است که تا زمانی که نیاز ندارید نیازی به تسلط بر آن ندارید. اما در عین حال، آنها قابلیت ها را تا حد زیادی گسترش می دهند، در حالی که خود سیستم را کاملاً ساده نگه می دارند.

اضافه کردن چک های خود

من واقعاً می خواهم این ایده را به شما منتقل کنم که okerr مجموعه ای از هزاران چک آماده برای همه موارد نیست، بلکه برعکس - اول از همه - یک موتور ساده با توانایی ساده برای ایجاد چک های شخصی شماست. ایجاد چک های خود در okerr یک کار برای هکرها، توسعه دهندگان مشترک سیستم، یا حداقل کاربران پیشرفته okerr نیست، بلکه برای هر مدیری که یک ماه پیش برای اولین بار لینوکس را نصب کرده است، یک کار امکان پذیر است.

بررسی حداقل دستمزدها از طریق ماژول انجام می شود وضعیت اجرا:

این خط در پیکربندی وضعیت اجرا اگر /bin/true ناگهان شروع نشود یا چیزی غیر از 0 برگرداند به شما اطلاع می دهد.

true_OK=/bin/true

فقط یک خط - و ما در حال حاضر کمی هستیم منبسط قابلیت okerr.

حتی چنین بررسی قبلاً ارزش خود را دارد: اگر به طور ناگهانی سرور شما خراب شود، نشانگر مربوطه در سرور okerr به موقع به روز نمی شود و پس از گذشت زمان، یک هشدار ظاهر می شود.

این بررسی به شما اطلاع می دهد که سرور apache2 از کار افتاده است (خب، شما هرگز نمی دانید ...):

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

بنابراین، اگر به هر زبان برنامه نویسی صحبت می کنید، و حداقل می توانید اسکریپت های پوسته بنویسید، می توانید چک های خود را اضافه کنید.

دشوارتر - می توانید (به هر زبانی) ماژول خود را برای okerrmod بنویسید. در ساده ترین حالت به نظر می رسد:

#!/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 به یک سوم، و غیره برای همه، همه، همه نیاز دارید). یک تلگرام کافی است. از طریق تلگرام می توانید بلافاصله هشدار دریافت کنید، وضعیت پروژه را بررسی کنید و دستور بررسی مجدد همه نشانگرهای مشکل دار را بدهید. تئاتر/هواپیما را ترک کردیم، دو ساعت انگشتمان را روی نبض نگه نداشتیم، تلفن را روشن کردیم، یک دکمه را در چت بات فشار دادیم و مطمئن شدیم که همه چیز خوب است.

صفحات وضعیت

امروزه، صفحات وضعیت تقریباً برای هر کسب و کاری که دارای فناوری اطلاعات، نگرش مسئولانه نسبت به قابلیت اطمینان است و با مشتریان/کاربران خود با احترام برخورد می کند، ضروری است.

موقعیتی را تصور کنید - کاربر می خواهد کاری را انجام دهد، اطلاعاتی را مشاهده کند یا سفارش دهد، و چیزی کار نمی کند. او نمی داند چه اتفاقی می افتد، مشکل از طرف چه کسی است و چه زمانی حل خواهد شد. شاید شرکت شما به سادگی یک وب سایت غیر کاربردی داشته باشد؟ یا شش ماه پیش خراب شده و دو سال دیگه درست میشه؟ اما شما باید همین الان یخچال بخرید، از قبل در سبد خرید است... و وقتی شخصی می بیند که مشکلی با شما مشکل دارد (حداقل واضح است که مشکل از طرف او نیست) موضوع کاملاً متفاوت است. مشکل کشف شده است، که شما در حال کار بر روی آن هستید، و شاید حتی زمان تقریبی را برای اصلاح یادداشت کنید. کاربر می تواند در صورت رفع مشکل مشترک شود و اعلان ایمیلی دریافت کند و بتواند کاری را که می خواهد انجام دهد (خرید یخچال).

مروری بر سیستم نظارت هیبریدی Okerr

مشکلات و خرابی ها برای همه اتفاق می افتد. اما کاربران و شرکا به کسانی که در رویکرد خود نسبت به این موضوع شفاف تر و مسئولیت پذیرتر هستند اعتماد بیشتری دارند.

در اینجا این است بررسی 10 پروژه دیگر که به شما امکان ایجاد صفحات وضعیت را می دهد. در اینجا نمونه هایی از ظاهر این صفحات پروژه آورده شده است پــایتــون и Dropbox به. صفحه وضعیت okerr.

غلبه بر خرابی

برای اینکه این مقاله طولانی تر نشود، یک بار دیگر به مقاله قبلی خود مراجعه می کنم - failover ساده برای یک وب سایت . اگر بتوانید یک سرور تکراری بسازید، سپس با استفاده از failover، اساساً زمان طولانی از کار نخواهید داشت - به محض اینکه مشکلی شناسایی شود، کاربران به طور خودکار به یک سرور پشتیبان کار هدایت می شوند. و به نظر من این یک ویژگی بسیار جالب و روشن است که به ندرت در هر جایی در دسترس است.

سیستم مورد نیاز پایین

برای سرورهای okerr، ما از ماشین‌هایی با رم 2 گیگابایتی استفاده می‌کنیم. برای سنسورهای شبکه، حتی 512 مگابایت کافی است. بخش مشتری به طور کلی تقریباً صفر است. (کیسه پلاستیکی okerrupdate 26 کیلوبایت وزن دارد، اما به Python3 و کتابخانه های استاندارد نیاز دارد). کلاینت از یک اسکریپت cron اجرا می شود، بنابراین مصرف حافظه دائمی آن صفر است. در میان دستگاه‌هایی که ما نظارت کردیم، سنسور (VPS فوق‌العاده ارزان با 512 مگابایت رم) و Raspberry Pi داریم. حتی بدون بخش مشتری نیز امکان پذیر است ارسال به روز رسانی از طریق curl! (پایین را ببینید)

با در نظر گرفتن این - okerr، احتمالا رایگان ترین سیستم مانیتورینگ از سیستم های موجود، زیرا حتی برای استفاده از یک سیستم منبع باز رایگان دیگر مانند Zabbix یا Nagios، باید منابع (سرور) را به آن اختصاص دهید، و این قبلاً پول است. علاوه بر این، برخی از تعمیر و نگهداری سرور هنوز مورد نیاز است. با okerr می توان این قسمت را حذف کرد. یا مجبور نیستید آن را حذف کنید و از سرور خود استفاده کنید، بسته به آنچه که بیشتر دوست دارید.

API و ادغام در نرم افزار اختصاصی

معماری ساده و باز. okerr یک روش بسیار ساده دارد 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/

می توانید نشانگرها را مستقیماً از برنامه خود به روز کنید. به عنوان مثال، ارسال سیگنال های ضربان قلب به طوری که okerr بداند در حال اجرا است و در صورت تصادف یا یخ زدن، زنگ هشدار را به صدا در می آورد. به هر حال، مؤلفه‌های 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))

کتابخانه ای برای به روز رسانی شاخص ها از برنامه های پایتون وجود دارد okerrupdate، برای هر زبان دیگری کتابخانه ای وجود ندارد، اما می توانید اسکریپت okerrupdate را فراخوانی کنید یا یک درخواست HTTP به سرور okerr ارسال کنید.

چگونه okerr به ما کمک می کند

اوکر زندگی ما را تغییر داد. در واقع. شاید سیستم مانیتورینگ دیگری بتواند همین کار را انجام دهد، اما کار با okerr برای ما آسان و ساده است و تمام عملکردهایی را که ما نیاز داشتیم را دارد (ما آنچه را که نداشت اضافه کردیم). به هر حال، اگر برخی از ویژگی ها کم است، بپرسید و من آنها را اضافه می کنم (قول نمی دهم، اما می خواهم okerr بهترین سیستم نظارت برای پروژه های کوچک و متوسط ​​باشد). یا بهتر است خودتان آن را اضافه کنید - آسان است.

ما موفق شدیم با این اصل زندگی کنیم "در مورد همه مشکلات از کرا بیاموزیم." اگر به طور ناگهانی مشکلی پیش آمد که ما از okerr یاد نگرفتیم، یک چک به okerr اضافه می کنیم. (در این مورد، منظور من از "ما" ما به عنوان کاربران سیستم است، نه توسعه دهندگان مشترک). در ابتدا این امر رایج بود، اما اکنون بسیار نادر شده است.

نظارت

ما از طریق okerr اندازه های گزارش را در همه سرورها نظارت می کنیم. البته خواندن متفکرانه هر خط سیاهه با چشم غیرممکن است، اما به سادگی نظارت بر نرخ رشد در حال حاضر چیزهای زیادی می دهد. از این طریق، ما ارسال هرزنامه و جستجوهای رمز عبور بی رحمانه را کشف کردیم، و هنگامی که برخی از برنامه ها "دیوانه می شوند"، چیزی برای آنها کار نمی کند و آنها آن را دوباره و دوباره تکرار می کنند (هر بار چند خط به گزارش اضافه می کنند. ).

گواهینامه های SSL تقریبا بلافاصله پس از راه اندازی رمزگذاری کنید مشتری ما شروع به ارائه گواهینامه های SSL رایگان به مشتریان خود کرد (حدود هزار نفر از آنها). و معلوم شد که فقط جهنم برای مدیریت است! واقعیت این است که سایت ها "زنده" هستند، مشتریان به طور دوره ای از آنها می خواهند کاری انجام دهند، برنامه نویسان آن را انجام می دهند. آنها می توانند بطور کامل آزادانه سایت را به عنوان مثال به DocumentRoot دیگری منتقل کنند. یا یک Rewrite بدون قید و شرط به پیکربندی هاست مجازی اضافه کنید. طبیعتاً پس از این، تمدید خودکار گواهینامه ها خراب می شود. اکنون ما همه میزبان های SSL را به طور خودکار از طریق یکی دیگر از ابزارهای مفید خود از بسته به okerr اضافه کرده ایم a2conf. فقط راه اندازی کنیم a2okerr.py - و اگر چندین سایت جدید روی سرور ظاهر شوند، به طور خودکار در okerr ظاهر می شوند. اگر به طور ناگهانی به دلایلی گواهی تمدید نشد، سه هفته قبل از انقضای گواهی، ما در جریان هستیم و متوجه خواهیم شد که چرا به روز نمی شود، چنین سگی. a2certbot.py از همان بسته - در این مورد بسیار کمک می کند (فورا محتمل ترین مشکلات را بررسی می کند - و آنچه را که بررسی شده است به خوبی می نویسد و به احتمال زیاد در کجا مشکل وجود دارد).

ما تاریخ انقضای همه دامنه های خود را کنترل می کنیم. و همه سرورهای ایمیل ما که نامه می فرستند نیز در برابر بیش از 50 لیست سیاه مختلف بررسی می شوند. (و گاه در آنها می افتند). راستی، آیا می دانستید که سرورهای ایمیل گوگل نیز در لیست سیاه قرار دارند؟ فقط برای خودآزمایی، mail-wr1-f54.google.com را به سرورهای نظارت شده اضافه کردیم و هنوز در لیست سیاه SORBS است! (این در مورد ارزش "ضد هرزنامه" است)

پشتیبان گیری - قبلاً در بالا نوشتم که نظارت بر آنها با okerr چقدر آسان است. اما ما هم آخرین نسخه‌های پشتیبان را روی سرورمان نظارت می‌کنیم و هم (با استفاده از یک ابزار مجزا که از okerr استفاده می‌کند) پشتیبان‌هایی را که در Amazon Glacier آپلود می‌کنیم. و بله، مشکلات هر از گاهی پیش می آید. جای تعجب نیست که آنها تماشا می کردند.

ما از نشانگر تشدید استفاده می کنیم. این نشان می دهد که اگر برخی از مشکلات برای مدت طولانی رفع نشده است. و من خودم وقتی بعضی از مشکلات را حل می کنم، گاهی اوقات می توانم آنها را فراموش کنم. تشدید یک یادآوری خوب است، حتی اگر خودتان را زیر نظر داشته باشید.

در مجموع، من معتقدم که کیفیت کار ما یک مرتبه افزایش یافته است. تقریباً هیچ تعطیلی وجود ندارد (یا مشتری وقت ندارد به آن توجه کند. فقط خس!)، در حالی که میزان کار کمتر شده و شرایط کار آرامتر شده است. ما از کارهای اضطراری با وصله سوراخ با نوار به سمت کارهای آرام و سنجیده حرکت کرده ایم، زمانی که بسیاری از مشکلات از قبل پیش بینی شده است و زمان برای جلوگیری از آنها وجود دارد. حتی مشکلاتی که اتفاق افتاده نیز رفع آنها آسانتر شده است: اولاً، ما قبل از وحشت مشتریان از آنها مطلع می شویم و ثانیاً، اغلب اتفاق می افتد که مشکل به کار اخیر مربوط می شود (در حالی که من یک کار را انجام می دادم، کار دیگری را شکستم) - بنابراین داغ است، مقابله با آن برای ردپاها آسان تر است.

اما یک مورد دیگر وجود داشت ...

آیا می دانستید که در Debian 9 محبوب (Stretch) چنین بسته محبوبی مانند phpmyadmin هنوز (برای چندین ماه!) در وضعیت آسیب پذیری قرار دارد؟ (CVE-2019-6798). وقتی آسیب پذیری ظاهر شد، ما به سرعت آن را به روش های مختلف پوشش دادیم. اما من نظارت بر صفحه ردیاب امنیتی را در okerr تنظیم کردم تا بدانم چه زمانی یک راه حل "زیبا" ارائه می شود (از طریق جمع SHA1 محتوا). نشانگر چندین بار من را تکان داد، صفحه تغییر کرد، اما همانطور که می بینید، هنوز (از ژانویه 2019!) نشان نمی دهد که مشکل حل شده است. شاید، اتفاقا، کسی می داند مشکل چیست که چنین بسته مهمی هنوز بیش از یک سال است که آسیب پذیر است؟

بار دیگر در وضعیت مشابه: پس از آسیب پذیری در SSH، لازم بود همه سرورها به روز شوند. و هنگامی که یک وظیفه تعیین می کنید، باید اجرا را کنترل کنید. ( زیردستان معمولا سوء تفاهم می کنند، فراموش می کنند، گیج می شوند و اشتباه می کنند). بنابراین، ابتدا یک بررسی نسخه SSH به okerr در همه سرورها اضافه کردیم و از طریق okerr مطمئن شدیم که به روز رسانی ها در همه سرورها منتشر شده است. (راحت است! من این نوع نشانگر را انتخاب کردم و بلافاصله می توانید ببینید کدام سرور دارای کدام نسخه است). وقتی مطمئن شدیم که کار در همه سرورها انجام شده است، نشانگرها را حذف کردیم.

یکی دو بار موقعیتی پیش آمد که مشکل خاصی ایجاد می شود و سپس خود به خود برطرف می شود. (احتمالا برای همه آشناست؟). تا زمانی که متوجه می‌شوید، تا زمانی که بررسی می‌کنید - و چیزی برای بررسی وجود ندارد - همه چیز به خوبی کار می‌کند. اما بعد دوباره می شکند. ما این اتفاق افتاد، برای مثال، با محصولاتی که در بازار آمازون (MWS) آپلود کردیم. در برخی موارد، موجودی بارگیری شده نادرست بود (مقادیر اشتباه کالا و قیمت اشتباه). ما آن را فهمیدیم. اما برای کشف آن، مهم بود که فوراً در مورد مشکل پی ببرید. متأسفانه، MWS، مانند همه سرویس‌های آمازون، کمی کند است، بنابراین همیشه یک تاخیر وجود داشت، اما با این حال، ما توانستیم حداقل به طور تقریبی ارتباط بین مشکل و اسکریپت‌هایی که باعث آن می‌شوند را درک کنیم (ما بررسی کردیم، گیر کردیم آن را به okerr، و آن را بررسی کرد و بلافاصله یک هشدار دریافت کرد).

یک مورد جالب به تازگی توسط یک هاست بزرگ و گران قیمت اروپایی به مجموعه اضافه شده است که مشتری ما از آن استفاده می کند. ناگهان همه سرورهای ما از رادار ناپدید شدند! ابتدا خود مشتری (سریعتر از okerra!) متوجه شد که سایتی که با آن کار می کند باز نمی شود و در مورد آن بلیط تهیه کرد. اما نه فقط یک سایت، بلکه همه آنها از کار افتاد! (ناتاشا، ما همه چیز را رها کردیم!). در اینجا اوکر شروع به ارسال بسته های بلند پا با تمام نشانگرهایی کرد که برای او روشن می شد. وحشت، وحشت، ما در دایره می دویم (چه کار دیگری می توانیم انجام دهیم؟). سپس همه چیز اوج گرفت. معلوم می شود که تعمیر و نگهداری معمولی در مرکز داده انجام می شده است (هر سال یک بار) و البته باید به ما هشدار داده می شد. اما نوعی مشکل برای آنها پیش آمد و به ما هشدار ندادند. خب، حملات قلبی بیشتر، حملات قلبی کمتر. اما پس از بازیابی همه چیز، باید همه چیز را دوباره بررسی کنید! نمی توانم تصور کنم که چگونه این کار را با دستانم انجام دهم. Okerr همه چیز را در چند دقیقه آزمایش کرد. معلوم شد که اکثر سرورها به طور موقت در دسترس نیستند، اما کار می کنند. برخی از آنها بیش از حد بارگذاری شده بودند، اما همانطور که باید ایستاده بودند. از بین تمام ضررها، دو نسخه پشتیبان را از دست دادیم که طبق تاج باید در حالی که این موز کامل در جریان بود ایجاد و بارگذاری می شد. من حتی به خود زحمت ندادم آنها را ایجاد کنم، فقط یک روز بعد هشدارهایی رسید که همه چیز درست است، نسخه های پشتیبان ظاهر شده اند. من واقعاً این مثال را دوست دارم زیرا okerr در موقعیتی که ما حتی از قبل به آن فکر نکرده بودیم بسیار مفید بود، اما این هدف نظارت است - مقاومت در برابر غیرقابل پیش بینی ها.

برای سنسورهای Okerr، ما از ارزان ترین هاست ممکن استفاده می کنیم (در جایی که کیفیت و قابلیت اطمینان مهم نیست، یکدیگر را بیمه می کنند). بنابراین، ما اخیرا یک هاست بسیار خوب و بسیار ارزان پیدا کردیم، معیارها عالی هستند. اما ... گاهی اوقات معلوم می شود که اتصالات خروجی از ماشین مجازی از IP دیگری (همسایه) ایجاد می شود. معجزه ها ماژول Client_ip با https://diagnostic.opendns.com/myip IP اشتباه می گیرد. و از لاگ های سرور نشانگر مشخص است که آپدیت از این IP همسایه نیز آمده است. حالا بیایید به پشتیبانی بپردازیم. خوب است که در زمان صلح متوجه این موضوع شدیم. اما، برای مثال، اغلب اتفاق می افتد که دسترسی طبق لیست سفید IP ثبت می شود - و اگر سرور گاهی اوقات برای مدت کوتاهی به این شکل چشمک می زند - می توانید برای مدت بسیار طولانی سعی کنید این مشکل را برطرف کنید.

خوب، یک چیز دیگر - از آنجایی که ما در مورد میزبانی VPS صحبت می کنیم - ما همیشه از موارد ارزان قیمت (hetzner، ovh، scaleway) استفاده می کنیم. من آن را هم از نظر معیارها و هم از نظر ثبات بسیار دوست دارم. ما همچنین از آمازون EC2 بسیار گران‌تر برای پروژه‌های دیگر استفاده می‌کنیم. بنابراین، به لطف okerr، ما نظر آگاهانه خود را داریم. هر دو سقوط می کنند. و من نمی گویم که در طول دوره طولانی مشاهدات ما، هاست های ارزان قیمت مانند hetzner به طور قابل توجهی پایدارتر از EC2 بودند. بنابراین، اگر به سایر ویژگی‌های آمازون وابسته نیستید، چرا بیشتر پرداخت کنید؟ 🙂

گام بعدی چیست؟

اگر در این مرحله هنوز شما را از Okerr نترسانم، آن را امتحان کنید! می توانید مستقیماً به این لینک بروید حساب آزمایشی okerr (اکنون کلیک کنید!) اما به خاطر داشته باشید که فقط یک حساب آزمایشی برای همه وجود دارد، بنابراین اگر کاری انجام دهید، ممکن است شخص دیگری در همان حساب در همان زمان با شما تداخل کند. یا (بهتر) از طریق لینک به ثبت نام کنید خارج از سایت okerr - همه چیز ساده است، بدون اس ام اس. اگر دوست ندارید از ایمیل واقعی خود استفاده کنید، می توانید از ایمیل یکبار مصرف مانند mailinator استفاده کنید (توصیه می کنم getnada.com). چنین حساب هایی ممکن است در طول زمان حذف شوند، اما برای آزمایش خوب هستند.

پس از ثبت نام، از شما خواسته می شود که تحت آموزش قرار بگیرید (انجام چندین کار آموزشی نه چندان دشوار). محدودیت های اولیه بسیار کم است، اما برای آموزش یا یک سرور کافی است. پس از اتمام آموزش، محدودیت ها (مثلاً حداکثر تعداد شاخص ها) افزایش می یابد.

از اسناد - اول از همه WIKI در سمت سرور و در مشتری (okerrupdate ویکی). اما اگر چیزی نامشخص است، به پشتیبانی (در) okerr.com بنویسید یا یک بلیط بگذارید - ما سعی خواهیم کرد همه چیز را به سرعت حل کنیم.

اگر به طور جدی از آن استفاده می کنید و این محدودیت های افزایش یافته کافی نیست، برای پشتیبانی نامه بنویسید تا آن را افزایش دهیم (رایگان).

آیا می خواهید سرور okerr را روی سرور خود نصب کنید؟ اینجا مخزن okerr-dev. توصیه می کنیم روی یک ماشین مجازی تمیز نصب کنید، سپس می توانید آن را به سادگی با یک اسکریپت نصب انجام دهید. در ماشین مجازی شما - بدون محدودیت :-). خوب، دوباره، اگر اتفاقی بیفتد، ما همیشه سعی خواهیم کرد کمک کنیم.

ما می‌خواهیم این پروژه کلید بخورد تا دنیا به لطف ما قابل اعتمادتر شود. به لطف نرم افزار و خدمات رایگان، جهان دوستانه تر شده است و پویاتر در حال توسعه است. منابع را می توان در github رایگان ذخیره کرد، برای ایمیل می توانید از gmail رایگان استفاده کنید. ما رایگان استفاده می کنیم تازه کارها برای پشتیبانی. برای هر یک از این موارد، نیازی به پرداخت هزینه برای سرورها، نیازی به دانلود و پیکربندی ندارید و نیازی به حل مشکلات عملیاتی مختلف ندارید. هر پروژه جدید، هر تیم بلافاصله ایمیل، مخازن و CRM دارد. و همه اینها بسیار با کیفیت و رایگان و فوری است. ما می‌خواهیم برای نظارت هم همینطور باشد - شرکت‌ها و پروژه‌های کوچک می‌توانند از okerr به صورت رایگان استفاده کنند و حتی در مرحله تولد و رشد، قابلیت اطمینان پروژه‌های جدی بزرگسالان را داشته باشند.

منبع: www.habr.com