[Videó] Átlátni az átláthatatlant: hálózati forgalomelemzés egyszerűen

Címkék

Zsák Csaba (Andrews IT Engineering) a HWSW free! meetup sorozaton elhangzott előadásának felvétele.

A komplex monitoring és elemzés egyre fontosabbá vált az utóbbi évtizedben, amikor is egyre magasabb SLA-kat kell tartani, egyre fontosabb, hogy milyen a válaszidő vagy milyen fenyegetéssel nézünk éppen szembe az informatikai rendszerünkben. Az előadásban alkalmazás teljesítmény monitoringgal, anomália detekcióval és historikus kereshetőséggel foglalkozunk - pusztán hálózat elemzésből kiindulva.

(A videó a HWSW free! meetup-sorozat 2019. június 18-i IT-üzemeltetői állomásán készült.)

Hozzászólások

A videó elején határozottan úgy tűnt az előadó látott már enterprise környezetet mikor a team-ek működését írta le. Aztán az előadás bemutatta hogy nem.

Mivel idestova 10 éve (vagy több) rendszeresen dolgozunk együtt az előadóval, biztosíthatlak róla, hogy nem csak, hogy látott, de üzemeltet is a csapatával olyan enterprise környezetet, amivel Magyarország (és külföld) nagyvállalatai vannak kiszolgálva.

(Nem, nem egy helyen dolgozunk. Még csak nem is egy városban.)

trey @ gépház

El nem tudom képzelni, hogy mi lehet az a visszatérő use-case, ami indokolja a teljes layer 7-es forgalom historikus tárolását. 

Az említett példákban (lassú SQL query, CI/CD Pipeline) sem jutna eszembe a hálózati forgalomból visszafejteni az alkalmazás réteget.

Valaki látott már ilyet működésközben? :) 

Én nem láttam, de nem tűnik rossz ötletnek. Ha valami hiba van, sokszor úgy kell elindulni, hogy mikor volt utoljára jó, mi változott.

Ha van olyan szoftver, ami megfelelően képes elemezni ezt az adathalmazt, kiszűrni belőle a változást, az hasznos lehet.

Például könnyen bele lehet futni olyanba, hogy az ember talál valami lassú dolgot. De aztán kiderül, hogy mindig is lassú volt, azaz rengeteg idő elmehet érdemi eredmény nélkül.

Az ugyanakkor valóban elgondolkodtató, hogy egyre több a titkosított adatforgalom és ez nem fog csökkenni. Ha belegondolunk: minél több az ilyen elemző cucc, annál célszerűbb minél több forgalmat titkosítani :-)

De egy layer 7-ben felmerülő hibát nem hálózati forgalom dump-olásával fogod megoldani.

Ha lassú az SQL server, akkor nem a hálózati dump-ból fogom az érintett query-t kivadászni (azt hiszem ez volt a példa), hanem a DB segítségével log-olom a hívásokat, az alatta lévő rétegek overhead-je nélkül. 
 

Nekem az jött le az előadásból, hogy a kiindulás szerint valahol probléma van és nem tudni hol, mert első blikkre minden gazda mindent rendben lát.

Mivel nincs meg első pillantásra a probléma oka, de viszont probléma van, el kell kezdeni keresni. Nagyjából három potenciális forrást fel is sorol: alkalmazás kiszolgáló, adatbázis, tároló.

Lehet azt mondani, hogy mindenki nézzen szét még kicsit jobban a saját háza táján (pl. a DBA-k figyeljék a lekérdezéseket, van-e lassabb és az alapján talán be lehet lőni, hogy a lekérdezés nem kellően optimalizált vagy a tároló lassú a háttérben), de ha jól értem az eszköz hamarabb megtalálhatja a probléma forrását, főleg komplexebb rendszerek esetén, amit "kézzel" egyáltalán nem feltétlenül könnyű kideríteni.

Azaz segít lokalizálni, hogy egyáltalán melyik adatbázis szerveren kell keresni, de az sem biztos, hogy adatbázisban kell keresni, lehet alkalmazás szerver is vagy valami más.

Például utóbbi időben többször előfordult, hogy adatbázis azért lassult be, mert sorban álltak a Windows frissítések (telepítés nélkül). Jobban nem lett kielemezve, hogy hol jött be a lassulás, mert a frissítések telepítése megoldotta a problémát, de el tudok képzelni olyan forgatókönyvet, mely szerint tényleg az adatbázis szerver szolgálja ki lassan a kéréseket, de maguk a lekérdezések gyorsan lefutnak.

>  Nekem az jött le az előadásból, hogy a kiindulás szerint valahol probléma van és nem tudni hol, mert első blikkre minden gazda mindent rendben lát.

