A kerdes elmeleti, de munka altal inspiralt.
Ahogy magunk mogott hagyjuk a monolith-okat es egyre divatosabb az elosztott architectura (ismet) felmerul a kerdes, hogyan bizonyosodsz meg rola, hogy a termeked valamennyi komponense a helyzet magaslatan all?
Kb. mindenhol latom tobbszor alahuzva, hogy komolyan kell monitorozni az osszes service-det, de minden tutorial kozponti monitorozast javasolt. Felmerult bennem, hogy ha a service-eid kulonbozo data center-ekben vannak, a halozati topologia nem trivialis vagy mindenfele API key-ek megfelelo konfiguracioja is kozrejatszik, akkor hogyan bizonyosodsz meg rola, hogy az egymassal kapcsolatban allo service-k latjak egymast es egyutt tudnak mukodni?
Persze vannak lehetosegek, peldaul kapcsolt service health check-jet monitorozni magaban a service-ben, esetleg bennefoglalni a sajat health data-ban, de a problema altalanosabbnak tunik.
Ti tudtok valami framework-rol, ami erre lenne kitalalva? Vagy valami eszmefuttatas elosztott rendszerek fuggosegi grafjarol?
Fórumok
Hozzászólások
"Ahogy magunk mogott hagyjuk a monolith-okat es egyre divatosabb az elosztott architectura"
Szerencsére sok cég kezdi felismerni, hogy nem feltétlenül érdemes ész nélkül megülni ezt a divathullámot (pl.: https://www.infoq.com/news/2020/04/microservices-back-again/).
"ha a service-eid kulonbozo data center-ekben vannak"
Én Prometheust használok ilyen rendszerek monitorozására, minden DC-ben van egy Prometheus "cluster". Federationnel tudod központosítani is őket, de önmagukban is funkcionálnak.
"a halozati topologia nem trivialis"
A service-eknek mi közük van a hálózati réteghez? Nem az ő feladatok biztosítani és felügyelni a hálózati infrastruktúrát, így a microserviceek szempontjából irreleváns a hálózati topológia, vagy a hálózat működőképességének monitorozása.
"mindenfele API key-ek megfelelo konfiguracioja"
Rengeteg dolog van, amit egyesével lehetne monitorozni, de végereményben egy fenntarthatatlan és megbízhatatlan monitoring rendszer lesz az eredménye, végtelen befektetett munkával és millió fals pozitív riasztással. Érdemes tüneteket monitorozni (error logok száma elezdett növekedni az elmúlt 10 percben) okok helyett (nincs beállítva az API key, nincs beállítva jól a DB kapcsolat, packet loss van, ...stb).
ha az okokat nem monitorozod akkor hogy tudsz azonnal rámutatni hogy na oda kell nyúlni mert ott lesz a probléma? én is szembesülök ezzel a gonddal hogy túl sok mindent monitorozok és amikor valami nem megy akkor annyi riasztást kapok hogy igazából esélyem sincs megmondani hogy mi a gond belőlük, szóval valamit rosszul csinálok az biztos:)
A service-ed logolja, hogy mi a probléma (unable to connect xy service, invalid API key, cant connect to database, etc.). Monitorozod a hibalogokat, ha elkezd felfelé menni a log bejegyzések száma kapsz riasztást, belenézel a logokba.
Hidd el, nem fogod tudni az összes okot monitorozni (és nem is jó irány). Én pont a napokban futottam bele olyanba, hogy egy service API token problémával nem tudott csatlakozni egy másik (külsős szolgáltató) service-éhez. Az API token-be bele volt kódolva egy timestamp, a másik oldalon volt egy egy perces elcsúszás, így mikor a másik oldal validálta a tokent, akkor visszadobta, hogy ez bizony invalid. És ez csak egy példa, rengteteg ilyet tudnék mesélni. Ezekre ha beleszakadsz, akkor sem fogsz tudni monitoringot építeni.
A halozati topologia ott jon kepbe, hogy oke, hogy nekem van service A es service B, tudom mindkettot monitorozni es latom, hogy mindketto el es virul. Ez csak arrol ad informaciot, hogy elnek es a monitorozo eszkoz eleri oket, arrol nem, hogy ok elerik-e egymast es tudnak-e kooperalni.
> Rengeteg dolog van, amit egyesével lehetne monitorozni, de végereményben egy fenntarthatatlan és megbízhatatlan monitoring rendszer lesz
Igen, ezert keresek valamilyen olyan altalanos megoldast, ahol az uj service deploy utan rogton elmondja, hogy marpedig neki ezek a szolgaltatasok fognak majd kelleni es panaszkodjon, ha ebbol valamit nem er el. Ne kelljen megvarnom a hetfo reggel nyolcat par elegedetlen felhasznaloval, ha elore lehetne tudni, hogy valami nem fog mukodni.
+1 mi atvertuk a deveken, hogy tessek top-down funkcios exportereket epiteni az alkalmazasba (ezekbol ok kapnak riportokat is, szoval sikerult nem monitor-centrikusra rajzolniuk). es mi is alkalmazasfuggo logokat figyelunk nagyban (mtail nagy barat (kozepesen jofej program :D )). plusz a job scheduler (nomad) is jol kerdezheto. halozati reteg/topologiara visszavezetheto "problema" nem is tudom mikor volt legutobb. tavaly?
Hali!
Erre a problémára találták ki az orchestrator rendszereket, mint kubernetes,dc/os. Van olyan funkciójuk, hogy figyelik az adott service-t és ha az látszik hogy behalt akkor képesek újraindítani és le/fől skálázni terhelés függyvényében. Valamint van beépitett központi monitoring funkciójuk is plussz még telepíthetők hozzá 3rd party toolok is amivel lehet bőviteni a tudásukat.
Üdv,
Mi van akkor, ha nem minden service van általad fejlesztve, és általad deployolva?
Például az alkalmazásod használ egy 3rd party service-t, amit te csak felhasználsz, de nem te fejlesztes és nem te deployolsz. Hogyan monitorozod k8s-sel ennek a service-nek az elérhetőségét?
feltehetőleg tudod hogy az adott servicetől milyen működést vársz el (ez általában egy adott port vizsgálata, vagy akár hogy egy adott porton való üzenetre válaszol). Teljesen mindegy ki fejleszti, ha te deployoltad, akkor te irod hozzá a liveness/readiness probeokat is.
De nem én deployolom! Mondjuk használok egy 3rd party által valahol elérhetővé tett szolgáltatást (például Google valamilyen szolgáltatását, Salesforce szolgáltatását, Pistike Bt. szolgáltatását). Őket hogyan monitorozom k8s eszközökkel, ha nem én deployolom, csak felhasználom.
Ez egy külső szolgáltatási függés, ami ugye a szolgáltatásorientált architektúrákban (a microservice-k is ilyenek) teljesen elfogadottak (lásd FaaS modellben rendelkezésre bocsátott szolgáltatások például).
Az alkalmazásom működéséhez szükségesek ezek a külső szolgáltatások, így ahhoz, hogy az alkalmazásom állapotáról képet kapjak, tudnom kell a külső felek által biztosított szolgáltatásokat is monitorozni. Őket is tudom monitorozni k8s-ben? Nem a k8s menedzseli ezeket a szolgáltatásokat, tudok hozzájuk readiness/liveness probe-ot definiálni?
Segítek: nem tudok, nem szkópja ezeknek az orchestrator eszközöknek ez, pedig az alkalmazásomhoz kell.
Lásd: https://github.com/kubernetes/kubernetes/issues/77738
Csak úgy tudod ezt megtenni, hogy készítesz és deployolsz egy saját wrapper szolgáltatást, ami semmi mást nem csinál, mint proxyzza a külső szolgáltatást.
Minden servicet (legyen az külső, vagy belső) fault tolerant módon kell integrálni. Ehhez vannak patternek, meg azokat megvalósító libek. Lásd Java: resilience4j. Ezt a funkcionalitást kiviheted lentebbi rétegbe, és a pod-od mellett futtatod, kvázi proxyként. Sidecar/service mesh -re keress rá. Kapcsolódó témakör a "reactive system".
Ez egy ortogonális dolog a monitoringra.
Az, hogy valami hibatűrően van integrálva (circuit breaker, default fallback, retry policyk stb.) segítségével, az teljesen független attól, hogy monitorozni akarom azt a komponenst, ami így van elkészítve. Hiszen ha szó szerint kell érteni, amit mondasz, akkor hibatűrően integrált komponenst nem kell monitorozni, hiszen hibatűrően van integrálva. Ez értelmetlen.
Ezek szerint ha hibatűrő minden komponenseim, nem kell monitorozni semmit. Azaz ha a rendszerben állandósul az az állapot, hogy egy hibatűrő komponens állandóan a fallback működést választja, akkor erről nem tudok értesülni, mivel nincs monitoringom, mert hibatűrő rendszerre minek. Viszont én szeretném tudni a kivételes állapot meglétét, azért, hogy be tudjak avatkozni, és az elvárt állapot felé tudjak haladni. Ehhez meg monitoring kell.
Attól, hogy a komponensem hibatűrő, azaz a felhasználó felé mondjuk sosem jut el hibajelzés, mert mindig van retry, fallback stb, attól még a rendszer eredménye nem az elvárt lesz. És fel kell tudnom deríteni, hogy melyik ponton kell beavatkozzak, hogy annak ellenére, hogy katasztrofális hiba nincs, mégis az elvárt viselkedést tudja nyújtani a rendszer. Ehhez pedig monitoring kell, a külső függésekre is.
Amikről beszélsz (sidecar, proxy stb), csak eszközök arra, hogy alapvetően nem erre felkészített rendszert körbe tudj csomagolni hibatűrést implementáló eszközökkel. Ezek csak kalapácsok, de nem segítik elő annak az elvnek a megvalósítását, hogy szeretném tudni, hogy a rosszul viselkedő rendszerembe hol kell beavatkozzak, hogy ne a kivételes(de leállást nem okozó), hanem az elvárt működés legyen a rendszer állapota. Ehhez meg kell tudnom figyelni a rendszer állapotát, azaz monitoring kell.
Nem azt mondtam, hogy nem kell monitorozni, csak látszólag elment egy kicsit másik irányba ez a thread.
Itt fentebb írtátok, hogy ha rengeteg mindent monitoroz az ember, az túl sok adat, mások írták, hogy logot érdemes monitorozni. Mindkettő igaz. Érdemes külön választani az alertinget meg a monitoringet. Előbbi nyilván mért adatokra építkezik. A fejlesztőgárda dolga meghatározni azt, hogy mi üti ki a biztosítékot, mikor kell ránézni a rendszerre. A log alapú alerting egyébként tapasztalataim alapján elég jó irány, feltéve, hogy a fejlesztők megfelelően használják a log leveleket. A fault tolerant rendszer azért jó, mert az általad is említett "beavatkozás" ritkábban szükséges.
Amit én (meg ahol dolgoztam) monitoroztam a teljesség igénye nélkül: service response time, request rate, circuit brakerek állapota, log (level szinten), instance verziók, egyéb magasabb szintő (business) metrikák, ami egy webshop esetén kb. ilyesmi lehet: rendelések száma, félbehagyott rendelések száma, első oldalbetöltés és vásárlás közti idő, böngésző alapú statisztikák, stb. Ezek legnagyobb része akkor kell, amikor már tudod, hogy hiba van és be akarod azonosítani a forrást. Mindezt folyamatosan követni egy nagy alkalmazás esetén kb. lehetetlen. Aggregált adatok (min, max, átlag, p75, p90, p99, p999) szintén kellenek. Prometheus, Graphite, Grafana, Splunk, Micrometer (java), stb. toolset javasolt.
Ha egy te általad ellőtt requestre akarod megnézni a "call" stacket, olyan értelemben, hogy melyik service hívás mennyi idő volt, ahhoz meg hasznos a distributed tracing (pl. Zipkin).
Olyan szoftverről, amit felraksz és varázsütésre mér minden releváns dolgot (de nem többet), meg szól, ha baj van (megfelelő alerting), nem tudok, de kétlem, hogy lenne univerzális megoldás.