Sziasztok!
Sima, mezei docker konténereket üzemeltetek a docker compose segítségével. (HA nélkül, nincs se Kubernetes, se más plusz réteg)
Ma reggel jött a parancs, hogy megyünk Azureba, Openshift alá. Hurrá?
Ám előbb ki kell töltenem egy táblázatot, mert szeretnék tudni, hogy mennyi erőforrást használnak a konténereink. Eddig ilyen adatokra nem volt szükségem, így mérni se mértem.
Ismerem a "docker stats" parancsot, és kalap, kabát. Ám az csak a pillanatnyi értékeket mutatja. Rá lehet bírni (a man és a google alapján tudtommal nem), hogy a hosszú távú (mondjuk 24 óra) méréseket mutassa? Úgy is jó, ha átlagot mutat.
Ismertek erre egyszerű megoldást, lehetőleg ingyenest?
A memória fogyasztást általában limitálom, a hálózat és a diszk I/O nem érdekli őket, szóval elég lenne a CPU használatot mérnem konténerenként.
Köszi!
Hozzászólások
Első találat:
https://www.docker.com/blog/how-to-monitor-container-memory-and-cpu-usa…
Ez nem jó, a docker desktop Windows-os alkalmazás, a cég amúgy tiltja is a használatát, a benne bemutatott mérő plugin pedig nem önálló szoftver :-(
Azért köszi, még keresgélek, legfeljebb írok valami zabbixos lekérdezést, és akkor lesz grafikonom a CPU használatból.
Nézd, ha egyszerre minden lófasz menni Azure, akkor mérd a host-ot és mondd azt, hogy összesen ennyi. A helyzet az, hogy egyszerű tool-ok csak Desktop-hoz vannak, de szerintem az neked nem lesz jó.
Esetleg egy Prometheus + Grafana járható lehet, de lehet, hogy overkill beállítanod: https://grafana.com/grafana/dashboards/179-docker-prometheus-monitoring/
https://iotguru.cloud
+1, én bedobnám a teljes hostról az aktuális adatokat (vagy ha megvan historikusan, azt), hogy szumma-szummárum ennyi, és majd lehet mérni később okosan.
Épp javasolni akartam Prometheus + Grafana párost. Nekem nagyon bejött. Az égvilágon mindent le lehet vele kérdezni és megjeleníteni. Telepíteni sem nagy kunszt. prometheus-node-exporter a legtöbb linux disztróban alapból benne van, Grafana pedig mehet dockerben. Kész dashboardok vannak Grafanához, amik alapján nagyon könnyű újakat létrehozni.
Ez egy jól előkészített ukáznak látszik :D
trey @ gépház
Mondjuk, ha a jelenleg futó rendszerről sincs halvány fogalom, hogy mi mennyi hány méter benne, az is implikál némi üzemeltetési kockázatot... :D
https://iotguru.cloud
1. ezsör el fogja bírni
2. úgy csinálsz mintha nem ez lenne a szokásos tempó
Gábriel Ákos
aka mit nem értesz azon hogy "a projekt sikerre van ítélve"
Gábriel Ákos
Azért egy költségelemzés meg szokta előzni a döntést jobb helyen, mielőtt egy ilyen ukázt kiadnak :D A költségelemzéshez meg elengedhetetlen tudni, hogy mi a faszt akarnak fellapátolni a felhőbe :D
Méreteztettem már meg Azure-re dolgot Microsoft disztribútorral. Az első kérdés lesz, hogy "mégis, miről beszélünk". Arra adnak egy árat :D
trey @ gépház
Ezek nem feltétlen technikai kérdések. Mikor ki az aktuális főnök, az honnan jött. Nálunk éppen egy olyan pasas ült bele a székbe, aki az Azure felől érkezett, így kicsit érthető az irány.
Legalább két éve vergődnek, azóta már több elképzelés is volt, engem egyre kevésbé érdekel, csak végre döntsék már el, hogy elkezdhessük a teszteket.
Pletyka szinten azt hallottam, hogy minden ország fizetni fog X összeget az Azure openshiftért, akkor is, ha egy konténert sem indítunk el. Szóval erősen javasolják a főnökeim, hogy minden konténerünket rakjuk bele, ha már ki van fizetve.
Ja, hát ha ki van fizetve ... Akkor meg nem tök mindegy, hogy mi mennyi? 🤔
trey @ gépház
Nalunk milliardos bizniszt (euroban) vittek gcp-be, ami akkor, 2018 tajekan meg csak a szarnyait bontogatta, erosen hianyoztak teljesen alap funkcionalitasok is.
Volt is nagy felhordules, mert sokan meg mast akartak.
Kiderult, hogy azert, mert a menedzsment kialkudott egy igen erosen kedvezmenyes arat, amit ugye meg tudtak tenni, mert tobbezer VM migralasarol volt szo.
Jo kerdes, hogy meddig lesz kedvezmenyes az ar ugye -- mert biza' a cloud-ban meg talan durvabban van jelen a vendor lock-in, ugye a google-specifikus GCP candy-k miatt, mint cloudsql, netspanner, bigtable es meg tucatnyi egyeb. Nem fog onnan mar elmenni a ceg sehova :D Akkor meg lehet emelni az arat, ameddig az agyu csoven kifer.
Ennek kivedesere persze csinaltak egy absztrakciot, es jopar service aws-be ment, de alapvetoen maceras 2 vpc-t fenntartani, meg osszeloni/monitorozni mindent, szoval gyakorlatban csak a legnagyobbaknak eri meg.
Ráadásul itt már befigyel az egress traffic kifelé a másik providerbe ami nagyjából 2x annyiba kerül mint a bejövő forgalom
.
Vendor lock-in -ról:
Voltak ilyen jómunkás emberek akik azzal próbáltak bármi toolingot nyomni nálunk hogy ettől majd cloud agnostic lesz az egész lőfütty.
Eljött a nagy nap, migrálják a service-t az emberkék egyszercsak repkednek az incident ticketek. Nincs disk. Kisült hogy a k8s storage provider neve más, mert idézem: nem volt egyértelmű hogy nincs EBS volume GCP-ben.
Ha egyszer már elkezdtél egy szolgáltatót használni ahogy mondod nincs sok értelme mixelni mert csak szívás a vége.
Vagy a másik irány amikor mindig mindent agnosztikusra akarsz csinálni és megkötözöd magad és rengeteget szopsz olyasmikkel amikkel nem kéne.
Valahol a középút az igazság de ahhoz nagyon sok mindent kell baromi jól ismerni - az meg azért drága.
Gábriel Ákos
milliardos ceg, ugyhogy ahogy irtam, a developerek nemigen nyulnak k8s konfigba kozvetlenul, hanem egy sajat yaml-t szerkesztenek, a helyi 'translator' rendszer meg abbol csinal gcp provision-t, terraformot es kubernetes konfigot, meg millio egyeb dolgot (kibana, graphana, yadda yadda) setupol fel automatikusan.
ez a translator automatikusan allokalhat olyan cloud providernel olyan resource-t, amilyet csak akar, alapvetoen.
abban igazad van, hogy valszeg min. 1 devops support team fog kelleni hozza cloud providerenkent, de ha 200+ dev team-ed van, megoldhato es meger(heti). Gondolj bele: egy dev team havi koltsege kb. 30-50 ezer euro; ha ez az ara annak, hogy az eves cloud koltseg ne 300, csak 150-200 millio euro legyen, akkor "megeri".
crossplane? :D
Rosszabb nem lesz a jelenlegi rendszernel ahol perpill fogalmuk sincs :)
Csavar hogy annak kell uzemltetni, aki nem a donteshozo. Mondtak hogy mit akar...
Ha semmid sincs erre, akkor lehet az a legegyszerubb, ha percenkent meghivod a docker stat-ot es kiirod file-ba a szukseges szamokat. Majd egy nap mulva Excelben feldolgozod (atlag, min, max, grafikon, stb.).
Persze fugg attol, hogy csak nehany vagy sokszaz kontener fut.
írtam egy egyszerű bash parancsot, annak a kimenete a CPU pillanatnyi értéke %-ban, azt már be tudom tolni a zabbixba
Részvétem.
Ilyenkor szoktuk elővenni a monitorozó rendszer (pl Nagios, Icinga, Zabbix, whatever) grafikonokat és megnézzük akár évekre visszamenőleg a host vasak statjait.
Aláírás _Franko_ miatt törölve.
neut @
zabbixunk van, 1 évig tárolt adatokkal, jobb híján elég lesz
Offtopic:
Egy újabb elcseszett felhős migráció lesz ebből.
Valószínűleg nincs meg hozzá a megfelelő szaktudás se vezetői, se beosztotti szinten. 1-1,5 éves vergődést jósolok. De ne legyen igazam.
Ontopic:
Én is a host felől közelíteném meg. Eleve kétlem, hogy csak az OpenShiftet fogjátok használni Azure-ben. Így egy rendes kalkulációhoz pl: az Azure kimenő adatforgalma is kellene, mint paraméter.
Ha az Azure Price Calculatorban (https://azure.microsoft.com/en-us/pricing/calculator/) kiválasztod az OpenShift 4-t, akkor eleve a worker node-ok típusát (D, E, F instance) és azok darabszámát (worker node) kell megadni pár más paraméter mellett. Ezért is én a hostból indulnék ki.
Skálázni lehet később is.
nem lesz ez elcseszve :-)
a hiányzó tudást út közben majd felszedem
lesznek hagyományos VM-jeink is, nem lehet minden appunkat konténerezni
Szóval el lesz cseszve.
Aláírás _Franko_ miatt törölve.
neut @
Te már csak tudod
Igen, láttam pár olyan projectet, ahol az volt a terv, hogy "majd felszedik a tudást a srácok, jó lesz ez". Nem a te hibád lesz a bukta, hanem a döntéshozóé, aki nekimegy a dolognak így. Te csak azt teszed amire utasítanak, a felelősség nem a tied.
Aláírás _Franko_ miatt törölve.
neut @
Nem az a baj, hogy nem lehet megtanulni, hanem hogy ehhez effektív tapasztalat kell, hogy adott felhőben mit hogyan és mennyire érdemes. Ráadásul van mondjuk háromféle tier (egy szolgáltatáson belül), hatféle árral, és akkor melyikbe. Nagyon könnyen ki tudja ám a "fönökség" mutatni, hogy valójában ők nagyon jól dolgoznak, csak sajnos alul a megvalósítás nem sikerült, és "kénytelenek" egy remek outsource-be átvinni az üzemeltetést. Szóval ezekkel óvatosan kell.
Pontosan.
Láttam már olyan felhős infrát, ahol a teljesítmény problémát azzal akarta orvosolni az elkövető, hogy nagyobb vasat tett alá. Közben meg csak az volt a gond hogy a világ két átellenes részén volt a DB meg az APP szerver, aztán meg csodálkoztak, hogy lassú.
Aláírás _Franko_ miatt törölve.
neut @
Ezzel nincs baj. Mindenki tanul menet közben. A kérdés, hogy milyen áron.... :)
A legjobb, ha mas fizet a hibaidert, de a siker utan te zsakolod a hasznot. Pro szinten a buktabol is hasznot huznak, de odaig el kell jutni :)
Lehet M.Sandor helyett MS.Andor leszel a végére :D
Ez így nagyjából 10 másodperc, ha kicsit kell kattogni a portokon, meg hogy melyik IP-n figyuzzon, akkor akár öt perc is lehet:
https://prometheus.io/docs/guides/cadvisor/
Jó, mondjuk a grafikon részével már jóval több idő belőni hogy mizu, de addig is, gyűjti az adatokat.
köszi, holnap tiszta fejjel megnézem, most a scriptem percenként fájlba menti a docker stats kimenetét
Prometheus lényege, hogy adott időközönként (pl. 15 sec.) rögzíti az összes mért adatot, amik tipikusan számláló jellegűek. Innentől bármilyen időszakra le lehet kérdezni, hogy mi mennyi vagy Grafanával grafikonokat is lehet rajzoltatni, amik rendszeresen frissülnek.
Szerintem gyorsabban meglesz minden, ha legalább a Prometheust összelövöd, hogy kezdjen mérni, aztán ráérsz később lekérdezéseket írni vagy a Grafanát is beállítani.
CAdvisor, Prometheus, Grafana a barátod. Érdemes fellőni hozzá egy mimir backendet vagy hasonlót hogy legyen sok adatod nem csak 30 nap (azt hiszem az a default Grafana-ban ha local storage van használva).
Mivel fogalmam sincs milyen workloadot migráltok, de ha ez ilyen ElasticSearch vagy hasonló jóság, akkor a zone awareness -t be kell configolni mert a cross-az replikáció rendesen kiakasztja ám a budgetet ha nem figyeltek.
ezt nem értem
Mi az availibility zone Azure: https://learn.microsoft.com/en-us/azure/reliability/availability-zones-…
Mi az aviailibility zone AWS: https://aws.amazon.com/about-aws/global-infrastructure/regions_az/
Google Cloud -ot nem linkelek mert náluk az AZ ugyanabban a szerverteremben van.
Felhőben több availibility zone -ba telepítünk mert ugye szeretnénk hibatűrő rendszert kialakítani.
Kubernetes cluster workerjeit is szépen szétdobjuk külön availibility zone -ba.
Az availibility zone közötti hálózati forgalom viszont nagyon nincs ingyen és drágább mintha ugyanabba az availibility zone -ba lenne pakolva minden, hát perszehogy hiszen másik datacenterbe küldöd a forgalmat.
Képzelj el egy olyan esetet amikor hibatűrő applikációd van (mondjuk valamilyen adatbázis cluster) és az elkezdi mozgatni az adatokat nemcsak ugyanabban a szerverteremben, hanem a szervertermek között is - sokszor indokolatlanul.
Ennek a kivédésére vannak különböző beállítások amit a software vendor szépen leír hogyan kell, és ilyen apróságokra oda kell figyelni.
Ellenkező esetben oltári nagy lesz a számla fölöslegesen.
De azon mit tudsz sporolni, ha a harom ES node szet van szorva kulonbozo AZ-be es szinkronizalniuk kell egymas kozott?
Az a javaslat, hogy egy AZ-n belul legyen mindharom ES node?
Meg kell nézni kell e három vagy kettő elég. Business requirement, nem technikai probléma.
Az adatmozgatásról pedig:
https://www.elastic.co/guide/en/cloud-on-k8s/1.2/k8s-advanced-node-sche…
Kettő esetén honnan tudja, hogy melyiknél van a jó adat?
https://iotguru.cloud
Elasticnál ez kicsit másképp megy.
Az availibility zone szám ott érdekes hogy mennyi master node van, mert ők mondják meg milyen a cluster állapota.
Ha nem elérhető egy node akkor elhagyja a clustert, ha egész zone nem elérhető akkor ők is elhagyják, de a shardok nem mozdulnak a két AZ között mert nem.
Másik érv az pedig az hogy Elastik képes egymás mellé mozgatni a shard replikákat ugyanabba az AZ-be, vagy ugyanarra a gépre/podra és ha az (vagy alatta lévő mondjuk EBS volume) megpusztul akkor oda az összes adat. Ezért jó ötlet allocation awareness-t használni hogy ez ne történjen meg, és persze az hogy olcsóbb mert nem replikálgatja a shardokat egyik AZ-ból a másikba 24/7.
Az hogy kettőben lehet lehet üzemeltetni, persze nem azt jelenti hogy jó ötlet de van hogy azt mondják drága és business hajlandó bevállalni a lehetséges kiesést, minden attól függ megéri e a kockázat. Ettől függetlenül háromban ajánlott.
Ott is így megy. A legtöbb problémát a distributed rendszereknél a brain split jelenti, amiből kettő DC esetén határozottan nem lehet eldönteni, hogy kinél van a jó adat.
Lehet egyet is üzemeltetni, aztán vagy áll vagy mentésből visszatöltjük, ez is üzleti döntés.
Minimum.
https://iotguru.cloud
Shardoknál van primary meg secondary, ha valamelyik nem elérhető akkor az elérhető a primary.
https://www.elastic.co/guide/en/elasticsearch/reference/current/scalabi…
Vagyis brain split esetén lesz két primary, mindkettő azt hiszi, hogy a másik meghalt, mert nem érik el egymást, ezért kell quorum based cluster, ahhoz meg minimum 50%+1 egymást látó élő DC kell.
https://iotguru.cloud
A linkelt oldal nem magyarazza a sporolasi lehetoseget.
Ha a 3node-3AZ ES tudtara adjuk, hogy melyik node melyik AZ-ben van, es bekapcsoljuk az allocation awarenesst, akkor az shardokat ugy allokalja, hogy a primary es a secondary copy masik AZ-be essen. Ettol nem lesz kevesebb a cross-AZ network forgalom.
Ha a 6node-3AZ (tehat AZ-nkent 2 node) ES eseten veletlenul se fog egy AZ-be esni a primary es a secondary copy, tehat ettol se lesz olcsobb a cross-AZ forgalom.
Csak azzal tudunk sporolni, hogy ha szandekosan egy AZ-be tesszuk a primary es a secondary copyt, de akkor lottek az AZ szintu redundancianak.
Ettől nem lesz kevesebb a cross-AZ network forgalom.
- szóval ha az elastic úgy dönt hogy márpedig most mozgatja a shardot (márpedig mozgatja gyakran mert több TB adatnál ez így van ILM policyval), szóval mégis hogyan ne lenne már olcsóbb a forgalom ha nem mozgatja AZ-k között amikor mondjuk megpusztul egy pod vagy éppen hot ból warm vagy cold tierre mozgatja?
Csak azzal tudunk sporolni, hogy ha szandekosan egy AZ-be tesszuk a primary es a secondary copyt
- ez nem igaz, fentebb írtam miért nem.
https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-cos…
Van egy olyan sejtésem hogy nem tapasztalatból írsz.
Fentebb azt allitottad, hogy ha beallitjuk az allocation awarenesst, akkor azzal sporolni tudunk. Most meg azt, hogy ettol tenyleg nem. Fogalmazhatnal vilagosabban/pontosabban.
Tehat akkor most a shard rebalancing a tema, nem pedig az adat iras miatti szinkronizacio.
Failure scenario eseten a rendelkezesre allas fontosabb szokott lenni, mint az okozott extra koltseg. Szerintem.
Na vegre, ez egy jogos pont lehet.
Tehat osszefoglalva amit szerettel volna irni (es ugy kellett kihamozni tobb kommentbol): public cloudban vigyazni kell az ElasticSearch-csel, mert multi-tier cluster eseten a shard rebalancing soran jelentos cross-AZ halozati forgalmat generalhat, amit jelentosen csokkenthetunk, ha jol beallitjuk az allocation awarenesst AZ hatarra, igy a shard allocation soran azt figyelembe tudja venni.
Fentebb azt allitottad, hogy ha beallitjuk az allocation awarenesst, akkor azzal sporolni tudunk.
- most is azt állítom.
Ellenben te állítottad azt hogy nem nem fogunk spórolni: https://hup.hu/comment/3018410#comment-3018410
Tehat osszefoglalva amit szerettel volna irni
- pontosan azt írtam.
Használd csak a ctrl+f/cmd+f-t, ki is írta ezt: "Ettől nem lesz kevesebb a cross-AZ network forgalom." arra válaszoltam csak nem idéztem hanem így reagáltam:
commented
- válasz.
Mivel bizonyos esetekben nem működik rendesen a formázás és szétb a postot.
Az a probléma forrása, hogy a megfogalmazásod szerint azonos szolgáltatási szint és üzemeltetési kocskázat mellett megoldható a probléma. Pedig nem, csökkenni fog a szolgáltatási szint és/vagy növekedni az üzemeltetési kockázat azzal a beállítással, amit írtál. Ennek bevállalása lehet üzleti döntés, ahogy akár az is, hogy egy darab ES node lesz és kész, de ez nem megoldás a problémára.
https://iotguru.cloud
Ha saját fejlesztés: Egyébként ezt biztos neked kell megmondani? A program fejlesztője nem lehet, hogy jobban képben van?
A fejlesztő honnan tudná megmondani, hogy az éles környezetet éppen mennyire terhelik az ügyfelek?
Mellesleg egyelőre csak egy beszállító ad konténereket, az összes többi appot én állítottam át, már amit tudtam.
Nekem az openshift/k8s egy csatahajó, semmi szükségem rá, jól megvoltam eddig is a docker compose-al. Abból a szempontból örülök a váltásnak, hogy így ezt is meg fogom tanulni.
Honnan? Hát mondjuk ránéz a dashboardra ami elérhető minden fejlesztő meg admin meg akárki számára a cégnél így bárki bele tud ásni ha ki kell deríteni mi döglött meg a valami ami a pénzt hozza.
Nem mindenhol természetes, hogy odaeresszék a beszállítót az éles rendszernek akár a dashboard-ja elé. :)
Foleg ha mindenfele opensource szoftvereket hasznalunk.
Nem azt tudja, hogy éppen mi történik, hanem becsülnie kell tudni. Tudja, hogy mit csinál a program, mennyi felhasználó van, stb... ez tipikus fejlesztői vagy architekti/beszállítói feladat.
:D
Na, kiröhögtem magam. Szóval eszembe jutott egy meló, egyik banknál, ahol vettek egy szoftvert, ami AS/400 vasra volt tervezve, de épp nem volt ilyen vas, szóval önerőből kitalálták, hogy akkor fusson emulátoron, kértek is a divízió hardverbeszállítójától rá hardvert, ami épp az Oracle volt és pont a Niagara vassal házalt, el is adott egyet jó pénzért, rátették a Solaris, arra rákókányoltak valami Linux libeket, arra rá az emulátor, majd az emulátorba bele a szofvert. A szoftver elvileg a kártyás vásárlásokat processzálta és számolta belőle a visszatérítéseket merchant kód és rule engine alapján, naponta egyszer, ment a szolid marketing kampány, aztán azt látták, hogy a napi batch futási ideje 16 óra, 17 óra, 20 óra, és hát látták, hogy nem lehet ebből ügyfélkört növelni. Na, itt szóltak, hogy külsős szakértőként van-e valami ötletem, mert a szoftver gyártóját nem merik megkérdezni, mert halvány licencsértés van... na, az volt, hogy a szoftver egy szálra volt megírva, nyilván, mert az AS/400 egy szálas teljesítménye viszonylag jó, a Niagara meg sok szálra kitalált dolog, ott pörgött egy mag, 127 meg nézte és böködték egymást, hogy figyelj, meg fog dögleni. Na, alátettek x86-ot és SSD-t és megjavult valamennyire...
...szóval van olyan, hogy a fejlesztők vagy a beszállítóknak halvány fogalmuk nincs arról, hogy a szarjukat hogyan is futtatják a jómunkásemberek.
https://iotguru.cloud
Igen, igazad van. A dolgok másik oldala, hogy ha egy fejlesztőt kérdeznek meg, hogy min fusson, akkor nagyon gyorsan a 4-es, majd a biztonság kedvéért inkább a 8-as szorzóval fog előállni. :)
Ez nem a szorzóról szól, de például az említett esetben a beszállító cég fejlesztői milyen becslést adjanak a vas igényére? Natív AS/400 szoftver, így fejlesztik, így adják el, így támogatják. Ha pedig n+1 beszállítói és n+1 emulációs rétegen egy architekturálisan alkalmatlan vason fut, akkor kinek a hibája, hogy töredékét tudja annak, amit a beszállító mond? Mire megy az adott bank azzal, hogy a beszállító becsül?
https://iotguru.cloud
X memória, Y konkurens felhasználás, ezért Z szál, Ennyi disk IO, stb...
Nem tudnak mást megkeresni egy új rendszer esetén, mert az üzemeltetőnek fogalma sem lesz egyedül, hogy min futtassa a dolgokat. Jobb esetben mindenkin átmegy a becslés. Vagy oké, lehet más a megközelítés: adott, hogy min kell futnia valaminek.
De felhőben talán ez kisebb probléma lehet, ha meg lehet úgy oldani, hogy egyszerű/esetleg automatikus legyen a felskálázás.
A beszállító egy natív AS/400 rendszerre gondolom azt mondja, hogy az a rendszer AS/400-on fusson. Létezik valami emuláció, amivel már máshol is futhat? (Amúgy az production ready dolog? Egy kritikus üzleti alkalmazást rá lehet arra bízni, vagy tanulásra van? Azért egy AS/400 komolyabb rendszer, esetleg ott is lehetnek licensz kérdések, már eleve a DB2-vel, oprendszerrel. Tanuláson, hobbizáson felül jó-e egy ilyen emulátor bármire is? Tudom, hogy van valami System/370-re-re pl. )
Hallottam amúgy cégeket, akik vállalják, hogy átkonvertálják neked a régi mainframe programodat, de a gyakorlatban szerintem ott újraírás mehet a legvégén, mondjuk Cobolból vagy RPG-ből JAVA-ba. Nem tudom.
Ezek semmit nem mondanak egy teljesen más architektúrán vagy környezetben.
Na, látod, ezek azok a kérdések, amire a válaszokat nem feltétlen adják tovább a beszállítónak... :D
https://iotguru.cloud
Hát, a saját utak járása mindig egy nehezebb feladat. :)
Onnan, hogy voltak teztek. Peldaul elvegeztek a performance test-et hogy megnezzek megfelel e a kovetelmenyeknek, es esetleg erre meg radobtak a stress test-et, hogy kinyomjak a szemet is, hogy megnezzek mennyi a maxiumum amit elbir. Innen azert aztan lehet kovetkeztetetni, hogy megfelelunk e majd es hol vannak a hatarok.
Persze azt nem a fejlesztonek kellelvegeznie egy nagyobb rendszeren vagy microservice architecturan, hanem majd az automata tesztelok megirjak a teszteket. A management majd dont.
Nagyon kevesen értenek a rendes (holisztikus) architektúra tervezéshez és teszteléshez.
Még kevesebben vannak akik szemébe merik mondani a menedzsmentnek ha fasságokat beszél.
Gábriel Ákos
És ha a szemébe is meri mondani, rögtön akad kettő másik, aki azt fogja mondani, amit hallani akarnak. :)
Igen, én is így gondolom, persze teszteket lehet és kell is csinálni. Az egy jó dolog, ha van olyan környezet, ahol használható lesz az eredmény (méretre akár, vagy integrációk szempontjából), és minden egyéb szempontból el lehet végezni a tesztet.
Automata tesztelők: cégeknél, ahol ez külön értelmezett (tehát nem csak a "fejlesztő" megnevezés van, és azon belül mikor milyen sapka), és ha vannak, akkor a feladathoz is kellően talpraesettek.
"Onnan, hogy voltak teztek."
Pontosan. Én igen kevés ilyesmiben vettem részt, de mindig az volt a vége, hogyhátigen, cpu, io, memória, paketta, csiribú-csiribá, húdejóleszez, deeeee izéna, azért adunk egy teszthardvert, mert... hát... na, azért jobb félni mint megijedni.
Nem igazan ertem. A kontenerben futo process az a host-on fut, az hogy be van zarva egy namespace-be nem valtoztat semmit. A cpu hasznalata annyi lesz amennyi. Ha tudod miket futtattok, mi a process, csak monitorozd nyugodtan barmilyen eszkozzel a host-on es kesz. Annyi lesz a cpu hasznalata. Meg a memoria meg a satobbi.
Nem mindig triviális eldönteni mondjuk a futó 523 httpd/apache processzről, hogy ki kivel van. Same in english ha pl. mysql. Meg még tuti van egy vödör efféle motyó.
Jo, hat ha a container hoszton meg futnak standalone LAMP stack-ek is szamolatlanul az mas. Meg meg anyamkinnyatuggya mire masra is hasznaljak. :D (nem tartom jo otletnek)
De ha csak container host akkor siman a process-eket kell monitorozni es kesz.
Najo, de melyik az a barmelyik eszkoz, ami namespace-ek alapjan osszegez? Pl.:
fisher@s2:~$ sudo ps -eo comm,pidns| grep apache2
apache2ctl 4026532705
apache2 4026532705
apache2 4026532705
apache2 4026532705
apache2 4026532705
apache2 4026532705
apache2 4026532705
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026533343
apache2 4026532851
apache2 4026533343
apache2 4026532851
apache2 4026532851
apache2 4026532851
Es meg millio egyeb sor.
Ugye eddig volt a cadvisor, illetve van zabbixuk is, de nem tudom milyen verzio, nem biztos hogy azt akarnam kiokositani. Szoval ja, ezt a "barmelyik eszkoz" kb. olyan "google" szeru valasznak tunik nekem.
Mi a baj a cadvisorral? Pont erre való.
ooo, egy kontener egy namespace, de nem is errol van szo. Ha a host kizarolag kontenereket futtat, akkor kb, minden processt monitorozni kell es kesz. Az afdja a host terheleset. Ha apache, akkor meg az apache2 processeket.
Ha az a cel, hogy a containerek szerint monitorozd, akkor pl pont a zabbix es a nagyok jok ebben (meg a kicsik is :), mivel ugy csinaljak, hogy a metaadatokat kiszedik a container runtime-bol es hozzaadjak a metrikakhoz mint labelek, tag-ek. A container runtime adja az osszes informaciot ehhez.
Ha tehat sajataot akarsz irni, akkor korulbelul ugy kell megirni, hogy lekerdezed az osszes containert a runtime-tol, elraktarozod hogy mik a metaadatok, majd monitorozod a process-et (dockernel peldaul Status-ban van az eredeti pid). Majd rogzited az adatokat. De korulbelul ezt csinalja mindegyik. Nezd meg a forraskodjat mondjuk a prometheus docker-exporter-nek.
De ha ez nem eleg valasz, akkor megirhatok neked egyet vagy ha adsz hozzaferest hat telepitek a rendszeredbe valamit. :D
Természetesen nem arról van szó, hogy a döntéshozóember jártában-keltében talált egy cuki színes website-ot, vagy esetleg kapott egy reklámtollat vagy bögrét. (Pláne nincs szó arról, hogy a technológiai döntések rendszerszerűen így történnènek.)
cadvisor + prometheus + grafana
Ezzel megy kb. az openshift is belül.
Ha csak az a baj, hogy hosszú távú adat kell, de a docker stats csak a pillanatnyit mutatja, akkor a kimenetét kitolod egy logfile-ba. Ezt vagy beteszed egy ciklikusan lefutó cron job-ba:
/5 * * * * docker stats --all >> /path/to/logfile
Vagy egy végtelenített loopot használó scriptbe:
while true; do docker stats --all >> /path/to/logfile; sleep 300; done
Ez így 5 percenként belerittyent a logba. Ha ritkábban kell, akkor növeled a sleep mértékét, vagy átírod a cron-t. Később ezt a logfile-t fel lehet dolgozni awk-kal vagy cut paranccsal, és akár gnuplot-tal is lehet ábrázolni.
Megoldás lehet az is, hogy az egész host-ot monitorozod, ahogy már előttem írták. Akkor az uptime-mal tudod a load average értékeit monitorozni, logolva épp úgy feldolgozni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)