پایش SNMP در Odoo 19: عبور از حد مجاز، ایجاد تیکت
سرورها، سوییچ‌ها، دستگاه‌های UPS و حسگرهای دمای اتاق سرور: تقریباً هر دستگاه متصل به شبکه از SNMP پشتیبانی می‌کند و می‌تواند وضعیت خود را گزارش دهد. سؤال فقط این است که چه کسی این گزارش‌ها را دریافت می‌کند و وقتی مقداری از محدودهٔ عادی خارج می‌شود، چه اتفاقی می‌افتد.
برای زیرساخت‌هایی که مدیریتشان را برای مشتریانمان بر عهده داریم، اکنون تمام این زنجیره را در یک سامانه جمع کرده‌ایم: Odoo 19 ما داده‌های دستگاه‌ها را می‌خواند، مقادیر را با حدود مجاز مقایسه می‌کند و وقتی مقداری به حد تعیین‌شده برسد، در بخش پشتیبانی برای مشتریِ صاحب دستگاه تیکت باز می‌کند. به‌جای یک سامانهٔ پایش جداگانه که با ایمیل به بخش پشتیبانی پیام می‌فرستد، همه‌چیز در همان سامانه‌ای انجام می‌شود که مشتری، دستگاه و تیکت از قبل در آن به هم مرتبط‌اند.
این ماژول را برای استفادهٔ داخلی خودمان توسعه داده‌ایم. برخلاف ماژول‌های صورتحساب بانکی یا صورتحساب الکترونیکی ما، این ماژول برای جامعهٔ کاربری منتشر نشده، بلکه بخشی از پلتفرم داخلی خدمات پشتیبانی ماست؛ درست مانند سامانهٔ ردیابی که اخیراً درباره‌اش نوشته‌ایم.
از مقدار اندازه‌گیری‌شده تا تیکت
روند کار را عمداً ساده نگه داشته‌ایم:
- دستگاه با نشانی و اطلاعات دسترسی ثبت می‌شود (SNMP v1، v2c یا v3 با احراز هویت و رمزنگاری). هنگام ذخیره، Odoo توضیحات سیستم، نام سیستم و مدت روشن بودن آن را دریافت می‌کند؛ تأییدی عملی و قابل اتکا برای درست بودن نشانی و اطلاعات دسترسی.
- برای دستگاه، نقاط داده تعریف می‌شوند: یک OID، یک واحد و یک مشتری مرتبط.
- یک برنامهٔ زمان‌بندی، داده‌های همهٔ نقاط فعال را دریافت می‌کند. اتصال برای هر دستگاه فقط یک بار برقرار می‌شود، نه برای هر نقطهٔ داده؛ برای بیست OID روی یک سوییچ، این یعنی یک نشست به‌جای بیست نشست.
- برای هر نقطهٔ داده می‌توان حد بالا، حد پایین یا هر دو را برای پایش تعیین کرد.
- اگر مقدار از محدودهٔ تعیین‌شده خارج شود، یک تیکت پشتیبانی ایجاد می‌شود.
یک تیکت برای هر رخداد، نه برای هر اندازه‌گیری
مهم‌ترین نکته در منطق هشدار: فقط تغییر وضعیت اهمیت دارد. هر که برای هر اندازه‌گیری تیکت ایجاد کند، پس از یک شب با یک حسگر گیرکرده یا لرزان، سیصد تیکت دارد – این هشداردهی نیست، این مه‌آلودکردن است.
ماژول از این رو برای هر نقطه‌ی داده به خاطر می‌سپارد که در وضعیت «عادی» است یا «هشدار». با نخستین رد آستانه، وضعیت تغییر می‌کند، یک پیام در Chatter دستگاه ثبت می‌شود و یک تیکت باز می‌شود – با مشتری مربوط به‌عنوان شریک تجاری، با نقطه‌ی داده، دستگاه، مقدار اندازه‌گیری‌شده و آستانه‌ی نقض‌شده در متن. تا وقتی مقدار بیرون از آستانه بماند، دیگر اتفاقی نمی‌افتد: تیکت باز است، تکنسین‌های ما مطلع‌اند.
وقتی مقدار به محدودهٔ عادی برگردد، ماژول پیام رفع هشدار را در همان تیکت ثبت و ارتباط آن را با نقطهٔ داده قطع می‌کند. تصمیم دربارهٔ بستن تیکت همچنان با انسان است؛ اینکه مقداری برای مدت کوتاهی پایین‌تر از حد مجاز قرار بگیرد، لزوماً به معنای رفع علت مشکل نیست.
حدود مجاز در هر اندازه‌گیری بررسی می‌شوند، چه مقدار ذخیره شود و چه نشود. مقداری که همواره بیش از حد بالاست، همچنان هشدار محسوب می‌شود. همچنین، ناتوانی در ایجاد تیکت نباید مانع ثبت هشدار شود؛ اگر ایجاد تیکت شکست بخورد، گزارش و پیام همچنان در رکورد دستگاه باقی می‌مانند.
فقط تغییرات را ذخیره کنید
یک نقطهٔ داده که هر پنج دقیقه خوانده می‌شود، سالانه ۱۰۵٬۰۰۰ مقدار تولید می‌کند. برای صد نقطهٔ داده، این تعداد به بیش از ده میلیون ردیف می‌رسد؛ آن هم برای مقادیری که اغلب اصلاً تغییر نکرده‌اند.
به همین دلیل، فقط مقداری ذخیره می‌شود که اختلافش با آخرین مقدار ذخیره‌شده از آستانهٔ تنظیم‌شده بیشتر باشد. برای هر نقطهٔ داده می‌توان اختلاف مطلق (مثلاً ۰٫۵ °C)، انحراف درصدی یا ثبت با هر تغییر را انتخاب کرد. با این حال، مقدار فعلی و زمان آخرین دریافت همیشه در نقطهٔ داده موجود است؛ فقط حجم تاریخچه کاهش می‌یابد.
محل ذخیرهٔ مقادیر هم قابل تنظیم است: پایگاه دادهٔ Odoo، یک MongoDB یا فایل‌های CSV در مخزن فایل Odoo. به این ترتیب، داده‌های اندازه‌گیری را خارج از پایگاه دادهٔ ERP نگه می‌داریم؛ همان اصلی که برای داده‌های موقعیت در سامانهٔ ردیابی رعایت می‌کنیم. در همهٔ حالت‌ها، تاریخچه را می‌توان به‌صورت نمودار نمایش داد؛ در تجمیع ساعتی، میانگین نمایش داده می‌شود، نه مجموع.
درصد فضای مصرف‌شده به‌جای تعداد بایت
بعضی کمیت‌ها مستقیماً در دستگاه موجود نیستند. درصد فضای مصرف‌شدهٔ یک پارتیشن باید از حجم مصرف‌شده و ظرفیت کل محاسبه شود؛ حسگرهای دما هم اغلب اعداد صحیحِ مقیاس‌شده می‌دهند، مثلاً ۲۳۵ برای ۲۳٫۵ درجه.
بنابراین، یک نقطهٔ داده می‌تواند مقدار را همان‌طور که گزارش شده دریافت کند، آن را در ضریبی ضرب کند یا نسبت آن را به مقدار یک OID دیگر به‌صورت درصد محاسبه کند. این موضوع برای حدود مجاز تعیین‌کننده است: حد ۹۰٪ برای هر ظرفیتی از دیسک معتبر است، اما حدی بر حسب گیگابایت باید برای هر درایو جداگانه تنظیم و به‌روز شود.
نیازی نیست کسی OIDها را از حفظ بداند
در سرورهای Windows و Linux، ساختار HOST-RESOURCES-MIB استاندارد است: اطلاعات درایوها و حافظه در محل مشخصی قرار دارد. قابلیت شناسایی دستگاه، جدول را می‌خواند، میزان مصرف را به درصد تبدیل می‌کند و نقاط داده را همراه با حد هشدار، با یک کلیک ایجاد می‌کند.
برای موارد دیگر، یک مرورگر SNMP وجود دارد که درخت OID را پیمایش می‌کند و هر OID یافت‌شده را همراه با مقدار فعلی آن نشان می‌دهد؛ اگر در فهرست شناخته شده باشد، نام، توضیحات و واحد آن را هم از MIB واردشدهٔ سازنده نمایش می‌دهد. کافی است موارد دلخواه را تیک بزنید.
این قابلیت چه سودی برای مشتریان ما دارد
دستگاه‌ها و نقاط داده به مشتریان مربوطه اختصاص داده شده‌اند. در پورتال مشتریان، زیر بخش مقادیر SNMP من، مقادیر فعلی دستگاه‌هایتان و نمودار تاریخچهٔ ۲۴ ساعت، ۷ روز، ۳۰ روز یا ۱۲ ماه گذشته را می‌بینید؛ دقیقاً همان مقادیری که ما هم می‌بینیم. فقط اطلاعاتی نمایش داده می‌شود که به شرکت شما اختصاص دارد.
اگر مقداری از حد مجاز عبور کند، لازم نیست کاری انجام دهید: پیش از آنکه متوجه شوید، تیکت همراه با دستگاه، مقدار و زمان رخداد به دست ما رسیده است.
این ماژول عمداً چه کارهایی انجام نمی‌دهد
این ماژول جایگزین یک سامانهٔ کامل پایش با بررسی دسترس‌پذیری، زنجیره‌های ارجاع و درخت‌های وابستگی نیست. اعلان‌های SNMP Trap را دریافت نمی‌کند و داده‌ها را به‌صورت فعال از دستگاه می‌خواند. همچنین هیچ تیکتی را خودکار نمی‌بندد؛ رفع هشدار به‌صورت پیام ثبت می‌شود، نه تغییر وضعیت.
هدف دقیقاً یک مسیر است: از مقدار اندازه‌گیری‌شده و عبور از حد مجاز تا تکنسینی که رسیدگی می‌کند. این مسیر اکنون تا جای ممکن کوتاه شده است.
اگر می‌خواهید سرورها، تجهیزات شبکه یا حسگرهایتان را به این سامانهٔ پایش اضافه کنید، با ما تماس بگیرید.