SNMP-моніторинг в Odoo 19: граничне значення перевищено, тікет відкрито
Сервери, комутатори, ДБЖ, датчики температури в серверній: майже все, що підключено до мережі, розмовляє 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-трапи, а опитує активно. І він не закриває тікет автоматично – відбій є повідомленням, а не зміною статусу.
Йдеться саме про один відрізок: від виміряного значення через межу до техніка, який займається проблемою. Цей відрізок тепер настільки короткий, наскільки це можливо.
Якщо ви хочете включити свої сервери, мережеві пристрої чи датчики до цього моніторингу, звертайтеся до нас.