en gyakran talalkozom ilyen szituval, foleg amikor kulso cegek szoftvereirol/szolgaltatasairol van szo. mindenki szerint minden jo, kozben megis hol mukodik hol nem, vagy jobb esetben csak baromi lassu.  de egy dologban mindenki egyetert ilyenkor: BIZTOS HALOZATI HIBA.

a halozatos meg oldja meg, hiszen mindenki szerint nala a gond... ilyenkor vagy otthagyod az ugyfelet, vagy bebizonyitod, hogy nincs igazuk. ilyenkor jobb hijan a tcpdump marad...

volt olyan esetem ahol wifis pda-kon futo raktari alkalmazas sql parancsokat kuldozgetett az mssql szervernek, es gyakran errort dobott. mindenki azt mondta, hogy biztos szar a wifi, leszakadnak, azert van a hiba. de a halozati forgalmi dumpbol kiderult, hogy a csomag eljut a szerverig, de az neha nem vagy nem jot valaszolt ra.

Amiket leírtál, azok tényleg valós use case, én sem azt vitatom, hogy szükség lehet tcp dump-ra.
De ezekhez és úgy általában is szerintem felesleges preemptive módon előre menteni a forgalmat (hátha jó lesz valamire), főleg layer 7 szinten lévő adatokkal. 

igen altalaban akkor inditom el a dumpolast amikor elkezdjuk keresni a hibat, de sokszor nagyon jol jott volna, foleg nagyon ritkan jelentkezo / nehezen reprodukalhato eseteknel, ha a historikus adatok is meglettek volna, legalabb nehany orara (vagy max napra) visszamenoleg...

de az teny, ha elore nem tudjuk mire lesz szukseg, akkor ez nagyon draga mulatsag is lehet, mivel akkor kb mindent kell rogziteni...

pont tegnap volt egy olyan eset, hogy az userek egy resze nem ert el szinte semmit a halozaton, se netet se belso szervereket, de persze az userektol csak a szokasos "szar a szerver" tipusu report jott. mire eljutott hozzam az info mar helyreallt minden, de az ugyfel szerette volna tudni, mi volt ez, mi okozta, hogy lehetne megelozni stb.  a halozati eszkozoket monitorozzuk, ott semmi riasztas vagy rendellenesseg nem latszott, a szervereken sem lattak problemat, az userek meg r=1 userek, beloluk nem lehet ertelmes infot kinyerni. ilyenkor is jol jott volna, ha utolag vissza tudjuk nezni az adott idoszakban a forgalmat, hogy megis mi volt vagy nem volt...  az en tippem az, hogy a belso DNS nem ment, de ezt csak tipp marad a dump nelkul...

De egy layer 7-ben felmerülő hibát nem hálózati forgalom dump-olásával fogod megoldani.

Megoldani biztosan nem, de számtalanszor volt már olyan szitu, ahol mindegyik csapat csak pingvinezett, meg a másikra mutogatott, mert szerinte minden jó.

Ilyen esetekben - és az előadás is erre fókuszált - a hálózati forgalom monitorozása hitelt érdemlően ki tudja mutatni ,hogy melyik komponens reakciója volt a "lassú" vagy nem üzen szerű.

 

szerintem.

Mail (IMAP) protokol hiba volt.
Az app (ami leveles ladabol csinal ticketet) vagy groupware hibaja ami tolja ki leveleket.

SQL selectektek kivadszasa az app-bol, amit nem teljes mertekben a ceged fejlesztett csak pluginokat hozza,
de lassan valaszol.
SQL response time latszik a dumpol.
Gyakori keres latszik.

Ha te irod az appot, lehet ra tudod venni hogy minden selectet logoljon.
DBA -a csoport nem feltlen add neked eleg jogot ahhoz hogy minden querity levadasz,
vagy nem olyan az SQL cumod ami tudja/ engedelyezett. (PL. nem mutatja, hogy 5000 select (1) -et tolt ki az app sorozatban, csak az epen futo 1 -et)

Valami nem ugy mukodik ahogy kene, fogado nem dolgozza fel, vagy a kuldo nem kuldi ki a HTTP headert ..

https://a-static.besthdwallpaper.com/mindenki-hazudik-tapeta-7480_L.jpg

Az appok nem csak hibaznak, de hazudnak is a logba, a halozati dump nem fog pont egy headert  kihagyni.

Jaj de nem uroluk az SSL manianak, foleg belso alkalmazasnal.
Ha hiba van, csak tobb a szivas a debuggal miatta ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Biztos van ilyen, láthatod a videon, ez azonban összevegyíteni az enterprise-al hiteltelenné teszi az egészet.  A kérdésre válaszolva ha nem is L7,  L4 szintig van értelme es meg is teszik és tud segíteni, de inkább tényleg statisztikai szinten ilyen most ilyen lett, ez történt ekkor állt helyre (recovery time) és esemény utáni table^H elemzés. 

