"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 .