Lenne erre igény?

 ( log69 | 2015. november 25., szerda - 23:55 )

Sziasztok,

Lenne szerintetek igény az alábbi linken található zamboriz fórumtársunk ötletére? Ha igen, vajon milyen elterjedtségben?

Tegyük fel hogy sikerül egy biztonsági szempontból jól megtervezett kódot összerakni, amely erőforrás takarékos. Linux platformot céloznék elsősorban. Esetleg egy script nyelvre támaszkodni, ha van mód a platform független process- és terhelés vizsgálatra.

http://hup.hu/node/111130#comment-1411455

Köszönöm.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Céges igény szerintem lehet rá. Nekem kellett csinálni hasonlót asteriskre, ami figyelte, hogy mennyi sms, hívás megy és ha nagyon (asszem 10%) eltért az előző hét meg hónap azonos napjától akkor riasztott nagioson keresztül.

FathoM

igen ez sok problemara megoldas is lehet, ha a korabbi azonos idoszakkal hasonlitjuk ossze, esetleg (ahol van ertelme) mindezt per-user vagy per-domain alapon.

esetleg hogy ML is legyen benne, irni valami olyat ami a munin adatokbol, grafikonokbol tanul, es az abban levo mintakat illetve azoktol valo elterest figyelne? ez azert lenne jo mert munin plugin mar kb mindenre van, es azok eleg jol szamszerusitik a mert parametereket egyseges feluleten, idopont alapjan.

pl meg tudna tanulni egy szerver memoria hasznalatat, amiben vannak mondjuk ismetlodoen rendszeres kiugrasok (pl amikor lemegy valami mentes, vagy db compact) meg amugy is mondjuk hullamzik napszaknak megfeleloen, de van egy jellegzetes periodikus mintaja. ha ettol nagyon elter akkor valami gaz van. nehez elhinni, hogy meg senki se csinalt ilyet :)

A'rpi

van erre egy eleg elvetemult otletem. bar nem biztos, hogy mukodne. ha ugy nezzuk ezeket a grafikonokat, mint egy hullamgorbe (kulonbozo periodusu hullamokbol tevodik ossze. pl napon belul valtozo terheles, hetvegi alacsonyabb terheles ami hetente ismetlodik, valami backup ami mondjuk 2 naponta fut le stb).

mi van ha egyszeruen csinalok egy nagyobb (mondjuk 2 honapos) idoszakra egy FFT-t (fourier transzformaciot), es ez alapjan extrapolalom a jovobeli gorbet? majd az igy szamolt es a valos mert ertek eltereset figyelem. ha lesz idom kiprobalom, nem egy nagy cucc ezt lekodolni, az .rrd-t ki lehet dumpolni asciiba ha jol emlekszem.

A'rpi

Lehet ilyesmit, vagy csak a jelenlegi mérésből a korábbiak átlag görbéjét kivonni, nagy eltérés esetén riasztani, de a különbség négyzetének integrálása után is egy adott érték fölött riasztani. Itt ugye arról van szó, hogy ha folyamatosan nem túl nagy az eltérés, de az tartós, akkor lesz belőle jelzés.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

igen. az igazi feladat a korabbi adatok atlagolasa, mert azert itt inkabb egy nagyon osszetett extrapolalasrol van szo, ami igyekszik lekovetni a korabbi karakterisztikat es elorevetiteni azt. ezert is gondoltam a fourier-re, mert az tud kulonbozo frekvenciaju valtozasokat szamszerusiteni es reprodukalni.

A'rpi

"nehez elhinni, hogy meg senki se csinalt ilyet :)"

Ige, az a baj hogy egy alapos piac kutatás is kellene, ami megint nem kevés idő, energia és így pénz.

hat befektetes nelkul nincs nyereseg :)
alternativa az opensource fejlesztes, es rabizni az egeszet a nagy szamok torvenyere :)

Lehet en bagatelizalom el, de nem erre valoak a monitorozo alkalmazasok? Beallitasz egy threshold erteket es a rendszer kuld neked egy riasztast ha attol elterot eszlel.