Ezt csakis enterprise környezetben tudom elképzelni, annyira nagy a cost - benefit.

Ott a CA házon belül van, az SSL kapcsolatokat fel tudod bontani. 

"most ilyen lett, ez történt ekkor állt helyre (recovery time)"

Ez pont szerencsésebb layer 5+ mérni.

Ez esetben sem kell, hogy a szolgáltatások tanúsítványát belső CA adja ki. Például akkor kifejezetten problémás lehet, ha külső partnerek is használják a szolgáltatást.

Ha SSL végződtetést akarsz, annak az a feltétele, hogy kliensek ismerjék a végződtető rendszer vagy az azt kibocsátó CA tanúsítványát. Ez ugyanúgy lehet duplikált külső kibocsátású tanúsítvány vagy akár * tanúsítvány.

(magyarán az SSL kapcsolat felbontásának nem előfeltétele, hogy legyen belső CA annak minden nyűgjével)

De jelen esetben én úgy értem, hogy az SSL végződtetés nem is lehet része a repertoárnak, mert a monitorozó nem ékelődik bele a kapcsolatba, hanem port forgalom tükrözés van, azaz "egyszerű" hallgatózás. Aminek az is az előnye, hogy nem lassítja a forgalmat, azaz valóban passzív résztvevő. Ilyen esetben teljesen mindegy, ki a CA, a kulcsokra van szükség az adatfolyam dekódolásához.

> Ez esetben sem kell, hogy a szolgáltatások tanúsítványát belső CA adja ki.

Nem állítottam hogy kell. Megpróbáltam rávilágítani, hogy miért mondta a kolléga, hogy a belső CA akkor is számít, ha nincs benne a kommunikációban, mert úgy tűnt, nem érted.

>  Például akkor kifejezetten problémás lehet, ha külső partnerek is használják a szolgáltatást.

Persze, ez a házi tanúsitványoknál így van.

> a SSL végződtetést akarsz, annak az a feltétele, hogy kliensek ismerjék a végződtető rendszer vagy az azt kibocsátó CA tanúsítványát

Nem mondod.

>  Ez ugyanúgy lehet duplikált külső kibocsátású tanúsítvány vagy akár * tanúsítvány.

(magyarán az SSL kapcsolat felbontásának nem előfeltétele, hogy legyen belső CA annak minden nyűgjével)

A dupla tanúsítványnak is vannak nyűgje, a *osnak is egyébként, de ebből a szempontból csak az ssl bontásos usecasek csak egy részét lehet vele fedni: azokat, ahol te rendelkezel egyébként kontrollal a server felett is, tehát kaphatsz rá certet. És nyilvánvalóan nem fogsz kapni *.example.com-osat, míg saját CAval, amit a kliensek elfogadnak tudsz ilyet is generálni.

Megpróbáltam rávilágítani, hogy miért mondta a kolléga, hogy a belső CA akkor is számít, ha nincs benne a kommunikációban, mert úgy tűnt, nem érted.

Miért számít/előnyös a belső CA, ha csak monitorozza a hálózatot és aktívan nem avatkozik be? (Tekintsünk el attól a helytelen gyakorlattól, amikor CSR-rel együtt a privát kulcs is mindenfelé megfordul.)

Az állítás így szólt:

Ott a CA házon belül van, az SSL kapcsolatokat fel tudod bontani. 

Ebben implicit szerepel (könnyen bele lehet érteni), hogy a szolgáltatások CA-ját belső CA írja alá.

Pontosabb megfogalmazás ez lenne: "ahol van hálózaton belüli CA (is), ott az SSL kapcsolatokat fel tudod bontani". Mert az mindegy, hogy a szolgáltatások tanúsítványát milyen CA írja alá, a lényeg az, hogy a kliens megfelelő CA-val aláírt tanúsítványokat vagy explicit rögzített tanúsítványokat lásson.

> Miért számít/előnyös a belső CA, ha csak monitorozza a hálózatot és aktívan nem avatkozik be? (Tekintsünk el attól a helytelen gyakorlattól, amikor CSR-rel együtt a privát kulcs is mindenfelé megfordul.)

Fentebb már írtam, hogy mivel van előrébb.

> Ebben implicit szerepel (könnyen bele lehet érteni), hogy a szolgáltatások CA-ját belső CA írja alá.

> Pontosabb megfogalmazás ez lenne: "ahol van hálózaton belüli CA (is), ott az SSL kapcsolatokat fel tudod bontani". Mert az mindegy, hogy a szolgáltatások tanúsítványát milyen CA írja alá, a lényeg az, hogy a kliens megfelelő CA-val aláírt tanúsítványokat vagy explicit rögzített tanúsítványokat lásson.

Ne haragudj, de nem értem, mit szeretnél.

