SNMP-маніторынг у Odoo 19: мяжа перавышана, тыкет адкрыты
Серверы, свічы, ІБП, датчыкі тэмпературы ў серверным памяшканні: амаль усё, што падключана да сеткі, гаворыць па SNMP і можа паведаміць пра свой стан. Пытанне толькі ў тым, хто слухае – і што адбываецца, калі значэнне выходзіць за межы.
Для інфраструктуры, якую мы абслугоўваем для нашых кліентаў, мы цяпер сабралі гэты ланцужок у адным месцы: наш Odoo 19 апытвае прылады, параўноўвае значэнні з межамі, і калі мяжа дасягнута, адкрывае тыкет у службе падтрымкі – у таго кліента, якому належыць прылада. Не асобная сістэма маніторынгу, якая піша па электроннай пошце ў службу падтрымкі, а тая ж сістэма, у якой кліент, прылада і тыкет і так звязаны.
Модуль мы распрацавалі для ўласнай працы. Гэта не публікацыя для супольнасці, як нашы модулі для банкаўскіх выпісак або электронных рахункаў, а частка нашай унутранай платформы абслугоўвання – як і геалакацыя, пра якую мы нядаўна расказвалі.
Ад вымеранага значэння да тыкета
Працэс наўмысна зроблены простым:
- Прылада ствараецца з адрасам і данымі доступу (SNMP v1, v2c або v3 з аўтэнтыфікацыяй і шыфраваннем). Пры захаванні Odoo атрымлівае апісанне сістэмы, імя сістэмы і uptime – самае сумленнае пацверджанне таго, што адрас і даныя доступу правільныя.
- На прыладзе вызначаюцца кропкі даных: OID, адзінка вымярэння, прызначэнне кліента.
- Расклад апытвае ўсе актыўныя кропкі даных. Для кожнай прылады злучэнне ўстанаўліваецца адзін раз, а не для кожнай кропкі даных – пры дваццаці OID на свічы гэта розніца паміж адной і дваццаццю сесіямі.
- Кожная кропка даных можа кантраляваць межы: верхнюю, ніжнюю або абедзве.
- Калі мяжа перавышана, узнікае тыкет у службе падтрымкі.
Адзін тыкет на інцыдэнт, а не на вымярэнне
Самы важны пункт у логіцы алармаў: лічыцца толькі змена стану. Хто стварае тыкет пры кожным вымярэнні, мае пасля ночы з заціснутым або дрыжачым датчыкам трыста тыкетаў – гэта не апавяшчэнне, гэта туман.
Таму модуль запамінае для кожнай кропкі даных, ці знаходзіцца яна ў стане «Normal» або «Alarm». Пры першым перавышэнні мяжы стан змяняецца, паведамленне трапляе ў 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-traps, а актыўна апытвае. І ён не закрывае тыкет аўтаматычна – адбой – гэта паведамленне, а не змена статусу.
Гаворка ідзе роўна пра адзін участак: ад вымеранага значэння праз мяжу да тэхніка, які займаецца справай. Гэты ўчастак цяпер такі кароткі, якім можа быць.
Калі вы хочаце ўключыць свае серверы, сеткавыя прылады або датчыкі ў гэты маніторынг, звяртайцеся да нас.