Çavdêriya SNMP di Odoo 19 de: Sînor derbas bû, tîket vebû
Server, switch, pergalên UPS, hîsên germahiyê di odeya serverê de: Hema hema her tiştê ku di torekê de daliqandî ye SNMP diaxive û dikare derbarê rewşa xwe de agahî bide. Pirs tenê ev e ku kî guh dide – û çi diqewime dema ku nirxek ji kontrolê derdikeve.
Ji bo binesaziya ku em ji bo mişteriyên xwe diparêzin, me niha ev zincîr li yek cihî danî: Odoo 19 ya me cîhazan dipirse, nirxan bi sînoran re dide ber hev, û gava ku sînorek tê gihîştin, di Helpdesk de tîketek vedike – li cem mişteriyê ku cîhaz yê wî ye. Ne pergaleke çavdêriyê ya cihê ku bi e-nameyê ji Helpdesk re dinivîse, lê heman pergal ku mişterî, cîhaz û tîket tê de jixwe bi hev ve girêdayî ne.
Me modul ji bo xebata xwe pêş xist. Ev ne weşandineke komeleyê ye wekî modulên me yên ji bo ekstreyên bankê an e-fatureyan, lê beşek ji platforma me ya lênihêrîna navxweyî ye – mîna şopandinê, ku me di dawiyê de li ser wê ragihand.
Ji nirxa pîvandî ber bi tîketê
Herikîn bi mebest sade hatiye girtin:
- Cîhazek bi navnîşan û daneyên gihîştinê tê çêkirin (SNMP v1, v2c an v3 bi pejirandin û şîfrekirinê). Di dema tomarkirinê de Odoo danasîna pergalê, navê pergalê û Uptime werdigire – rastirîn pejirandina ku navnîşan û daneyên gihîştinê rast in.
- Li ser cîhazê xalên daneyan têne diyarkirin: OID, yekeyek, danasîneke mişterî.
- Plana demê hemû xalên daneyan ên çalak dipirse. Ji bo her cîhazekê carekê tê girêdan, ne ji bo her xala daneyê – di bîst OID li ser switchekê de ev cudahiya di navbera yek û bîst danişînan de ye.
- Her xala daneyê dikare sînoran bişopîne: sînorekî jorîn, sînorekî jêrîn an hem jî.
- Heke sînorek were derbaskirin, tîketeke Helpdesk çêdibe.
Yek tîket ji bo her bûyerê, ne ji bo her pîvandinê
Xala herî girîng di mantiqa alarmê de: Tenê guhertina rewşê dihejmêre. Kesê ku ji bo her pîvandinê tîketekê çêdike, piştî şeveke bi sensorekî asê an lerzok sê sed tîketan heye – ev ne alarm e, ev kuxirandin e.
Modul ji ber vê yekê ji bo her xala daneyê tîne bîra xwe ka di rewşa „Normal" an „Alarm" de ye. Di derbaskirina yekem a sînor de rewş diguhere, peyamek di Chatter ya cîhazê de dikeve, û tîketek tê vekirin – bi mişteriyê bandorbûyî wekî partner, bi xala daneyê, cîhaz, nirxa pîvandî û sînorê binpêkirî di nivîsê de. Heya ku nirx li derveyî sînor dimîne, tiştek din nayê kirin: Tîket vekirî ye, teknîsyenên me dizanin.
Gava ku nirx vedigere asta normal, modul di heman tîketê de hişyariya bê xetere dinivîse û girêdanê vedike. Ka tîket paşê were girtin yan na, hê jî mirov biryar dide – nirxek ku demeke kurt li jêr sînor dikeve, hê nayê wê wateyê ku sedem hatiye çareserkirin.
Sînor di her pîvandinê de têne kontrolkirin, bêyî ku nirx were tomarkirin. Nirxeke bi domdarî pir bilind alarm dimîne. Û alarm qet nabe ku bi ber tîketê nehatina çêkirinê ve bişkê – heke çêkirin têk biçe, tomar û peyam li ser cîhazê dîsa dimînin.
Tenê tiştê ku diguhere tomar bike
Xalek daneyê ku her pênc deqeyan tê pirsîn, di salê de 105.000 nirxan dide. Di sed xalên daneyê de ev ji deh milyon rêzan zêdetir e – ji bo nirxan ku pir caran qet nehatine guhertin.
Ji ber vê yekê tenê tiştê ku li gorî nirxa dawî ya tomarkirî ji bêtirî sînorekî hatî sazkirin cuda dibe tê tomarkirin – ji bo her xala daneyê wekî cudahiya mutleq (mînak 0,5 °C), wekî veqetîna sedî an di her guhertinê de. Nirxa heyî û dema pirsa dawî dîsa her gav li ser xala daneyê ne; tenê dîrok tê kêmkirin.
Nirx li ku têne nivîsandin jî dikare were mîhengkirin: di databasa Odoo de, di MongoDB de an wekî pelên CSV di Odoo-Filestore de. Bi vî awayî em nirxên pîvandinê ji databasa ERP dûr dihêlin – heman prensîp wekî di daneyên cihê yên şopandinê de. Dîrok di her rewşê de dikare wekî diagram were nîşandan, di berhevkirina saetane de wekî navînî, ne wekî berhevok.
Asta tijîbûnê bi sedî li şûna bayt
Hin mezinahî wekî wan di cîhazê de nîn in. Asta tijîbûna partîsyonekê divê ji bîra bikarhatî û mezinahiya giştî were hesabkirin; sensorên germahiyê pir caran hejmarên tam yên pîvandî didin – 235 ji bo 23,5 pile.
Xalek daneyê ji ber vê yekê dikare nirxê wekî hatî ragihandin bigire, bi faktorekê bi ser de zêde bike an wekî sedîyeke OID ya duyem hesab bike. Ji bo sînoran ev diyarker e: Sînorek 90 % ji bo her mezinahiya dîskê derbasdar e. Sînorek bi gîgabayt dê ji bo her ajokerê were nûvekirin.
Tu kes naxwaze OID ji ber bike
Di serverên Windows û Linux de HOST-RESOURCES-MIB standard e: Ajoker û bîra xebatê li cihê naskirî ne. Naskirina cîhazê tabloyê dixwîne, astên tijîbûnê bi sedî hesab dike û xalên daneyê bi sînorê alarmê bi yek klîkê çêdike.
Ji bo her tiştê din SNMP-Browser heye ku dara OID dimeşe û her OID ya hatî dîtin bi nirxa wê ya heyî nîşan dide – û, heke di katalogê de naskirî be, bi nav, danasîn û yekeya ji MIB ya çêker a împortkirî. Nîşankirin bes e.
Mişteriyên me ji vê çi sûd werdigirin
Cîhaz û xalên daneyê bi mişteriyan ve girêdayî ne. Di portala mişteriyan de di bin Nirxên min ên SNMP de nirxên pîvandî yên heyî yên cîhazên xwe û dîroka 24 saetên dawî, 7 rojan, 30 rojan an 12 mehan wekî diagram dibînin – heman nirxan ku em jî dibînin. Tenê tiştê ku bi pargîdaniya we ve girêdayî ye xuya ye.
Û heke sînorek were derbaskirin, hûn neçar in tiştek nekin: Tîket jixwe li cem me ye, bi cîhaz, nirx û demjimêr, berî ku hûn pê bihesin.
Modul bi mebest çi nîne
Ew ne cîgirê çavdêriyeke temam e bi kontrolên berdestbûnê, zincîrên bilindkirinê û daran girêdayîbûnê. Ew SNMP-Trap wernagire, lê bi çalakî dipirse. Û ew tîketekê bi awayekî otomatîk nagire – hişyariya bê xetere peyamek e, ne guhertineke rewşê.
Tenê li ser rêyekê ye: ji nirxa pîvandî bi sînorê re heya teknîsyenê ku xwe pê ve mijûl dike. Ev rê niha bi qasî ku pêkan e kurt e.
Heke hûn dixwazin serverên xwe, cîhazên torê an sensoran têxin vê çavdêriyê, bi me re têkilî daynin.