Ezt írtad: "Ott a CA házon belül van, => mivel a kliensek megbíznak a te CAdban, on the fly generálhatsz bármihez certificatet, végződtetheted a kapcsolatot, nézhetsz / mókolhatsz bele, és eljátszva a klienst dobhatod tovább a szervernek egy másik kapcsolaton."

Nagyon nem látom, hogy ezzel miért vagyok beljebb, ha csak figyelni van módom a forgalmat, megköszönném, ha kifejtenéd.

Kezdem sejteni, hol beszélünk el egymás mellett :)

Az eredeti állítás ez volt:

> Ott a CA házon belül van, az SSL kapcsolatokat fel tudod bontani. 

Te erre írtad, hogy:

> A CA nem ismeri a privát kulcsokat, így közömbös, hogy hol van a CA.

Ezért azt gondoltam, hogy nem érted, hogy mire jó egy a te kezedben levő CA, amiben a kliensek megbíznak, ha bontani szeretnéd az SSLt, erre reagáltam. Meg sem fordult a fejemben, hogy arról van szó, hogy egyáltalán nem bontjuk. Még a 

> Miért számít/előnyös a belső CA, ha csak monitorozza a hálózatot és aktívan nem avatkozik be?-t

is úgy értettem, hogy bontással monitorozunk (szóval ugyan kibontjuk, megnézzük, és újracsomagoljuk, de nem nyúlunk bele)

Természetesen, ha egyáltalán nem bontasz, csak egy tcpdumpod van, akkor teljesen mindegy, mi volt a CA. Igaz, akkor nagyjából az is, hogy mi volt a konkrét certificate, mert ahogy willy irta, akkor meg a -- ma már azért jellemzően elérhető -- PFS (perfect forward secrecy) képes kulcscsere algoritmusok* miatt hiába van meg a privát kulcsod, nem tudod visszafejteni.

* DH-* és ECDH-* azt hiszem, ami megy, tls1.3ban már ha jól rémlik csak ECDH van, de ebben nem vagyok biztos.

Tipikus enterprisnal szerintem nem tudsz felloni egy random MiM proxit.

 - A CA csoport nem fog neked csoda certet adni
 - A halozati csoport nem fogja ad-hock routolni
 - ..

A sajat alkalmazasodat ra veheted hogy ki firkalja kulcsokat, ami utan dumpolhatsz.
See also: SSLKEYLOGFILE

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igen láttam, egy részét én terveztem. :)

Visszatérő use-case lehet az, hogy a törvényi szabályzás előírja.
Vannak itthon is ilyen helyek szép számmal.

Egyébként meg mindig a megfelelő megoldást próbáljuk alkalmazni, például egy cloud native környezetbe nem raknék be
egy klasszikus on-premise hálózathoz való visibility infrastruktúrát.

Arra is van eszköz és az oda való.

Volt rá példa, hogy ezekkel az eszközökkel (és persze elemzői szaktudással) sikerült gyorsan segíteni egy ügyfélnek az adott problémáján.

Hagyományos hálózat, aminek több pontjáról gyűjtöttük a forgalmat (SPAN portokon).
Ezt aggregáltuk és továbbítottuk a kiértékelést végző appliance-re.
Azon felépítettük az adott szolgáltatáshoz tartozó flow térképet.
Majd vártunk.

Amikor ismét jelentkezett a hiba, akkor már volt egy időablak, amiben tudtunk keresni, elemezni.
A kolléga megtalálta a hiba helyét és okát.

Itt konkréten egy hibásan beállított load-balancer volt, ami miatt bizonyos esetekben az egyik node-ra ment a forgalom jelentős része.
Ez nem volt állandó, nem tudta az ügyfél mihez kötni, így maradt az, hogy segítettünk neki.

Ezek általában nem olcsó eszközök, de jellemzően azok a cégek veszik, akiknél a hibákból adódó időkiesés még nagyobb kiadással járna.

...úgyis jönnek...

Visszatérő use-case lehet az, hogy a törvényi szabályzás előírja.
Vannak itthon is ilyen helyek szép számmal.

A törvényi szabályozás a naplózást írhatja el, abban nagyon kételkedem, hogy explicit előírja a hálózati forgalom layer 5 szintű historikus tárolását.

például egy cloud native környezetbe nem raknék be egy klasszikus on-premise hálózathoz való visibility infrastruktúrát.

Itt most fizikai hálózatra gondoltam, SDN esetén ez jelentősen egyszerűbb / olcsóbb.

Itt konkréten egy hibásan beállított load-balancer volt, ami miatt bizonyos esetekben az egyik node-ra ment a forgalom jelentős része.

Bontsuk ezt ketté:

- A hibát gondolom az egyik node magasabb terheléséből vagy a szolgáltatás log-olásából vették észre > nem az történt, hogy a network csapat a hatalmas eltárolt hálózati log-ból kibányászta, hogy hopp, ott egy cluster hiba :)

