پایش SNMP در Odoo 19: آستانه رد شد، تیکت باز شد
سرورها، سوئیچ‌ها، سیستم‌های UPS، حسگرهای دما در اتاق سرور: تقریباً هر آنچه به شبکه متصل است SNMP می‌فهمد و می‌تواند درباره‌ی وضعیت خود اطلاع دهد. مسئله فقط این است که چه کسی گوش می‌دهد – و وقتی یک مقدار از کنترل خارج می‌شود چه اتفاقی می‌افتد.
برای زیرساختی که برای مشتریان‌مان نگهداری می‌کنیم، اکنون این زنجیره را در یک جا گرد آورده‌ایم: Odoo 19 ما دستگاه‌ها را پرس‌وجو می‌کند، مقادیر را با آستانه‌ها مقایسه می‌کند و وقتی به یک آستانه برسد، در Helpdesk یک تیکت باز می‌کند – برای مشتری‌ای که دستگاه به او تعلق دارد. نه یک سیستم پایش جداگانه که با ایمیل در Helpdesk می‌نویسد، بلکه همان سیستمی که در آن مشتری، دستگاه و تیکت به‌هرحال به هم مرتبط‌اند.
ماژول را برای کسب‌وکار خودمان توسعه دادیم. این یک انتشار جامعه‌محور مانند ماژول‌های ما برای صورت‌حساب‌های بانکی یا فاکتورهای الکترونیکی نیست، بلکه بخشی از پلتفرم داخلی نگهداری ماست – مانند ردیابی که اخیراً درباره‌اش گزارش دادیم.
از مقدار اندازه‌گیری تا تیکت
روند عمداً ساده نگه داشته شده است:
- یک دستگاه با نشانی و اطلاعات دسترسی ایجاد می‌شود (SNMP نسخه‌ی v1، v2c یا v3 با احراز هویت و رمزنگاری). هنگام ذخیره، Odoo شرح سیستم، نام سیستم و Uptime را می‌گیرد – صادقانه‌ترین تأیید این‌که نشانی و اطلاعات دسترسی درست‌اند.
- روی دستگاه، نقاط داده تعریف می‌شوند: یک OID، یک واحد، یک تخصیص مشتری.
- یک زمان‌بندی همه‌ی نقاط داده‌ی فعال را پرس‌وجو می‌کند. برای هر دستگاه یک‌بار اتصال برقرار می‌شود، نه برای هر نقطه‌ی داده – با بیست OID روی یک سوئیچ، این تفاوت میان یک نشست و بیست نشست است.
- هر نقطه‌ی داده می‌تواند آستانه‌ها را پایش کند: یک حد بالا، یک حد پایین یا هر دو.
- اگر یک آستانه رد شود، یک تیکت Helpdesk ایجاد می‌شود.
یک تیکت برای هر رخداد، نه برای هر اندازه‌گیری
مهم‌ترین نکته در منطق هشدار: فقط تغییر وضعیت اهمیت دارد. هر که برای هر اندازه‌گیری تیکت ایجاد کند، پس از یک شب با یک حسگر گیرکرده یا لرزان، سیصد تیکت دارد – این هشداردهی نیست، این مه‌آلودکردن است.
ماژول از این رو برای هر نقطه‌ی داده به خاطر می‌سپارد که در وضعیت «عادی» است یا «هشدار». با نخستین رد آستانه، وضعیت تغییر می‌کند، یک پیام در Chatter دستگاه ثبت می‌شود و یک تیکت باز می‌شود – با مشتری مربوط به‌عنوان شریک تجاری، با نقطه‌ی داده، دستگاه، مقدار اندازه‌گیری‌شده و آستانه‌ی نقض‌شده در متن. تا وقتی مقدار بیرون از آستانه بماند، دیگر اتفاقی نمی‌افتد: تیکت باز است، تکنسین‌های ما مطلع‌اند.
وقتی مقدار به محدوده‌ی عادی بازگردد، ماژول یک اعلام پایان هشدار در همان تیکت می‌نویسد و پیوند را برمی‌دارد. این‌که تیکت سپس بسته شود یا نه، همچنان با یک انسان است – مقداری که اندکی زیر آستانه می‌افتد هنوز به معنای رفع علت نیست.
آستانه‌ها در هر اندازه‌گیری بررسی می‌شوند، صرف‌نظر از این‌که مقدار ذخیره شود یا نه. مقداری که پیوسته بیش از حد بالا باشد، همچنان هشدار است. و هشدار هرگز نباید به این دلیل شکست بخورد که تیکت ایجاد نمی‌شود – اگر ایجاد شکست بخورد، گزارش و پیام روی دستگاه به‌هرحال می‌مانند.
فقط آنچه تغییر می‌کند ذخیره می‌شود
نقطه‌ی داده‌ای که هر پنج دقیقه پرس‌وجو می‌شود، سالانه 105.000 مقدار تولید می‌کند. با صد نقطه‌ی داده، این بیش از ده میلیون ردیف است – برای مقادیری که بیشتر اوقات اصلاً تغییر نکرده‌اند.
از این رو فقط آنچه نسبت به آخرین مقدار ذخیره‌شده بیش از یک آستانه‌ی تنظیم‌شده تفاوت دارد ذخیره می‌شود – برای هر نقطه‌ی داده به‌صورت اختلاف مطلق (مثلاً 0,5 °C)، به‌صورت انحراف درصدی یا با هر تغییر. مقدار فعلی و زمان آخرین پرس‌وجو به‌هرحال همیشه روی نقطه‌ی داده هست؛ فقط تاریخچه رقیق می‌شود.
این‌که مقادیر کجا نوشته شوند نیز قابل تنظیم است: در پایگاه داده‌ی Odoo، در یک MongoDB یا به‌صورت فایل‌های CSV در Filestore Odoo. به این ترتیب مقادیر اندازه‌گیری را از پایگاه داده‌ی ERP دور نگه می‌داریم – همان اصلی که در داده‌های موقعیت ردیابی هم هست. تاریخچه در هر حالت به‌صورت نمودار قابل نمایش است، در فشرده‌سازی ساعتی به‌صورت میانگین، نه مجموع.
سطح پر بودن به درصد به‌جای بایت
برخی کمیت‌ها به‌صورت مستقیم در دستگاه نیستند. سطح پر بودن یک پارتیشن باید از حافظه‌ی اشغال‌شده و اندازه‌ی کل محاسبه شود؛ حسگرهای دما اغلب اعداد صحیح مقیاس‌شده می‌دهند – 235 برای 23,5 درجه.
از این رو یک نقطه‌ی داده می‌تواند مقدار را همان‌طور که گزارش شده بپذیرد، در یک ضریب ضرب کند یا به‌صورت درصدی از یک OID دوم محاسبه کند. برای آستانه‌ها این تعیین‌کننده است: آستانه‌ی 90 % برای هر اندازه‌ی دیسک صدق می‌کند. آستانه‌ای بر حسب گیگابایت باید برای هر درایو جداگانه نگهداری می‌شد.
هیچ‌کس نباید OIDها را از بر بداند
در سرورهای Windows و Linux، HOST-RESOURCES-MIB استاندارد است: درایوها و حافظه‌ی اصلی در جای مشخصی قرار دارند. یک تشخیص دستگاه جدول را می‌خواند، سطح پر بودن را به درصد تبدیل می‌کند و نقاط داده را همراه با آستانه‌ی هشدار با یک کلیک ایجاد می‌کند.
برای هر چیز دیگر یک مرورگر SNMP وجود دارد که درخت OID را پیمایش می‌کند و هر OID یافت‌شده را با مقدار فعلی‌اش نشان می‌دهد – و در صورت شناخته‌بودن در کاتالوگ، با نام، شرح و واحد از MIB وارد‌شده‌ی سازنده. علامت‌زدن کافی است.
مشتریان ما از این چه سودی می‌برند
دستگاه‌ها و نقاط داده به مشتریان تخصیص داده می‌شوند. در پورتال مشتری زیر مقادیر SNMP من مقادیر اندازه‌گیری فعلی دستگاه‌های خود و روند 24 ساعت، 7 روز، 30 روز یا 12 ماه گذشته را به‌صورت نمودار می‌یابید – همان مقادیری که ما نیز می‌بینیم. فقط آنچه به شرکت شما تخصیص داده شده قابل مشاهده است.
و وقتی یک آستانه رد شود، شما نیازی به انجام کاری ندارید: تیکت پیش از آن‌که متوجه شوید، با دستگاه، مقدار و ساعت نزد ما هست.
ماژول عمداً چه چیزی نیست
جایگزین یک پایش کامل با بررسی دسترس‌پذیری، زنجیره‌های ارجاع سطح بالاتر و درخت‌های وابستگی نیست. SNMP Trap دریافت نمی‌کند، بلکه فعالانه پرس‌وجو می‌کند. و هیچ تیکتی را خودکار نمی‌بندد – اعلام پایان هشدار یک پیام است، نه تغییر وضعیت.
موضوع دقیقاً یک مسیر است: از مقدار اندازه‌گیری، از آستانه، تا تکنسینی که رسیدگی می‌کند. این مسیر اکنون تا حد ممکن کوتاه است.
اگر می‌خواهید سرورها، دستگاه‌های شبکه یا حسگرهای خود را در این پایش بگنجانید، با ما تماس بگیرید.