Azért ezt lehet kicsit jobban is csinálni, nagyon szép machine learning feladat :).

--

Szerintem itt arról van szó, hogy a threshold állítás öntanulóan működne.

igen, ez lenne a lenyeg.

engem erdekelne, en is gondolkoztam mar ilyesmin, csak nem tudom megfogni sehol :) marmint az ilyen algoritmusokhoz szamszerusiteni kene mindent, de ezt altalanossagban eleg nehez megtenni...

mondjuk engem foleg az email forgalom kiugro vagy a szokasostol eltero volta erdekelne. levelezesnel pl van 2000 user, es van aki napi 100-200 levelet valt de van aki csak heti 3-at kuld. van aki egesz nap nezi a leveleit van aki naponta 1x lep be. ha ezekben jelentos valtozas lep fel jo lenne jelezni, mert akkor valami tortent.
(jelenleg is van riasztas ha valaki eleri a napi 100 cimzettet, de vannak userek akik rendszeresen elerik mert sok korlevelet kuldenek, van akinel meg amire ez riaszt mar nagy a baj - mondjuk erre talan egyszerubb lenne fejleszteni valamit, ami per-user tarol egy mozgo atlagot es az ettol valo elterest nezi csak. na ezt mindjart meg is irom :))

webnel is erdekes, de azt meg nehezebb altalaossagban megfogni, foleg a csoda sql-es cms-ek miatt. meg arra mar eleg sok tool van ami bizonyos limit feletti oldalletoltesnel korlatoz vagy riaszt.

A'rpi

"engem erdekelne, en is gondolkoztam mar ilyesmin, csak nem tudom megfogni sehol :) marmint az ilyen algoritmusokhoz szamszerusiteni kene mindent, de ezt altalanossagban eleg nehez megtenni..."

Nekem pont erre lenne sok (több) ötletem. De nyilván nem kis feladat azért, és sok fajta képen meg lehet közelíteni.

Ha pl. az I/O terhelést vesszük processzenként, akkor histogrammot tárolnék minden process terheléséről 1 napra, 1 hétre és 1 hónapra is. Ezek mellett generálnék ebből több fajta "képet" különböző burkoló görbékkel. A régi adatokkal hasonlítanánk az újakat különböző módon - ez is érdekes algoritmus fejlesztéseket rejt magában - és össze is kellene mosni az új adatot a régivel.

Szerintem ketté lehetne szedni az egészet. Az egyik a felismerő lib lenne, amely le lenne okosan algoritmizálva és teljesen általános adattal megetethető (vagyis két 1 dimenziós mintával).

A másik lenne az összes modul, pl: cpu / process, disk / process, net / kliens gép, email / user stb.

De kérdés, hogy azért ezt a nem kis munkát hogy lehetne megtéríteni?

Kiegészítés: a harmadik rész lenne az értesítés metódusa, pl: desktop info buborék, email, log fájl vagy egyéb interface meglévő monitoring cuccokhoz - ahogy említettétek - pl munin. Ezt is elég szerte ágazóra lehet csinálni. Pl. ismerje a szabványos MTA-kat vagy külső SMTP-ket (gmail). Esetleg email to SMS gateway-eket.

> 1 napra, 1 hétre és 1 hónapra is.

igen ez az egyik nehez problema, mert pl vannak jobok amik minden vasarnap futnak le, es vannak amik mondjuk minden honap elsejen.
es akkor meg nem is beszeltunk az even beluli hullamzasrol, pl egy email szerver eseten az unnepek korul meglodul (sok udvozlo level), a szunetekben meg (nyaron, karacsony utan) meg lecsokken. tehat meg az eves adatokat is nezni kene. na meg az evente valtozo idopontban elofordulo munkaszuneti napokat es hosszu hetvegeket is :)

az adatgyujtesre elso korben szerintem a munin idealis, pont azt csinalja ami nekunk kell, es eleg sok helyen hasznaljak is mar evek ota igy vannak visszamenolegesen adatok. mig egy uj adatgyujtonel honapokat kene varni mire egyaltalan el tud kezdeni erdemben mukodni az elemzo algoritmus...