- Ha megvan a hiba, akkor ez valószínűleg a load balancer szolgáltatás log-olásából kideríthető, vagy esetleg akkor el lehet indítani tcp dump-ot leszűkítve arra szolgáltatásra > nincs szükség a teljes switch forgalom historikus tárolására

"A törvényi szabályozás a naplózást írhatja el, abban nagyon kételkedem, hogy explicit előírja a hálózati forgalom layer 5 szintű historikus tár

olását."

A mélységét nem írja elő a törvény, de a döntéshozókon sok múlik.
Olyan helyekre gondolj, ami az ország szempontjából mondjuk kritikus infrastruktúra lehet, mint pl. egy erőmű (nem az volt).

"Itt most fizikai hálózatra gondoltam, SDN esetén ez jelentősen egyszerűbb / olcsóbb."

SDN-nél, cloud native környezetben is meglepően drága dolgok tudnak lenni. Természetesen itt az enterprise szintű dolgokra gondolok, pl.: Fortune 500-as cégek.

"Bontsuk ezt ketté:"

Ne bontsuk, mert felesleges. :)
Azt is elmondom miért.

A hibát a felhasználói bejelentésekből vették észre. Ebben az esetben körbekérdeztek és mindenki mindent rendben talált.

A log beállításaikat nem ismerem, de nem ez volt a szűk keresztmetszet, hanem az emberi erőforrás.
Mindegyik csapat alul van méretezve, folyamatosan a napi túlélésért küzdenek. Ha energiájuk lenne is rá, idejük alig.

Jellemzően itt nem kellett a teljes csomagot lementeni, de máshol igen.
Mindig a megfelelő eszközt és beállításokat használjuk az ügyféligényeknek megfelelően.

Ha azt szeretné, hogy egy évre visszalehessen mindent nézni, akkor azt is meg tudjuk oldani.
Ennek a költségvonzata viszont őt terheli. Általában el szoktak tekinteni a hosszú távú tárolástól. :)

...úgyis jönnek...

Több, mint tíz évig dolgoztam Csambival, az előadóval (de már nem). Biztosíthatlak, hogy nem egy enterprise környezetet látott, kezelt, kiváló szakember. Nekem úgy tűnik, hogy nem sikerült megértened az előadás lényegét. Nem a teljes belső hálózat monitorozásának előnyeit ecseteli. Nem arról van szó, hogy 15k Jóska desktopja miért lassan éri el a Gmail-t.

Inkább olyan esetről van szó, amikor mondjuk egy nagy SaaS rendszer backendjének belsejében kell hibakeresésére felkészülni, eszközöket adni az adminoknak. Amikor együtt dolgoztunk, akkoriban én már inkább szoftvert fejlesztettem, de oldalról láttam pár olyan szolgáltatást, aminek a backend része sok mikroservice-ből áll és százas nagyságrendű szervereken fut és az admin csapat kezelte őket. Ilyen (főleg virtualizált) környezetben nagyon is ésszerű ez a preventív hozzáállás, hogy ha gubanc van, akkor legyen adat, amiből szakértő szem ki tudja nézni, hogy hol lehet egy lassulás oka. És szerintem egy ilyen, erősen védett, teljesítményre kiélezett hálózatban, a BE belsejében szükség esetén lehetséges a Layer 7 elérése, mentése. Ha kell, akkor saját PKI-val, igen.

Egyébként a hozzászólásod modortalan volt, alapból ilyenre nem is válaszolnék. De annyira sértő a feltételezésed, hogy még az én igazságérzetem se hagyta szó nélkül. Én tényleg láttam, hogy mivel foglalkozik az előadó. Szerintem neked jó lenne egy kicsit szerényebbre venni.

Egy leegyszerűsített, teoretikus helyzet:

Van egy microservice alapú backend, mely A,B,C,D,E szolgáltatásokból áll. A szolgáltatások JSON-RPC-n beszélgetnek HTTP felett. A microservice-ek egy multirepo-ban laknak a Git-ben, egyszerre megy ki az összesre a deploy. Egy deploy után jelentősen megnő az teljes rendszer válaszideje és az A, B szolgáltatások CPU terhelése jelentősen nő. Mi lehet a baj?

Azt már a hálózati fejlécek utólagos elemzéséből is meg lehet nézni, hogy mely két komponens közti kapcsolatok átlagos kiszolgálási ideje nőtt meg a deploy előttihez képest. De ebből még nem lehet tudni, hogy pontosabban hol a hiba. Ha a TCP kapcsolatokhoz hozzá tudnád rendelni a kérés irányát (bár ez még a TCP-ből kitalálható) és az RPC függvény nevét és paramétereit, és ezeknek a deploy utáni kiszolgálási diagramjait összeveted a deploy előtti nappal, akkor már azt is látni lehet, hogy konkrétan melyik RPC hívás kiszolgálása lassult le.

A fejlesztők ezek után sokkal könnyebben rájöhetnek, hogy mi lehet a kiváltó ok. Amúgy ezt persze alkalmazás szintű profiling segítségével is lehet mérni, de ez ellen néhány érv:

  • minden microservice-be implementálni kell,
  • nem feltétlenül lesz egységes, lehet, hogy a microservice-ek technológiája heterogén, nem mindnél megvalósítható azonos megoldás,
  • a profiling jó eséllyel kisebb-nagyobb mértékben lerontja a teljesítményt.

Ellenben ha ez hálózat szinten van kezelve, akkor csak egyetlen helyen kell implementálni és utána akár 20-30 microservice profilingja is egyszerűen, egységesen, egy helyen megoldható. Hangsúlyozom nem egy PHP+MySQL CMS-ről beszélünk, hanem egy milliótól kezdődő felhasználó számú, sokszáz szerveres backend-ről.

BTW nem én adtam elő a témáról, csak az előadás alapján nekem ez jött le. Csak álmodoztam egyet egy jól kezelhető forgalom elemzőről, mely remek lenne egy jó komplex rendszerhez.

"ezt persze alkalmazás szintű profiling segítségével is lehet mérni"

"profiling jó eséllyel kisebb-nagyobb mértékben lerontja a teljesítményt"
A halozati eszkozok sincsenek CPU -val eleresztve, de nezuk kicsit maskep a temat.

Elmeletben mindnen alkalmazas logol egyebkent is, elmeletben egy 100 as szervices dolognal egy kozponti valami fele lesz a log kitolva egyebkent is.
Mi lenne e plusz profilig szervice hegyek abajgatasa helyett, az egyebkenet is kezelt loggolast tennenk meg hasznalhatobba.
 - strukturalt loggolas , mondjuk valamifele json streamet minden micro service ki tudd tolni.
   A nagyon elenkezo szervicek logjait valamelyeset lehet konvertarlni (a log analizalo fele egyebkent is fel szokas parsolni valami strukturlatabba, ha szemet jon ki..)
 - A strukturlat logba meg beletehetsz egy (tobb) id -t. Az ID nelukul hivott szervice generalhat egy contex ID-t es bele teszi minden altala hivott RPC keresbe, amit mindenki szepen logol.
    - Igy azt is latod, hogy szervice A az adott keresre hivott 10 szervice B,C,D amik A konkret kerese miatt csinaltak 30 E,F,G hivast.

Azt lehet tovabb bonyolitani, tobb ID hasznalataval. ID lehet egy sima random string (UUID4), tartalmazhat issuert valamilyen formaban type/host/pid ...

Szoval, kisebb koltseggel egyes estekben lehet meg hasznalahatobb dolgot csinalni.

Persze ha a halozati forgalom nem SSL, es minden alkalmazasa hasznal egy jo ID -t, es meg halozati elemeid is birjak tartani tempot akkor egy ID -vel
kiegeszitve a layer 7 net logger is hasznalhatobb lenne..

Az app esten,  3 party fele iranyulo (pl. DB) kereseket szinten loggolhatjuk contex specifikusan a micro service logjaba .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

a logolas azert messze nem olyan detailed mint a profiling. sot komolyabb forgalmu rendszereknel eleve csak a hibat szoktak logolni, nem mindent. tehat a lassulast nem is fogod a logokban latni, hacsak nem rakod tele a kodot sebesseg meressel, ami meg overhead.

masreszt az egesz mindent logolosdi-elemezosdi akkor megoldhato ha a te fejleszted az osszes komponenst, ami azert ritkan valosul meg...

ID-k: hat ez is jo moka. en irtam mail.log elemzot, ami kibanyassza az infokat es betolja sql-be, vegig kovetve 1-1 email teljes utjat az osszes szuron (greylist, spamassassin, sajat szurok, clamav, stb) at a deliveryig, kozben folyton valtozik az id-je, hol PID-eket es PPID-eket kell osszekotni, hol message id-t (ami lehet duplikalt ha pl. forwardolodik vagy levlista es emiatt 2x megy at a szuron) hol a mail queue id-jet ami meg regebben ujrahasznositott volt (mar egy ideje tud a postfix is unique qid-t legalabb), 1-1 esemeny (level delivery) akar 4 napig is eltarthat, es neha tobb 10 ezer uj is johet 1 sec alatt. es ez csak 1 kis szever logja... es folyton updatelni kell, mert neha 1-1 komponens frissitesevel megvaltozik valami a log formatumban.

A'rpi

"a logolas azert messze nem olyan detailed mint a profiling. "