megterules: jo kerdes. en anno az mplayer-t ingyen, hobbibol csinaltam, iszonyatosan sok ido es energia volt 4 even at, ugyanakkor nagyon sok ismeretseget, es ceges megkeresest kaptam ezaltal, a mai napig foleg ezekbol elek. sokszor kerdeztek miert nem penzert arultam vagy egyaltalan miert lett opensource: egyedul sose keszultem volna el vele, egyszeruen kellett az a 100+ ember aki evekig ezen dolgozott tok ingyen. ezt meg egy tokeeros startup sem tudna finanszirozni.

a masik opcio hogy eladod, vagy egyenkent az usereknek (es szopsz a supporttal), vagy valami cegnek aki aztan meggazdagszik belole :)

illetve van meg az, amit sok opensource projektnel csinalnak, hogy a fo fejlesztok alapitanak egy ceget es a supportot adjak penzert. igy azok a cegek akik nem akarnak szopni a bevezetessel, finomhangolassal meg tudjak venni a supportot elso kezbol (a fejlestzoknel jobban senki sem ismeri a termeket). esteleg lehet olyan plugineket, opcionalis modulokat irni hozza (pl szep csilivili gui, vagy mondjuk sms ertesites kuldo, mobil app stb) ami nem resze az openszosz verzionak, csak kulon penzert veheto meg. (lasd pl a zimbra-ban az outlook connector vagy a mobil app ilyen).

A'rpi

Az nem baj ha van hullámzás (eltérés) a terhelés megjelenésében. Erre meg egy olyan okosítást kellene csinálni, amelynél úgy húzzuk a régi görbére az újat, hogy vízszintesen lehet részeket skálázni. Vagy kiszámoljuk a körbe kerületét. Vagy egyszerre több szempontból vizsgáljuk. Pl. az egész havi teljes terhelését is hasonlítjuk. Egy rakás szempontból meg lehet közelíteni.

Arra meg, hogy ne kelljen megvárni az 1 hónapot, megoldás lehetne szerintem, hogy akkor az aktuális eltelt időt vesszük alapul. De ezt is úgy, hogy például mindaddig csak minta vételezés van, amíg egyre nagyobb "dombok" jönnek - ez beállítja az eddigi max terhelést - és ekkor ha már volt kisebb domb is, akkor lehet vizsgálgatni.

Baromi szerteágazó a kérdés. nyilván mindent meg lehet csinálni, de rohadtul nem mindegy, hogy mennyi emberóra kell egy használható 1.0-s körüli verzióhoz.

Nem beszélve a technológia követésről, hogy ugye változik a környezet és technológiák futnak ki és jelennek meg - például RHEL 7-nél mit dobtak és mit nem - az új Linux kernelek API-ja hogy módosul - a user space tool-ok változásainál milyen szívások jöhetnek stb.

Nehéz megcsinálni. Nekem a mentésem ugyanarról a gépről volt, hogy néhány percig tartott, de volt, hogy 8 órán át. Egy dologra gondolhatok. Van egy 30 GB-os virtuális gép egy file-ban. Ha ezen bármi változik, akkor ezzel a nagy file-lal az dekrementális backup-ban is kezdeni kell valamit, meg ki is kell írni, ha nem változik, akkor meg nem. Manapság már kivételek közé tettem a virtuális gép image-ét.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nem tévedek nagyot, a SCOM-nak vannak önhangoló metrikái, amire megadod a vizsgálandó periódust (pl havi, mert a havi zárás kihajtja, de az OK) és ahhoz hasonlít. Linux monitorozásra is jó.

A másik, amit megnéznék, az Operation Management Suite.

Üdv,
Marci
A Microsoftnál dolgozom.

Erre a témakörre gyakorlatban is működő, elterjedt alkalmazás nem nagyon van, bár azért előfordul (pl. az emlegetett SCOM-ban).

Az elméletről sokat lehet olvasni, ha rákeresel, hogy "anomaly", "unusual", "time series", "detection" vagy ezek valamilyen kombinációja.

Ha open source megoldást keresel, akkor nézegesd a Prometheus-t (http://prometheus.io/), nem tartanak még itt, de errefelé haladnak.

Az ötlet jó, igény lenne is rá, de nem vagyok benne biztos, hogy ki is fizetnék. Egy ilyen monitorozást csak úgy tudsz rendesen finomhangolni, ha minden egyes teljesítmény példányhoz manuálisan végignézed a görbéket, és az alapján finomhangolod az aktuális példány algoritmusát. Ez rengeteg idő, és nem sok cég hajlandó a betanítás idejét fizetni (és/vagy dedikált embert áldozni erre).

Ahogy Mrceeka is említette, a SCOM-ban vannak self-tuning monitorok. Itt van egy példa, hogy néz ki a GUI-n. Maga a SCOM meglehetősen összetett, és több cégnél is azt látom, hogy nem akarnak embert dedikálni a finomhangolására, ami nélkül csak a töredékét lehet belőle kihozni. Ez alapján gondolom azt, hogy ha fejlesztenél egy saját megoldást erre, akkor nem biztos, hogy el tudnád adni azt az időt az ügyfélnek, ami a finomhangolásához kellene. Vagy ha el is kezdenéd a projekt részeként, az ügyfél nem fogja befejezni azt, hiába is dokumentálod le.

Jómagam nem a Microsoftnál dolgozom. Részt vettem jó pár SCOM telepítésben/upgrade-ben, és néhány ügyfelünknek nyújtunk hozzá terméktámogatást.

Szerk.: a Balabit Shell Control Box terméke (ami beékelődik az adminisztrátorok és a szerverek közé, és lényegében "videóra veszi" a munkamenetet) szintén tartalmaz beépített algoritmusokat arra, hogy a szokatlan viselkedés esetén ellenlépéseket tegyen (például megszakítsa a kapcsolatot, ha az admin éjszaka próbál meg bejelentkezni, de soha nem szokott).

Nem hiszek az egyedi esetek kézi finomhangolásában. Kizárólag teljesen automatikus hangolásnak van értelme számomra, különben nem éri meg a befektetett időt - az miatt amit te is mondasz, hogy szerverenként kellene beavatkozás. És legfeljebb kinyomja az értesítést az admin, hogy fals riasztás. De csak akkor van létjogosultsága egy ilyen lefejlesztésének, ha jól meg tudjuk közelíteni teljes automatizálással az általános igényt. "1 klikk" telepítés -> és működjön.

"Egy ilyen monitorozást csak úgy tudsz rendesen finomhangolni, ha minden egyes teljesítmény példányhoz manuálisan végignézed a görbéket, és az alapján finomhangolod az aktuális példány algoritmusát. Ez rengeteg idő, és nem sok cég hajlandó a betanítás idejét fizetni (és/vagy dedikált embert áldozni erre)."

Tökéletesen definiáltad a machine learning létjogosultságát. Evvel nagyon jól megoldható (sőt, szerintem már megoldott) a feladat.

"például megszakítsa a kapcsolatot, ha az admin éjszaka próbál meg bejelentkezni, de soha nem szokott"

Ez mondjuk elég súlyos, ha valami váratlan gond van, még tetézi a bajt :).

--

fejesjoco írta:
Tökéletesen definiáltad a machine learning létjogosultságát. Evvel nagyon jól megoldható (sőt, szerintem már megoldott) a feladat.

Igazad van, definiáltam. Ugyanakkor szerintem rengeteg adat kell ahhoz, hogy használható legyen a következtetések levonása. Problémás lehet az is, ha fals adatot kap a tanuló algoritmus (az egyik admin például lustaságból tévesnek állítja be az alertet, hogy "jól van, már ne zajongj").

Talán a Blindspotter esetén ez már megvalósított. Sajnos nem ismerem ezt a terméket.

Kiigazítás: a Balabit Blindspotter terméke tud ilyen vizsgálatatot, nem a Shell Control Box. Viszont ha integrálva van ez a kettő, akkor képesek arra, hogy adott esetben akár megszakítsák az admin session-t.

sub

pont irni akartam, hogy mintha a balabitnek lenne hasonlo cucca