A mini access loggot http serveren nem szokas kikapcsolni, meg nagyobb forgalmu rendszernel sem.
nginx log ha valoban nagy request szamot csinalsz feltuno teljesitmeny valtozas ab (Apache benchmark) nem feltuno,
mivel az ab a szuk keresztemetszet . https://github.com/wg/wrk -nal kikapcsolt loggolas mar hatalmas valtozas,
de olyan hatamas request szamrol beszelunk amit mezei halando nem-igen lat.

A backend koltsege aminel szamitana a logolas miatti veszteseg eleve nagyon magas lesz.

Nem tudom te mit ertesz profiling alatt,
Nagy telesitemny esten csak a sampling profilereknek van eleg alacsony overheadje hogy ne latszodjon.
En most olyan profilingrol beszeltem, ami csak a lenyegesebb momentumokat logolja.
Nagyobb szamitas (passwd hash mar annak szamithat ~5000 round sha2), vagy kulso kereseket.
Vagyis nem csak a bemeno, kimeno kereseket is.
A bemeno keresek minimalis loggolasa, kb 4 szer annyi adata mint egy sima access log,
a kimeno dolgok app fuggoen akkor 10x annyi is lehet mint a bemeno log.
Nem loggolunk minden local method hivast vagy ilyesmi..

strukturaltan loggolni lehet viszonylag olcson:
https://github.com/uber-go/zap

Ha valami kozponti log rendszert hasznalsz, ha nem strukturalt a log akkor convertalod .
Timestamp resz parszolva, worker parszolva ... , ha mar eleve egy viszanylag konnyen ertheto(parszolhato) formaban van
akkor a log gyujtogeto CPU koltsegen sporolsz.

" tehat a lassulast nem is fogod a logokban latni, hacsak nem rakod tele a kodot sebesseg meressel, ami meg overhead."
Azert egy keres elejen es vege nem olyan veszes egy timestampet kerni:
A Linux vdso https://man7.org/tlpi/code/online/dist/vdso/gettimeofday.c.html eleg olcson lekerheted az idot,
egy integer kivonas szinten nem tul draga.
" One system call that is commonly bypassed through an implementation in the VDSO is gettimeofday(2)"

Tottal vak repules-hez kepest en ~10% tobblet CPU koltseget saccolnek tipikus estben.
Ha mar csinalsz valamilyen access lognak latszo dolgot (legalbb request time lathato),
a tenyleges plusz a profiling extrak miatt nem feltelen fog feltunni.

Szeretem a jo nagy benchmar szamokat, de a vak repulest mar nem annyira.

"masreszt az egesz mindent logolosdi-elemezosdi akkor megoldhato ha a te fejleszted az osszes komponenst, ami azert ritkan valosul meg..."

Mint mondtam ha kulso dolgot hivasz azt loggolja az app, ha kulso dolog nem loggol megfeleloen es hiv egy masik dolgot az nem lesz osszekotve az eredeti keressel.
Egy memcached keresnel a loggolas kolsge valszinuleg  dragabb, de egy SQL cluster write intent keresenl valszinuleg olcsobb, read intent, egyetlen record  nal oszemerheto lehet.

Eleg ha kozepso elemeket te irod, a legalso ill legkulso reteg lehet kulsos.

A log elemek Elasticsearch -be valo (az ingyenes valozat -ban is megvan ami kell) tarolasa eleg gyors, eleg nagy lehet.

Ha az appod jelentos reszet egy  ACID DB cluster ethernet/TCP/IP -vel valo komunikacioval tolti,
akkor loggolas nem lesz feltunoan draga.

"ID-k: hat ez is jo moka. en irtam mail.log elemzot "
Az e-mail nel tipkusan tobb ID-t szokas hozza adni a regi megorzesevel, legalabb kovetheto, megha trukkos is.

size:
Elesticsearch valamelyest kompactalhat..
https://www.elastic.co/blog/elasticsearch-storage-the-true-story

A raw size szamoljunk 16k per keres (bele ertve a tobbelt hivasokat).
10M keres per nap 1TB -n elferhetne egy hetre viszamenoleg.

Most lehet gondolkozni mi draga, egy problema adot esetben orakkal kesobbi megoldasa,
vagy nemi CPU + storage hasznalata kozponti log elemzovel ..

En inkabb perkalnek (replikalt) storage ert  es +10% CPU -ert.
 

ES ket nagysegrendel nagyobb is lehet..
Feldolgozas ~ 1M record per sec .
Max size ~3PB.
Max record szam (hard limit) 2G .
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Bocs, nem biztos hogy teljesen értettem mit akartál leírni. Próbálok arra válaszolni amit én értettem meg belőle.

1, Leírod ismered az embert biztosan ért hozzá -> nem vitattam, semmilyen állítást nem tettem rá mert _nem ismerem_

2, Azt mondod nem értettem meg azt amit elmondott, pedig úgy gondolom a gond nálad van. Miért? Mert megnéztem a videót mivel ahogy írtam is az elején úgy éreztem végre egy ember aki már látott enterprise-t és egyre jobban negálták az előadásban felhozott példák.  Csak hogy beszéljünk valamiről amit előhoztál mivel egy későbbi elmélet vs. gyakorlat példában említettem volt gondolom: a  titkosított adat feldolgozás nagyon nem költséghatékony(hardware igényes, security problémákat is felvetm ütközhet alapelvekbe és szabályokba) és időszakos bekapcsolás van sokszor és eléggé vékony általános scope szűrés alapján, de ez egy hosszú sztori nem mennék jobban bele. Igen használnak ilyet, nem vitatom, itt az Extrahop és társai a nagypályások (annak ellenére hogy a flowmon is tud valamit kezdeni tls 1.3-al) mivel más paraméterek is számítanak. (nem a szoftveren _nevén_ hanem a szoftver adta lehetőségeken lovagolok). Még azt is el tudom képzelni hogy az előadás rövid volt és a közönséghez hangolva de akkor sajnos félrement, azt az érzetet keltette hogy amit bemutat felemás.

3, Köszönöm hogy értékeled a hozzászólásomat. Tehát ez a: 

"A videó elején határozottan úgy tűnt az előadó látott már enterprise környezetet mikor a team-ek működését írta le. Aztán az előadás bemutatta hogy nem"

mondat számodra modortalan és miben? Ugye nem abban hogy félreértelmezted és az előadót gondoltad hogy jellemeztem? Nem érzed hogy félrecsúszott valami?

Nincs bajom ha megmondod hol vagyok hülye, de most piedesztálra emeled az ismerősöd és _nem_ az előadást hanem az embert véded. Ezzel vitatkozni nem tudok, hisz az emberről semmit nem montam.

kiegeszites: a video 2019 juniusában készült.

Szerkesztve: 2021. 01. 21., cs - 13:50

A kivonatra reagáltam aztán megnéztem az előadást. Hülyeséget beszéltem ezért töröltem. 

honlapom http://dyra.eu/

A tapasztalataim szerint a teljes hálózati forgalom monitorozása nem "új" ötlet, pl egy Security Operation Center -ben is igen hasznos tud lenni.

A probléma 99%-ban a gyakorlati megvalósításával van, mert:

- a titkosított forgalmat nem egyszerű layer 7 szinten elemezni

- a mintavételezés legtöbbször fizikai korlátokba ütközik, a switch nem bírja, vagy csak 1000:1 mintát képes adni, nem teljes netflow-t, stb.

- a költségek is általában irreálisan magasak, hiszen ennek tárolására és feldolgozására kell némi hardver erőforrás is..

 

Azonban - ahogy csambi is említette - full virtuális környezetben ez a gyakorlatban is életképes (és rentábilis) megoldás lehet - persze továbbra sem olcsó móka.

Én egyszer telkó operátornál láttam olyat még integrátorként, hogy mondtam a core netwörkös csávónak, hogy üljünk már le, küldjön még pár tesztet, mert meg kellene nézni, hogy mik mennek a HLR/MSC/BSC között, meg hogy mi esik be abba, amit már én is látok. Mire megkérdezte, hogy meg tudom-e mondani, hogy kb mikor, meg hogy milyen üzenetek voltak már, és elővette a logból, hogy tessék itt van. Pislogtam rendesen :)

- komoly rendszereknel az ssl jellemzoen nem a szerveren van hanem kulon ssl offload vagy reverse proxy, ami mogott tudod nezni a forgalmat

- ha egy 10g switch teljes forgalmat rogziteni akarod, igen az draga es maceras lenne, de amivel eddig en talalkoztam ott az erdekes halozati forgalom elenyeszo volt (jellemzoen sql vagy api hivasok ide-oda, nehany 100/sec, az packetben is max 1-2kpps)

- koltseg leginkabb az adatok elemzese, vagy veszel dragan kesz univerzalis szoftvert ra vagy megfizetsz valakit aki a konkret esetre/problemara ir valamit

Netflow 10.000-20.000 dodó/év.

Jöhetnek a free alternatívák :D

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ez egy jó projekt "volt" . Ennek is vége sajnos lassan szerintem.

Ez lesz belőle:

https://www.elastiflow.com/

Még van community verzió belőle (beta) ki tudja meddig.

Egyébként egy pmacct + elasticsearch vagy pmacct+kafka-ból elég sokat ki lehet hozni. Csak hát dolgozni kell vele, nem kulcsrakész. Ez van minden open source cuccal.

 

Egyébként nem tudom most 2021-be a Flowmon mire alapoz, de régebben belenézve az appliance Os-be erősen az open source nfsen/nfdump-ra építettek.