Éveleje a fogadalmak időszaka. És ez kiváló alkalom arra, hogy elhatározzuk, megtanulunk valami új dolgot vagy elérkezettnek látjuk az időt a karrierváltásra, és megnézhetjük mit tartogat nekünk a felhő.
A felhő egy kikerülhetetlen szereplő és az AI térhódításával még hangsúlyosabb, hogy alapos ismeretünk legyen ezen a területen. És ekkor merül fel a kérdés: Vajon melyik felhőszolgáltató a legjobb? Melyiket válasszam?
Ebben szeretnék neked segíteni legújabb videó sorozatommal, mely röviden bemutatja mindhárom felhőszolgáltatót.
Egy korábbi cikkemben egy sajátos összehasonlítást végeztem a felhőszolgáltatók között.
Ennek első része röviden ismerteti az Azure azon előnyeit amelyeket én elsőre fontosnak tartok és szerintem kezdők számára ez lehet a legkényelmesebb választás.
Ezeket érintem:
Miért Azure?
Biztonsági előnyök
AI és Power Platform
Gyakorlati előnyök
Ha szeretnél ebben az irányban tisztábban látni, érdemes követned a további cikkeimet és feliratkozni az InfoPack hírlevélre vagy a YouTube csatornámra.
Amikor pár éve az AI megjelent, sokan érezték úgy, hogy „elveszik a munkát”. Erről, sokat beszéltünk a képzéseimen is. Aztán kiderült, hogy nem elvette, hanem átalakította. Kevesebb manuális feladat, több kreatív dolog. Kevesebb tűzoltás, több tervezés. Már akkor is azt jósolták, hogy hamarosan az AI írja a programokat és alkalmazásokat.
Azóta is ugyanez történik újra, csak gyorsabban.
Az utóbbi hónapokban egyre gyakrabban látom azt, hogy fejlesztők nem azért írnak kevesebb kódot, mert lusták lennének, hanem mert nincs már értelme mindent kézzel megírni. Az AI nem „segít”, hanem konkrét munkarészeket vesz át. És ez most először nem elméleti vita, hanem napi gyakorlat.
Egy friss írásban a Anthropic vezérigazgatója, Dario Amodei egészen konkrét állítást fogalmazott meg: szerinte 6–12 hónapon belül az AI képes lesz elvégezni a szoftverfejlesztők munkájának nagy részét, akár egészét is.
Ez a mondat önmagában félrevezető lenne. A részletek viszont sokkal érdekesebbek.
Amodei szerint az Anthropicnál már most dolgoznak olyan mérnökök, akik egyáltalán nem írnak kódot. Az AI generálja, ők pedig szerkesztik, ellenőrzik és döntéseket hoznak. Ez nem kísérlet, hanem működő munkamodell.
Az állítások szerint ehhez a Claude Opus 4.5 modellt használják, és az Anthropic egyik új terméke, a Cowork, szinte teljes egészében AI által generált kóddal készült el, nagyjából másfél hét alatt. A projekt mögött álló Boris Cherny pedig azt nyilatkozta, hogy az elmúlt hónapban a Cowork-höz való hozzájárulásainak 100%-át AI írta, ő pedig szerkesztett és irányított.
Ez fontos pont: nem arról van szó, hogy „a gép mindent megold”, hanem arról, hogy a fejlesztői munka súlypontja eltolódik.
És itt jön az a kérdés, amit szerintem érdemes feltenni. Nem az a kérdés, hogy eltűnnek-e a fejlesztők. Hanem az, hogy mivé válik a fejlesztői munka, hol lesz az emberi hozzáadott érték, és mit jelent ez cloud, DevOps, architect és platform oldalról.
Amit ma az AI nagyon hatékonyan csinál, az a repetitív, szabályalapú munka. API-k váza, CRUD logika, config fájlok, pipeline-ok első verziói, Terraform sablonok. Ezek eddig is sok időt vittek el, és kevés valódi üzleti döntést igényeltek. Ha ezt átveszi egy eszköz, az nem veszteség, hanem felszabaduló kapacitás.
Viszont vannak határok, és ezt az eredeti cikk is hangsúlyozza.
Több, egymástól független szakember is kritikát fogalmazott meg. David Heinemeier Hansson, a Ruby on Rails megalkotója szerint az AI-alapú kódolási eszközök még nem érik el egy junior fejlesztő megbízhatóságát, különösen akkor, amikor valódi üzleti rendszerekről, nem pedig demókról van szó.
Hasonlóan óvatosan fogalmazott Matt Garman, az Amazon Web Services vezetője is. Szerinte a junior fejlesztők kiszorítása rövid távon hatékonynak tűnhet, de hosszú távon veszélyes, mert ők jelentik a jövő szakmai utánpótlását. Ha nincs tanulási út, nem lesz tapasztalt szakember sem.
Sok fejlesztő gyakorlati tapasztalata is ezt erősíti meg. Az AI gyakran jól működik izolált példákon, de valós rendszereknél rendszeresen hibázik – én is sokszor tapasztalok hasonlókat – , főleg igen speciális esetekben és biztonsági kérdéseknél. Ezeknél a hibáknál pedig nem hivatkozhatunk arra, hogy „ezt az AI írta”.
Cloud és DevOps szemmel nézve számomra egyértelmű a kép. Kevesebb lesz a kézzel írt kód, de nagyobb lesz a felelősség. Több architekturális döntés, több költség- és security kompromisszum, több platform-szintű gondolkodás. Nem az tűnik el, aki ért a rendszerekhez, hanem az a szerep, amely csak végrehajt.
Az eredeti cikk konklúziója szerint a szoftverfejlesztői szakma nem szűnik meg, de példátlan tempóban alakul át. A mérnökök egyre inkább olyan szerepbe kerülnek, amit talán legjobban úgy lehet leírni, hogy AI-t irányító és felügyelő szakemberek lesznek. Kevesebb aktív gépelés, több döntés, több kontroll.
Ha ebből egy dolgot érdemes hazavinni, az szerintem ez:
Nem az a kérdés, hogy az AI tud-e kódot írni. Hanem az, hogy te tudod-e, mit miért íratsz meg vele.
Ha ezek a kérdések benned is felmerülnek, érdemes róla beszélni. Írj nyugodtan, szívesen megosztom a saját tapasztalataimat.
Itt az év elején kiváló alkalom kínálkozik arra, hogy megválaszoljam az egyik leggyakrabban felmerülő kérdést a cloud világában, amit rendszeresen feltesznek nekem a diákjaim és a mentoráltjaim is:
Azure, AWS vagy GCP?
Ez a kérdés szinte mindenkinél előjön. Kezdőknél, karrierváltóknál, de még olyanoknál is, akik már dolgoztak valamelyik platformmal. Megnézel pár videót, elolvasol néhány cikket, és könnyen azt érzed, hogy most azonnal döntened kell. Mintha ez egy végleges választás lenne.
Én viszont mást tapasztaltam. Az elmúlt években többször változott, hogy melyik platform áll közelebb hozzám, és ez teljesen rendben van. A cikk végén el is árulom, 2026 elején én személy szerint melyiket kedvelem jobban – és miért.
Ez az írás nem egy részletes összehasonlítás, hanem egy iránymutatás és gondolatindító, amely segít csökkenteni a döntés körüli bizonytalanságot.
Ez azt jelenti, hogy hosszú távon egyik platform sem korlátoz technikailag. A különbség inkább ott jön elő, mennyire könnyű elindulni és átlátni, hogy mi történik a háttérben.
Azure – érthető nyelv, strukturált gondolkodás
A Microsoft Azure egyik legnagyobb előnye az őszinte, egyértelmű elnevezés.
Ez tanulás közben óriási segítség. Nem kell egy külön „cloud nyelvet” megtanulnod ahhoz, hogy megértsd az alapokat, hanem mindent úgy használhatsz, ahogy eddig hallottad, olvastad vagy tudtad.
A portál megjelenése sokszor konzervatív, de cserébe nagyon jól támogatja az átláthatóságot. Az erőforráscsoportok, címkék és szűrők segítenek rendet tartani, ami később költség és üzemeltetés szempontjából is kritikus.
Fontos különbség kezdőknek: az Azure felülete és dokumentációja magyar nyelven is elérhető. Ez nem kötelező, de az elején komoly mentális terhet vesz le a válladról. Azt azonban fontos szem előtt tartani, hogy a magyar nyelv gépi fordítású, tehát bizonyos esetekben nem a legkellemesebb olvasni azt. Ezen felül a portálon is észrevehető több esetben hogy egy-egy szolgáltatás több néven szerepel, attól függően, hová kattintunk. Ez zavaró lehet.
2026. elején az Azure iránti érdeklődés különösen erős az AI-integrációk miatt, főleg az OpenAI-hoz kapcsolódó szolgáltatások és az enterprise fókusz miatt.
AWS – cloud-native szemlélet, maximális rugalmasság
Az Amazon Web Services filozófiája más. Itt szolgáltatásokban gondolkodsz, nem projektekben.
A konzol letisztult, gyors, viszont nem mutat meg mindent egy helyen. Kezdőként ez zavaró lehet, később viszont sokkal hasznosabb lehet, mert nagy rendszereknél jobban átlátható, ahol egy-egy szolgáltatást szeretnénk csupán egyszerre kezelni.
Az integrációk erősek, az automatizálás természetesen konfigurálható, a cloud-native irány itt nagyon hangsúlyos. Ha valaki szeret mélyebben rendszerekben gondolkodni, az AWS kiváló terep.
A klasszikus nehézség a jogosultságkezelés. Az IAM nagyon erős, de kezdőként könnyű túlbonyolítani. Ha egyszer összeáll a kép, utána már nem probléma – de az elején hosszabb a tanulási folyamat. Ezt tovább nehezíti, hogy kifinomult jogosultságokat több módon is be lehet állítani, amelyeket nagyrészt JSON objektumokon keresztül érhetünk el. Semmi esetre sem hátrány ez, csupán egy lassabban elsajátítható tulajdonság.
Fontos különbség: AWS esetén nincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el.
GCP – mérnöki logika, adat és AI fókusz
A Google Cloud Platform sokszor kevesebb figyelmet kap, pedig technikailag nagyon erős.
A GCP egyik legnagyobb előnye a letisztult, mérnöki megközelítés. Sok szolgáltatás mögött ugyanaz a technológia van, amit a Google saját rendszereinél is használ. Ez különösen az adatfeldolgozás és AI területén érződik.
A felület általában egyszerűbb, kevésbé zsúfolt, mint a másik kettőnél. Elsőre is könnyű átlátni, mi történik, viszont kisebb az „enterprise cucc”, mint Azure vagy AWS esetén. Ez nem azt jelenti, hogy nem alkalmas nagyvállalati megoldások megvalósítására.
A GCP erős:
adatplatformokban
gépi tanulásban
Kubernetes-közeli megoldásokban
Ugyanakkor fontos látni: GCP-nél sincs magyar nyelvű felület vagy dokumentáció, minden angolul érhető el, és bizonyos enterprise minták kevésbé nyilvánvalóak, mint Azure-ban.
Mesterséges Intelligencia 2026-ban – mindhárom jó választás
Azure, AWS és GCP is komolyan veszi az AI-t. Más hangsúlyokkal, más eszközökkel, de mindhárom platform alkalmas valós üzleti megoldásokra.
Amit viszont mindig hangsúlyozok: az AI sem varázslat. Cloud alapokra épül, hálózatra, biztonságra, költségkeretekre. Ha ezek nincsenek rendben, az AI sem fog csodát tenni.
A felhő is csak akkor költséghatékony, ha okosan használjuk.
Hogyan válassz, ha most kezdesz bele?
Én ezt a gondolkodást javaslom:
ne technológiát válassz, hanem tanulási élményt: melyik esik kézre, melyik megértése egyszerűbb számodra
melyik motivál hosszabb távon: amelyik tetszik, azt válaszd
ne akarj mindent egyszerre megtanulni: a fokozatosság a kulcs
fogadd el, hogy a döntés nem végleges: a szolgáltatók is változnak és Te is. Ma még ezt kedveled, holnap a másikat. Ez rendben van.
Ha számodra a Microsoft-os háttér és az OpenAI a fontos, akkor merülj el az Azure világában. Cloud-native megoldások érdekelnek és a mély technikai megvalósítások, ez esetben az AWS lesz a Te utad. Ha pedig az adat, vagy a gépi tanulás, esetleg a Kubernetes-közeli világ foglalkoztat, akkor nézd meg a GCP-t.
Amit vállalati oldalon látok
A nagyvállalati valóság az, hogy a cégek többsége egyetlen hyperscaler-re fókuszál. Nem azért, mert ne ismernék a vendor lock-in kockázatát, hanem mert a gyorsaság, az egyszerűbb működés és a költségkezelés fontosabb számukra.
Sok esetben a vendor lock-in tudatos kompromisszum. Mire valódi problémává válna, a rendszer már annyira mélyen beágyazódott az adott felhő ökoszisztémájába, hogy a kiszállás csak jelentős költségek és komoly átalakítás árán lenne lehetséges. Ilyenkor inkább együtt élnek vele.
Reális alternatívaként gyakran hibrid megoldások jelennek meg, főleg hagyományos rendszerek, adatvédelmi vagy compliance okok miatt. Ez sokszor kezelhetőbb, mint több hyperscaler párhuzamos használata.
Én az ideális állapotot máshogy látom. Egy olyan több-felhős megközelítésben, ahol minden szolgáltatótól azt használom, amiben valóban erős, miközben tudatosan figyelek arra, hogy ne zárjam be magam visszafordíthatatlanul egyetlen platformba.
Számomra ez olyan, mintha egy különleges menüt állítanék össze a legjobb éttermek kínálatából. A végeredmény kiváló lehet, de több tervezést, nagyobb szakmai érettséget és folyamatos odafigyelést igényel. Nem a legegyszerűbb út, de hosszú távon a legkiegyensúlyozottabb.
A siker nem azon múlik, melyik platformot választod, hanem azon, hogy:
érted-e az alapelveket
költségtudatosan tervezel-e
biztonságban gondolkodsz-e már az elején
egyszerű és a megfelelő megoldásokkal indulsz-e
Számomra melyik?
2026 elején összességében az AWS áll közelebb hozzám. Nem azért, mert az Azure rossz lenne – sőt, AI területen jelenleg egyértelműen erős, különösen enterprise környezetben. Ezt kár lenne vitatni.
Amiért nálam most mégis az AWS a „nyerő”, az inkább rendszerszintű gondolkodás kérdése. Az AWS szolgáltatásai, integrációi és a cloud-native szemlélet sok esetben jobban illeszkednek ahhoz, ahogyan ma infrastruktúrát és platformokat tervezek. Nagyobb szabadságot ad, kevesebb röghöz kötött megoldással, ami számomra most előny.
Hangsúlyozom: Ez nem végleges álláspont. Volt már olyan időszak, amikor az Azure volt előrébb, és könnyen lehet, hogy lesz még ilyen. A cloud világában a technológia és az igények is gyorsan változnak – ezzel együtt a preferenciák is.
A lényeg nem az, hogy melyik platform jobb, hanem az, hogy tudd, miért választasz egyet egy adott helyzetben.
Zárásképpen
Az Azure, az AWS és a GCP valós piaci versenytársak. Más üzleti fókusz, más ökoszisztéma, más erősségek mentén fejlődnek. A gyakorlatban viszont a legtöbb mérnök és cég nem „platformhűség”, hanem konkrét problémák és költségek alapján dönt.
Továbbra sem az a legfontosabb kérdés, hogy melyiket választod elsőre, hanem az, hogy:
értsd a cloud alapelveket,
tudd, mikor melyik platform miért jó választás,
és képes legyél később váltani vagy több platformban gondolkodni.
A platformválasztás csak egy döntés. A valódi érték abból jön, ha tudatosan és magabiztosan használod.
Ha ebben szeretnél előrébb lépni, több módon is tudlak támogatni:
Az előző cikk végén ott hagytuk abba, hogy 2026-ban a cloud már nem cél, hanem eszköz. Egy gondolkodásmód, amire a legtöbb digitális rendszer épül. A következő lépés viszont már nem pusztán erről szól. Az igazi változás ott kezdődik, amikor az AI nem csak használja ezt az alapot, hanem formálni is kezdi a felhőt.
Ez a cikk erről a személetváltásról szól. Nem arról, hogy melyik modell jobb, és nem is technikai útmutató. Sokkal inkább arról, milyen szerepe lett és lesz az AI-nak a cloud működésében, és milyen következményei vannak ennek technológiai, gazdasági és döntési szinten.
Az AI szerepe a Cloud-ban megváltozott
Az AI ma már nem külön projektként jelenik meg a felhőben. Nem egy újabb doboz a sok közül, hanem platformszintű képesség. A cloud szolgáltatók nem egyszerűen futtatási környezetet adnak hozzá, hanem olyan rétegeket építenek köré, amelyek az AI-t beemelik a mindennapi működésbe. Mindehol ott a Co-Pilot jellegű működés, amely arra hivatott, hogy segítse a mindennapjainkat. Bár néha kifejezetten idegesítő.
Ez jól látszik abban, ahogyan a hyperscalerek pozicionálják az AI-t. Nem egyetlen „AI termékről” beszélnek, hanem olyan szolgáltatásokról, amelyek architektúra-tervezést, skálázást, költségoptimalizálást vagy incidensek értelmezését is támogatják. Fontos: Az AI nem helyettesít, hanem döntési teret alakít át.
Azure, AWS és GCP – „minden út Budára vezet”
A Microsoft Azure esetében az AI erősen az LLM-vonal köré szerveződik. Az Azure OpenAI Service és az erre épülő enterprise megoldások azt mutatják, hogy az AI szorosan integrálódik az üzleti folyamatokba. Nem önmagában érdekes, hanem azért, mert ott jelenik meg, ahol a felhasználók dolgoznak. Persze ez csak egy nagyon apró része annak az AI funkcionalitásnak és trendnek, amit ma ismerünk.
Az AWS más irányból érkezett. Régóta erős a machine learning területén, és ezt a tapasztalatot vitte tovább platformlogikába. A Bedrock a generatív AI-t teszi elérhetővé felügyelt módon, míg a SageMaker AI a klasszikus ML-életciklust fedi le. Az üzenet itt nem a modell, hanem az eszköztár és az irányíthatóság.
A Google Cloud Platform pedig azért érdekes, mert az AI nem új irány nála. A Google belső rendszerei évek óta AI-ra épülnek, és ez a szemlélet jelent meg a Vertex AI köré szervezett cloud kínálatban. Itt az adat és az AI szoros összekapcsolása kerül fókuszba.
A közös pont mindhárom esetben az, hogy az AI nem kiegészítő, hanem a platform működésének része lett.
Miért lett a cloud az AI természetes közege?
Sokan még mindig hardveroldalról közelítik meg az AI-t: milyen GPU kell hozzá, mennyi memória, elég-e egy erős otthoni gép. Ez a gondolkodás érthető, de egyre kevésbé írja le a valóságot.
A cloud egyik legnagyobb előnye az AI esetében nem pusztán a teljesítmény, hanem a skálázhatóság és az időbeliség. Olyan erőforrások érhetők el rövid időre is – több terabájt memória, több nagy teljesítményű GPU egy környezetben –, amelyek otthoni vagy kisebb on-prem környezetben nem reálisak.
A valódi szemléletváltás azonban ott történik, hogy az AI jellemzően felügyelt (managed) szolgáltatásként jelenik meg. Nem kell CPU-, RAM- vagy GPU-konfigurációval foglalkozni, nem kell drivereket, frameworköket karbantartani. Ezeket a problémákat a platform kezeli.
Személyes megjegyzésként idekívánkozik, hogy 2026-ban én is szert tettem egy aránylag erős helyi gépre, kifejezetten AI-val való kísérletezésre és fejlesztésre. Egy Ryzen 7 7800X3D, 64 GB RAM és egy RTX 3090 24GB körüli konfiguráció már alkalmas arra, hogy kis- és közepes modellekkel dolgozzak, tanuljak, prototípusokat építsek.
De ez a tapasztalat inkább megerősítette bennem: amit helyben lehet, az tanulás és kísérletezés.Amint skálázni, párhuzamosítani vagy üzemszerűen használni szeretnék, a cloud egyszerűen más ligában játszik.
És itt előtérbe kerül az árazás és az árazási modellek megértése a felhőben. Otthon az a kérdés, hogy elég-e a gép. A felhőben az, hogy mennyibe kerül, ha így használom. Ez az egyik oka annak, hogy az AI a cloud-ban nem hobbi-megoldásként, hanem üzemszerűen terjedt el.
Az AI hatása a hardverpiacra
Az AI és a cloud együtt nem csak szoftveres változást hozott. A hardverpiacon is érezhető a hatása. Az adatközponti AI igény nem csak GPU-kat szív fel, hanem memóriát is – különösen nagy sávszélességű és szerveroldali megoldásokat.
A piaci elemzések és üzleti hírek egyre gyakrabban kötik össze a memóriaárak alakulását az AI-adatközpontok növekvő igényével. A hangsúly eltolódott: a gyártók és beszállítók számára a hyperscalerek váltak a legfontosabb ügyfelekké.
A változás egyik leglátványosabb következménye az árakon látszik. Egyes GPU- és memóriaszegmensekben 2024–2025 során 1,5–3× közötti áremelkedés volt tapasztalható, különösen ott, ahol az adatközponti AI-igény közvetlenül megjelent. Ez nem egységes a teljes piacon, de jól mutatja az irányt: amikor a hyperscalerek és nagyvállalatok tömegesen vásárolnak, a fogyasztói és kisebb üzleti piac háttérbe szorul.
Ezt a folyamatot jól szemlélteti az NVIDIA bevételeit bemutató ábra. A sávok azt mutatják, hogyan vált a Data Center (DC) üzletág – vagyis a Cloud-os, AI-fókuszú infrastruktúra – a domináns bevételi forrássá, miközben a Gaming és az egyéb szegmensek aránya háttérbe szorult. A grafikon nem csak növekedést, hanem súlypont-eltolódást jelez: az AI ma már elsősorban adatközpontokban él.
Adatbiztonság és a félreértések
Az AI + Cloud kapcsán az egyik legtöbb bizonytalanságot az adatkezelés okozza. Sok félelem nem konkrét tapasztalatból, hanem feltételezésekből fakad. Gyakori gondolat, hogy a Cloud-os AI „biztos betanítja az adatokat”.
A valóság ennél árnyaltabb. A nagy cloud szolgáltatók dokumentációja különbséget tesz az alapértelmezett működés és az explicit engedélyezett tréning között. Enterprise környezetben az ügyféladatok jellemzően elkülönítve maradnak, és nem kerülnek más ügyfelekhez vagy alapmodell-tréningbe engedély nélkül.
Ugyanakkor fontos kimondani: a cloud nem varázslat. Az adatbiztonság nem automatikus. A shared responsibility modell itt is érvényes. A platform adja az alapokat, de a jogosultságkezelés, a hozzáférések és az adathasználat kontrollja továbbra is az ügyfél döntése.
A félelmek egy része abból fakad, hogy sokan a mai napig nem értik pontosan, hogyan működik egy AI. A modell, a tréning, az inference és az adatkezelés gyakran egyetlen „fekete dobozzá” mosódik össze a fejekben. Ha nem világos, mi történik egy kérdés elküldésekor, hol fut a feldolgozás, és mi marad meg belőle, akkor természetes reakció a bizalmatlanság. Ez a bizonytalanság nem rosszindulatból fakad, hanem információhiányból.
Ezért a zavar valószínűleg 2026-ban sem fog teljesen eltűnni. Nem azért, mert a szolgáltatók ne lennének egyre transzparensebbek, hanem mert az AI használata gyorsabban terjed, mint ahogy a szervezetek megtanulják helyesen értelmezni a működését.
Mit várhatunk 2026-ban az AI + Cloud területén?
Az AI és a Cloud együtt nem új trend, hanem új működési környezet. Kevesebb manuális döntés látszik, de több döntés történik a háttérben. Kevesebb technikai akadály, de nagyobb felelősség.
Azok járnak jól ebben a világban, akik nem csodát várnak az AI-tól, hanem értik, mire használják, és hajlandók felelősséget vállalni a döntéseikért.
2026-ban az AI nem egy kísérleti technológia lesz, hanem egy stratégiai alapvetés, amely a cloud működésének mindennapi részévé válik. A nagy technológiai szolgáltatók és elemzők szerint több irányban is érdemes felkészülni:
• Az AI szerepe tovább mélyül: A korábbi „AI mint eszköz” fázist teljesen felváltja az „AI mint partner” logika – az AI nem csak kérdésekre válaszol, hanem támogatja a döntéseket, együttműködik munkafolyamatokban és gyorsítja a kutatást. Ez nem csak technikai előny, hanem szervezeti és működési átalakulás is.
• Agentic AI és intelligens automatizálás erősödik: A vállalati környezetben 2026-ra szélesebb körben terjednek az olyan AI-agentek, amelyek nem csak input-output feladatokat végeznek, hanem autonómabban lépnek kölcsönhatásba rendszerekkel és döntési folyamatokkal.
• Adat és AI governance fókuszba kerül: A fogyasztók és szervezetek egyre nagyobb figyelmet fordítanak arra, hogyan használja az AI az adatokat, hogyan magyarázható és kontrollálható a működése. Ez nem csupán technikai kérdés, hanem a bizalom és jogi megfelelés alapja.
• Biztonság és infrastruktúra kiemelt téma: A növekvő AI-használat új támadási felületeket és identitás-vezérelt kihívásokat hoz, ezért a kiberbiztonság nem csak háttérfeladat, hanem stratégiai prioritás lesz az AI + Cloud környezetben.
Ezek az irányok nem csupán az én gondolataim, hanema legfrissebb szakmai előrejelzésekkel egybevágó vélemény is.
Az AI nem külön dolog többé, hanem a Cloud működésének szerves, strukturális része lesz.
2026-ban már nem az a kérdés, használod-e az AI-t a Cloudban, hanem az, hogy jól használod-e. Ha ebben szeretnél biztosabb lenni, iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeimet.
Amikor több mint egy évtizeddel ezelőtt először dolgoztam felhővel, még egészen más kérdések foglalkoztatták a cégeket. Mekkora szervert vegyünk? Elég lesz-e két év múlva is? Mikor kell új vasat rendelni, és mennyi idő alatt ér ide? A döntések hónapokra, vagy évekre előre szóltak, és minden hibának ára volt.
Ma, 2026 elején, egészen másról beszélünk. A kérdés már nem az, hogy „használjunk-e felhőt”, hanem az, hogy hogyan használjuk jól.
Ez a cikk nem arról szól, hogyan kell kattintgatni a konzolon, inkább egy helyzetkép: hol tart most a cloud, mit tanultunk az elmúlt években, és mire érdemes készülni rövid távon.
Mi a cloud computing ma, röviden és érthetően
A cloud computing nem egy konkrét technológia, hanem egy működési modell. A lényege egyszerű: erőforrásokat használsz akkor, amikor kell, és csak addig fizetsz értük, amíg valóban szükséged van rájuk. Nem te vásárolsz szervert, nem te cseréled a meghibásodott alkatrészt, és nem neked kell minden részletet kézben tartani.
Fontos kimondani azt is, ami sokszor kimarad: a cloud nem ingyenes, és nem varázslat. Nem lesz tőle automatikusan gyorsabb vagy jobb egy alkalmazás. Viszont ad egy rugalmasságot, amit korábban csak nagyvállalatok tudtak megfizetni.
Egy egyszerű példa: egy webalkalmazás elindítása saját szerverrel ma is működik. Viszont ha hirtelen tízszer annyi felhasználó kezdi el használni, a cloud adja azt a mozgásteret, amivel ezt különösebb kapkodás és túlterhelés miatti leállás nélkül le lehet kezelni.
Mi változott az elmúlt években, és miért fontos ez 2026-ban
Néhány évvel ezelőtt sok helyen uralkodó gondolat volt, hogy „mindent vigyünk fel a felhőbe”. Ez azonban hibás gondolat, úgy ahogy a Scrum sem való minden projekthez. Emiatt ez a hozzáállás ma már egyértelműen kiforrottabb lett. A cégek megtanulták, hogy a cloud nem automatikusan olcsóbb, és a rosszul megtervezett rendszerek itt is gyorsan drágává és átláthatatlanná válhatnak.
2026-ra a cloud érett technológiává vált. Nem a kísérletezésről szól, hanem a tudatos döntésekről. Egyre több szervezet ismeri fel, hogy kevesebb szolgáltatás, egyszerűbb architektúra és átgondolt működés sokszor többet ér, mint a legújabb megoldások halmozása. Annak ellenére, hogy a felhőszolgáltatók sokszor mást sugallnak.
A cloud nem lett rosszabb. Mi lettünk tapasztaltabbak. És elkezdtük hatékonyabban használni.
Mire használják a cégek a felhőt 2026-ban valójában
A legtöbb vállalat ma nem csupán „innovációs lehetőségként” tekint a felhőre. Sokkal inkább stabil alapként. Tipikus felhasználási területek:
üzleti webalkalmazások futtatása
belső rendszerek és API-k
adatfeldolgozás és jelentéskészítés
fejlesztői és tesztkörnyezetek gyors létrehozása
Ezekben a felhasználási esetekben a cloud legnagyobb értéke a gyors indulás és a skálázhatóság. Nem kell mindent előre megtervezni évekre. Lehet kipróbálni, tapasztalni, majd dönteni.
Itt jelenik meg egyre természetesebben az AI is. Nem külön projektként, hanem funkcióként. Keresésben, ügyfélszolgálati automatizmusokban, vagy éppen adatok értelmezésében. A cloud biztosítja azt az alapot, amely nélkül ezek a megoldások nem lennének gazdaságosan működtethetők.
Hogyan indul ma egy kis cég?
Vegyünk egy mai, valós helyzetet. Egy kisebb cég szeretne egy webes alkalmazást indítani, aminek eleinte csak néhány száz felhasználója van, de nem tudják, fél év múlva mi lesz belőle.
2026-ban ilyenkor már ritkán merül fel az, hogy saját szervert vegyenek. Ehelyett:
és tárolják az adatokat egy felhőalapú storage-ban.
Ha az alkalmazás sikeres lesz, a rendszer skálázható. Ha nem válik be, egyszerűen leállítható, nagy veszteség nélkül.
Ez a cloud egyik legnagyobb ereje: nem kell előre mindent tudni, mégis van mozgástér. Ez üzleti oldalról legalább akkora előny, mint technikai szempontból.
Hol találkozol a felhővel a gyakorlatban?
Sokan úgy gondolnak a felhőre, mint valami elvont, „nagyvállalati” dologra, pedig a legtöbben már most is naponta használják – csak nem így hívják. Ha azt mondom: Instagram, TikTok, Gmail, OneDrive és Netflix, akkor azoknak a szolgáltatásoknak a nevét sorolom, ahol naponta találkozol Te is a felhővel.
Amikor egy webalkalmazás gyorsan betölt, amikor egy online rendszer gond nélkül kiszolgál sok felhasználót egyszerre, vagy amikor egy szolgáltatás mögött nincs látható leállás, ott nagyon gyakran „cloud fut a háttérben”.
A felhő a nagy szolgáltatóknál nagyon hasonló alapokra épül.
Például:
Microsoft Azure esetén tipikusan virtuális gépek, menedzselt adatbázisok és tárolószolgáltatások adják az alapot.
Amazon Web Services ugyanezt az elvet követi, csak más elnevezésekkel, megközelítéssel és hangsúlyokkal.
A lényeg nem az, hogy melyik platformon vagy, hanem az, hogy nem nulláról építkezel, hanem kész, kipróbált építőelemekből dolgozol.
Mit jelent a cloud a felhasználók számára
A legtöbb végfelhasználó nem gondolkodik cloudban. Nem is kell. Ők gyors, megbízható szolgáltatásokat várnak el, lehetőség szerint zéró leállással és elfogadható válaszidőkkel. Ha egy alkalmazás lassú vagy elérhetetlen, nem az érdekli őket, hogy hol fut, hanem az, hogy miért nem működik.
2026-ra a cloud ebből a szempontból láthatatlanná vált. Ott van minden mögött, de csak akkor kerül szóba, ha valami nem úgy működik, ahogy kellene. Ez önmagában jelzi az érettségét. Pontosan olyan alapszolgáltatásként tekintünk rá, mint a vezetékes vízre vagy az áramra.
Mit jelent a cloud a karrierváltóknak és pályakezdőknek
Sokan kérdezik tőlem, hogy érdemes-e ma még cloud irányba indulni. A válaszom röviden: igen, de másképp, mint pár éve. Nem az számít, hogy hány szolgáltatás nevét ismered, hanem az, hogy érted-e az alapokat.
2026-ban a cloud jó belépési pont az IT világába azoknak is, akik nem szeretnének mélyen programozni. A rendszerszemlélet, az alap biztonsági gondolkodás és az üzleti igények megértése sokkal fontosabb lett, mint a konkrét implementációs részletek.
Az AI ebben a tanulási folyamatban segíthet, magyarázhat és irányt mutathat, de nem veszi le a döntés terhét a válladról.
A cloud szakember nem attól lesz jó, hogy mindent automatizál vagy mindent tud, hanem attól, hogy felelősséget vállal a döntéseiért és tanul a hibáiból.
Az AI szerepe röviden
Talán észrevetted az AI itt nem főszereplő még, de nem lehet megkerülni. 2026-ban egyértelműen látszik, hogy az AI felerősíti a cloud jelentőségét. Skálázás, költségoptimalizálás, automatizált elemzés mind olyan területek, ahol a kettő együtt ad valódi értéket.
Ugyanakkor fontos határt húzni. A cloud itt még az alap, az infrastruktúra és a platform. Az igazi változás ott kezdődik, amikor az AI már nem csak használja a felhőt, hanem formálja is. Erről szól majd a következő cikkem.
Korlátok, amik 2026-ban is megmaradnak
A cloud nem old meg rossz döntéseket. Nem helyettesíti a gondolkodást, és nem javítja ki a szervezeti problémákat. Rosszul használva továbbra is drága, és könnyen átláthatatlanná válik.
Ez AI-val együtt sincs másképp. Ha nincs világos cél, nincs felelősség és nincs kontroll, akkor a legmodernebb technológia is csak gyorsabban visz rossz irányba.
Útravaló
2026-ban a cloud nem trend, hanem alap. Nem cél, hanem eszköz. Azok a csapatok és szakemberek járnak jól, akik nem csodát várnak tőle, hanem tudatosan használják. A következő lépés viszont már nem csak erről szól. Az AI és a cloud együtt új kérdéseket vet fel, és új válaszokat kényszerít ki.
Erről fog szólni a folytatás…
Ha érdekel, merre halad ez az irány, és hogyan érdemes rá felkészülni, akkor iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeim.
Senki sem szereti a rendetlenséget. Akkor sem, ha nem vagyunk rendmániások. Valahol mindannyiunknak szüksége van arra a fajta belső nyugalomra, amit az ad, hogy a dolgok a helyükön vannak. Egy rendezett tér nem csak esztétikai kérdés: segít tisztábban gondolkodni, könnyebben eligazodni, és biztonságérzetet ad a mindennapokban.
Nincs ez másképp a Kubernetes cluster esetében sem. Amikor egyre több alkalmazást, podot, service-t és konfigurációt indítunk el, hamar rájövünk, hogy a rendszer saját “lakói” is igénylik a strukturáltságot. A Kubernetes pedig erre egy elegáns, mégis egyszerű megoldást kínál: a namespace-eket, amelyek láthatatlanul, de nagyon is hatékonyan teremtik meg azt a rendezettséget, amelyre egy növekvő clusternek szüksége van.
Mi az a namespace?
A Kubernetesben a namespace egy logikai szeparációs mechanizmus, amely csoportokra bontja a cluster erőforrásait. A fogalom eredetileg a Linux kernel világából származik: ott is az izoláció a cél, vagyis hogy különböző folyamatok saját, elkülönített erőforrás-nézetet kapjanak.
A Kubernetes ezt továbbgondolja: a namespace nem csupán technikai elszeparálás, hanem egy szervezési, erőforrás-kontroll és biztonsági keret is.
Lényeg:
Minden API-hívás egy namespace-en belül történik, hacsak nem adunk meg külön mást. Például: https://<api-server>/api/v1/namespaces/default/pods
A namespace lehetővé teszi a kvóták és limitációk alkalmazását egy adott csoport erőforrásaira.
Később az access control – például RBAC – is működhet namespace-szinten.
Ha csak néhány erőforrás van a clusterben, akkor a szükségessége nem mindig látszik. De nagyobb vállalati környezetben a namespace az egyik legfontosabb szervezési eszköz.
A Kubernetes alapértelmezett namespace-ei
Amikor egy új clustert létrehozunk, Kubernetes négy namespace-t hoz létre automatikusan. Ezek előre definiált szerepet töltenek be, és fontos, hogy ismerjük őket.
default
Az alapértelmezett namespace. Ha nem adunk meg explicit namespace-t egy API-hívásban vagy egy YAML-ben, minden ide kerül.
kube-system
Itt futnak a rendszer- és infrastruktúra szintű komponensek. Maga a Kubernetes működéséhez szükséges podok találhatók itt, például a DNS, a kontrollerek, scheduler stb.
kube-public
Ez egy mindenki számára olvasható namespace (még hitelesítetlen felhasználók számára is). Tipikusan olyan információkat tartalmaz, amelyeknek publikusnak kell lenniük.
kube-node-lease
Ez tárolja a node-ok „lease” objektumait. A control plane ezzel követi a node egészségi állapotát, gyorsabban és hatékonyabban, mint korábban.
Hogyan dolgozunk namespace-ekkel?
A namespace-ek egy része kimondottan szervezési célokat szolgál: a fejlesztői, tesztelési és éles környezet könnyen elkülöníthető, de akár csapatonként, projektenként vagy üzleti funkcióként is létrehozhatunk új namespace-eket.
A legfontosabb alapműveletek:
Meglévő namespace-ek listázása
kubectl get ns
Új namespace létrehozása
kubectl create ns sajat-projekt
Namespace részletes leírása
Megmutatja többek között a címkéket, annotációkat, kvótákat, limiteket.
kubectl describe ns sajat-projekt
Namespace tartalmának YAML formátumú lekérése
kubectl get ns/sajat-projekt -o yaml
Namespace törlése
kubectl delete ns sajat-projekt
Namespace használata YAML fájlokban
Ha egy erőforrást szeretnénk egy konkrét namespace-ben létrehozni, azt a metadata blokkban kell megadni:
apiVersion: v1
kind: Pod
metadata:
name: redis
namespace: sajat-projekt
Ez a mindennapi Kubernetes fejlesztés egyik alapja: a pod encapsulation, a resource isolation és a cluster szervezése így lesz konzisztens, rendezett és biztonságos.
pod encapsulation: A „pod-beágyazás” azt jelenti, hogy a Kubernetes egyetlen kezelhető egységbe, az úgynevezett Podba foglal egy vagy több szorosan együttműködő konténert, a közösen használt tárolót és hálózati erőforrásokat. Ez lehetővé teszi, hogy konténerek egységes egészként működjenek: közösen használják az olyan erőforrásokat, mint a tároló vagy a hálózat, miközben a rendszer egy csomóponton (node) együtt ütemezi és kezeli őket. Ez a megközelítés jelentősen leegyszerűsíti az alkalmazások telepítését és skálázását.
Mikor érdemes namespace-t használni?
A namespace akkor segít igazán, ha:
több csapat dolgozik ugyanabban a clusterben,
több környezetet szeretnénk egymástól elszeparálni (dev, test, staging, prod),
erőforráskvótákat kell alkalmazni (CPU, memória, storage),
korlátozni akarjuk az erőforrások láthatóságát vagy módosíthatóságát,
Kisebb clusterben nem mindig tűnik létkérdésnek, de hosszú távon a namespace az egyik legfontosabb szervezési eszköz, ami segít megelőzni a káoszt.
Összegzés
A namespace látszólag egy apró részlet a Kubernetesben, mégis az egész ökoszisztéma egyik legfontosabb alapköve. Rendet teremt, felelősségi köröket választ szét, erőforrásokat szabályoz, és előkészíti a terepet a biztonságos, skálázható működéshez.
Ahogy tovább haladunk a Kubernetes mélyebb rétegei felé, újabb olyan elemeket fogunk megismerni, amelyek pontosan ilyen csendben, mégis hatalmas erővel segítik a fejlesztőket, üzemeltetőket és szervezeteket abban, hogy a microservice-ek világában stabil rendszereket építsenek.
Itt az évvége, amikor meg kell állnunk egy kicsit, hogy visszatekintsünk, mi is történt idén. Nem egy hosszas elemzést végzünk, csupán megnézzük, mit értünk el, és hogyan szeretnénk átlépni a következő évbe.
Én is így teszek most, ebben a cikkben. Ez nekem minden évben fontos, hogy lássam, hová jutottam el a tavalyi cikkemtől. Ami teljesen bizonyos, hogy teljesen más irányt vett az életem, mint ahogy azt előre vártam. Egy olyan irányba fordultam, amit régen érzek magamban, de nem tudtam, beérik-e valaha, de ne szaladjunk ennyire előre.
Tavaly az alábbi sorokkal búcsúztattam az évet:
2025-ben is folytatom az utamat a technológia és a tanulás világában, és bízom benne, hogy velem tartotok ezen az izgalmas utazáson. Terveim szerint rengeteg új témával, praktikus példákkal és inspiráló tartalmakkal készülök nektek.
Nézzük mi is történt, hogyan fejlődtem, milyen megéléseim voltak.
Köszönöm
Először is szeretném megköszönni a Feleségemnek a sok-sok támogatást, amit mindig és folyamatosan kapok Tőle. Ő az, aki mindig inspirál és átsegít a nehéz pillanatokon.
Kiemelt köszönet azoknak, akik követik munkásságomat és támogatnak a mindennapokban, azzal hogy olvassák cikkeimet vagy tanácsot kérnek a szakmai fejlődésükhöz.
Hálás vagyok a Mentor Klubnak is, hogy már több mint 3 éve egy inspiráló, baráti és motiváló együttműködés keretében tesszük jobbá a világot azzal, hogy a fejlődni és váltani vágyóknak biztosítjuk a lehetőséget a tanulásra.
Összességében szeretném megköszönni a sok kedves visszajelzést és energiát, amit rendszeresen kapok. Ez motivál arra, hogy a következő időszakban is tovább folytassam az utam és rendszeres megújulásokon keresztül még jobb és praktikus témákat hozzak nektek.
Oktatás és mentorálás
Ebben az évben a Mentor Klubon belül kicsit bővítettük azt a palettát, amit nyújtok a fejlődni vágyóknak. Már nem csupán szakmai képzéseken (Azure, AWS) találkozhattatok velem, hanem volt egy nagyon jó hangulatú karrier-tanácsadás is.
Egy olyan élő lehetőség, ahol bárki kérdezhetett tőlem a karriercéljai és esetleges nehézségei kapcsán. Ezen az eredetileg 2 órásra tervezett (végül 2,5 órás) interaktív beszélgetésen több mint 190 ember vett részt és ennek többszöröse az, aki utólag nézte vissza a felvételt. Ez fantasztikus és felemelő volt egyszerre.
És ez csak egy kis szelete annak a több mint 1000 hallgatónak, akik résztvettek idén a képzéseimen vagy online, vagy offline módon. Hihetetlenül sok energiát kapok ezeken keresztül is.
Hiszen felhő képzéseimen is megnőtt az érdeklődők száma, ami jól mutatja, hogy a felhő egy fontos összetevője a jelenlegi informatika világának. Ráadásul a mesterséges intelligencia térhódításával, talán még fontosabb lett, mint korábban.
Az év negyedik negyedévében lett két mentoráltam is, akikkel 2 hetente még mélyebbre ássuk magunkat a felhő és a modern karrierváltás világába. Rajtuk keresztül még jobban látom, mennyit ér a kitartó és kemény munka, ha valaki szeretné megvalósítani az álmait.
2025-ben indítottam útjára az ingyenes karrier-tanácsadási kérdőívemet, a Felhő Iránytűt, amit február vége és november vége között húszan töltöttétek ki. Nekik személyre szabott felhő karrier tanácsokat adtam, amit a visszajelzések alapján mindenki kiemelten hasznosnak tartott.
Evolvia – a büszkeségem
Az Evolvia számomra különösen fontos. Ez egy olyan felhőalapú gyakorló platform, amelyet teljes egészében egyedül építettem fel. Az volt a célom, hogy ne csak beszéljünk a technológiáról, hanem valódi, gyakorlati környezetben lehessen kipróbálni, megtapasztalni és megtanulni.
Az Evolvia pontosan azt a hiányt tölti ki, amit én is sokszor éreztem korábban: az elmélet és a gyakorlat közötti szakadékot. A fejlesztését 2026-ban is folytatom, hogy még több ember számára legyen elérhető, használható és értékes tanulási lehetőség.
Az Evolvián jelenleg olyan gyakorlati képzések érhetők el, amelyek az Azure alapjaitól indulnak, és fokozatosan vezetnek el az összetettebb, valós életből vett megoldásokig. A cél végig ugyanaz: ne csak értsük, miről szól egy szolgáltatás, hanem saját kézzel hozzuk létre, konfiguráljuk és működtessük.
A tananyagok lefedik az Azure Portál használatát, a virtuális gépek és hálózatok létrehozását, a terheléselosztást és a skálázhatóság alapjait, valamint a CloudShell és az Azure CLI gyakorlati alkalmazását. Ezekre épülnek a modernebb irányok is, mint az App Service alapú webalkalmazások, a DevOps folyamatok automatizálása, a Docker-alapú telepítések, vagy akár az AI-hoz kapcsolódó megoldások, például az OpenAI és RAG-alapú alkalmazások Azure környezetben.
Alkotás és kódolás
Ezen a területen is sokat tevékenykedtem idén. 2025-ben ezzel a cikkel együtt 88 alkalommal osztottam meg veletek valamilyen tudást vagy információt. Remélem, hogy hasznos számotokra és jövőre is velem tartotok.
Munkám során és a hobbi projektjeim keretein belül több mint 33 075 kódsort írtam több mint 18 GitHub repository-ba, amelyekkel valamilyen Cloud, AI valamint DevOps projektet keltettem életre vagy járultam hozzá annak hatékonyabb működéséhez.
Az alkotás itt nem állt meg. Az általam tartott képzésekhez idén 542 db prezentációs diát készítettem, amelyeket az élő- és videós képzésekhez készítettem nektek.
Ebben az évben 3 új – általam készített – videós képzéssel is megajándékozott Titeket a Mentor Klub. Ezek széles spektrumon mozognak: DevOps & SRE, AI, NoCode-LowCode. Igazán izgalmas volt ezeket elkészíteni, mert tudtam, hogy hasznos és használható tudást adhatok nektek ezzel.
Tanulás
Ahogy előrevetítettem, idén is rengeteget tanultam. Évelején elkezdtem a felkészülést a Certified Kubernetes Administrator (CKA) vizsgára, amely kapcsán volt néhány negatív megélésem. Rájöttem, hogy nem egy újabb technológiai vizsga az az út vagy irány ami a jövőm.
Ez a megélés meghatározta az év nagy részét, így egy valódi hullámvasút érzést adott. Izgalmas volt, de nyár végére rájöttem egy új, nagyobb cél, amit nekem szánt a sors.
Emiatt tanulásomat 2025-ben a vezetői soft skill képzések tették ki, ezen belül is az új irány a Leadership, azaz a menedzsment irány. Lehetőségem volt a Harvard ManageMentor keretében több mint 25 tanúsítványt szereznem. Izgalmas és új utazás volt, ahol azt tanulhattam és tanúsíthattam, hogyan tudok embereket vezetni.
Olyan képességeimet tudtam fejleszteni mint a delegálás, coaching, mentoring, visszajelzések kezelése, emberek vezetése, AI alkalmazása a vezetésben, és még sok-sok hasonló. Érdekes hónapok voltak ezek is.
2025-ben bennem is – ahogy már utaltam rá – sok minden átrendeződött. Nem egyik napról a másikra, inkább lassan, szinte észrevétlenül. Ebben új munkahelyem is segített. Egyre világosabb lett, hogy már nem az hajt igazán, hogy minél több dolgot csináljak, hanem az, hogy amit csinálok, annak valódi súlya és értelme legyen.
Megváltozott a fókuszom. Tudatosabban választok témákat, embereket, irányokat. Sokkal fontosabb lett számomra a mélység, mint a mennyiség, és az, hogy ne csak technológiai problémákat oldjak meg, hanem embereknek segítsek eligazodni, dönteni, fejlődni.
Ami viszont igazán világossá vált 2025-ben, az egy régi belső gondolat megerősödése volt: régóta éreztem magamban a vezetői irányt. Idén ez letisztult, kimondhatóvá vált, és ennek megfelelően kezdtem el tudatosan rendezni az életemet – szakmailag és emberileg egyaránt.
A karrieremben is ebbe az irányba haladok tovább, amit már nyíltan vállalok. Ennek a változásnak része az is, hogy a szakmai jelenlétemben – például a LinkedIn profilomon – már DevOps leaderként határozom meg magam.
Ez nem egy hirtelen váltás, hanem egy irány, amely mostanra érett meg bennem igazán.
A következő lépés
A következő időszak számomra egyértelműen a vezetői karrier tudatos építéséről szól. Ez már nem kérdés, hanem irány. Úgy érzem, ebben a szerepben tudok igazán többet adni: tapasztalatot, rálátást, iránymutatást.
A technológiát természetesen nem engedem el. A Cloud és az AI továbbra is központi része marad annak, amivel foglalkozom. Vannak technológiai terveim és törekvéseim is a következő évre, de ezekről egyelőre még nem szeretnék részletekbe menni.
2026-ban is folytatom az oktatást és a mentoringot, sőt, még több energiát szeretnék ebbe az irányba tenni. Akár képzésekről, akár személyes mentorprogramról vagy vizsgafelkészítésről van szó, továbbra is az a célom, hogy valódi segítséget adjak azoknak, akik fejlődni vagy váltani szeretnének.
Köszönöm, hogy idén is velem tartottatok. Jövőre is várlak benneteket a Mentor Klub képzésein, egy személyes mentorprogramban vagy egy vizsgafelkészítőn.
Kellemes ünnepeket kívánok, és találkozunk 2026-ban!
Amikor legutóbb a Kubernetes API-ról mint „a kommunikáció idegrendszeréről” írtam, sok visszajelzést kaptam arról, mennyire segített érthetővé tenni a fürt működését. Most innen folytatjuk a történetet. Az előző cikkben is sok mindent megmutattam, hogy érthetőbbé tegyem a cluster belső működését, és most megvizsgáljuk, hogyan zajlik valójában az információáramlás a Kubernetes belső világában.
Ennek a cikknek a célja, hogy az API működésének gyakorlati oldalát mutassa be: hogyan jelenik meg mindez a legegyszerűbb kapszula létrehozásánál, mit csinál a kubectl valójában a háttérben, hogyan lehet a klaszteren kívülről hozzáférni az API-szerverhez, és mire szolgál a mindenki által használt ~/.kube/config fájl.
A Kubernetesben minden objektum, minden módosítás, minden lekérdezés API-hívások sorozata. Ha értjük ezt a réteget, a rendszer teljes működése világossá válik.
1. A kapszula mint API-objektum: a legkisebb egység
Az előző cikkben már beszéltünk arról, hogy a kapszula a Kubernetes legkisebb futtatási egysége. Az alábbi példa egy minimális, mégis rendkívül tanulságos kapszula-definíciót mutat be:
Ez a néhány sor már minden lényeges elemet tartalmaz:
apiVersion – melyik API-csoportot használja az objektum;
kind – az erőforrás típusa (Pod);
metadata – az objektum azonosító adatai;
spec – a kapszulában futó konténerek és paramétereik.
A létrehozás és lekérdezés mind API-hívások sorozatán keresztül történik:
kubectl create -f elsopod.yaml
kubectl get pods
kubectl get pod elsopod -o yaml
kubectl get pod elsopod -o json
A külvilág számára ezek egyszerű parancsoknak tűnnek, de valójában a kubectl az API-szerverhez küld lekérdezéseket és módosítási kéréseket.
2. Hogyan kommunikál valójában a kubectl?
A Kubernetes minden erőforrást RESTful API-n keresztül kezel. Ez azt jelenti, hogy a kubectl működése valójában nem más, mint HTTP-hívások generálása az API-szerver felé – tipikusan JSON formátumú kommunikációval.
Ha szeretnénk még többet megtudni arról, mit csinál a kubectl a háttérben, akkor kapcsoljuk be a részletes – verbose – naplózást:
a két fél között TLS-sel védett HTTP-forgalom zajlik.
Ez a tudás fontos, mert így értjük meg igazán, mi történik akkor, amikor mi „csak” egy új kapszulát hozunk létre vagy lekérjük a futó erőforrásokat.
3. Hozzáférés a Kuberneteshez a klaszteren kívülről
A legtöbb adminisztrációs feladat a kubectl használatával történik, de akár közvetlenül curl-lel is kommunikálhatnánk a Kubernetes API-szerverével. A gond csak az, hogy ehhez hitelesített, TLS-sel védett kapcsolat kell. És mit kell tudni a klaszterhez tartozó API-król?
A klaszter API végpontjának adatai a kubectl config view kimenetében találhatók.
A kliens a hitelesítési adatokat a ~/.kube/config fájlból olvassa ki.
E nélkül a fájl nélkül a hozzáférés legfeljebb korlátozott, „insecure” módon lehetséges, amellyel a legtöbb művelet nem érhető el.
Ezért mondjuk, hogy a kubeconfig a hozzáférés kulcsa: nélküle a klaszter elérhetetlen lenne.
4. A kubeconfig felépítése és jelentése
A ~/.kube/config fájl a Kuberneteshez való hozzáférés központi eleme. A benne található adatok határozzák meg:
melyik klaszterhez csatlakozunk,
milyen felhasználó nevében tesszük ezt,
milyen hitelesítési adatokat használunk,
és milyen kontextusban fut a kubectl.
A kubeconfig több fő részből áll, amelyek együtt írják le a kapcsolat minden aspektusát. Egy alap struktúra így néz ki:
Ahogy minden Kubernetes-objektumnál, itt is meg kell határozni, hogy a fájl melyik API-verzió szerint értelmezendő. A kubeconfig esetében ez tipikusan v1.
clusters
A klaszter(ek) eléréséhez szükséges adatok:
server – az API-szerver címe, amelyhez a kubectl csatlakozik;
certificate-authority-data – a CA tanúsítvány, amely biztosítja, hogy a kliens a megfelelő API-szerverhez kapcsolódjon, és a kapcsolat hiteles legyen.
Ezek alapján a kubectl tudja, hová küldje a kéréseit.
users
Itt találhatók a kliens hitelesítési adatai. Tipikusan:
kliensoldali tanúsítvány,
privát kulcs,
vagy token.
A Kubernetes ebben a részben tárolja, hogy a felhasználó milyen módon igazolja magát a klaszter felé.
contexts
A context egy hármas kapcsolat:
melyik klasztert használjuk,
melyik felhasználó nevében,
és milyen alapbeállításokkal (pl. namespace).
Ez teszi lehetővé, hogy ugyanarról a gépről több klaszterrel is dolgozhassunk, akár eltérő jogosultságokkal.
current-context
Ez mondja meg, hogy a kubectl éppen melyik contextet használja alapértelmezésként. Ha nem adunk meg külön kapcsolót minden parancsnál, akkor ez a context érvényesül.
preferences
Ritkán használt beállítások, például megjelenítési opciók. A legtöbb esetben üres marad.
5. Miért fontos mindezt érteni?
A kubeconfig nem csupán technikai részlet: a Kubernetes működésének egyik kulcsdarabja. Ez határozza meg, hogy:
melyik klaszterrel kommunikálsz,
milyen jogosultsággal,
milyen biztonsági réteg alatt.
Ha a kubeconfigot érted, akkor magabiztosan tudsz klaszterek között váltani, hibákat diagnosztizálni, saját API-hívásokat küldeni, vagy akár több környezetet is kezelni ugyanazon a gépen.
A történet pedig itt még nem ér véget – a Kubernetes mélyebb rétegei csak most kezdenek igazán érdekessé válni.
Az elmúlt években látványosan felgyorsult a mesterséges intelligencia fejlődése. Ami pár éve még kísérleti játéknak tűnt, ma már napi szinten segít fejlesztésben, elemzésben, ügyféltámogatásban vagy akár tartalomkészítésben. Én is végigkövettem ezt az utat az első, még bizonytalan válaszokat adó modellektől egészen a mai, komplex rendszerekig. Ebbe a folyamatba illeszkedik bele a ChatGPT 5.2 megjelenése, ami egyértelműen nem csak egy apró frissítés, hanem egy fontos lépcsőfok lehet.
Ez egy új verziója az 5-ös modellnek, amitől én azt várom, hogy nem lesz olyan mogorva és merev. Habár meg kell jegyezni, hogy nemrég érkezett frissítés, hogy kiválasztható az 5.1-es modellhez a beszédstílusa, sokat javított az 5-ös okozta csalódáson. A 5.2 azonban már alapjaiban próbál reagálni ezekre az észrevételekre, nem csak felszíni finomhangolással.
Kezdjük azzal, hogy mit jelent a ChatGPT 5.2 a gyakorlatban. Ez jelenleg az OpenAI legfejlettebb, úgynevezett „frontier” modellje, amelyet kifejezetten valós feladatokra és agent jellegű működésre optimalizáltak. Ez utóbbi azt jelenti, hogy nem csak válaszol egy kérdésre, hanem képes hosszabb folyamatokban gondolkodni, eszközöket használni, és több lépésen keresztül eljutni egy eredményig.
A frontier modell kifejezés az aktuálisan elérhető legfejlettebb, technológiai élvonalat képviselő AI modelleket jelenti. Ezek a modellek mutatják meg, meddig jutott el adott pillanatban a mesterséges intelligencia képességekben, például gondolkodásban, kódolásban, képfeldolgozásban vagy komplex feladatok megoldásában. Jellemzően nem tömegfelhasználásra optimalizáltak, hanem új határokat feszegetnek, és irányt mutatnak a következő generációs, szélesebb körben elérhető modellek számára.
Kontextus kezelés
Az egyik legfontosabb előrelépés a hosszú kontextus kezelése. Egyszerűen fogalmazva: a modell sokkal jobban megérti a hosszú dokumentumokat, összetett leírásokat vagy „adatgazdag” anyagokat. Ha például egy több oldalas specifikációról, riportokról vagy vegyes, nem teljesen egyértelmű információkról van szó, a 5.2 lényegesen stabilabban tartja a fonalat – Állítja az OpenAI. Nem véletlen, hogy olyan cégek számoltak be erről pozitívan, mint a Notion, a Box vagy a Databricks.
AgenticAI
Szintén komoly előrelépés történt az eszközhívások terén. A ChatGPT 5.2 jobban tud külső rendszerekhez, API-khoz vagy belső funkciókhoz nyúlni, és ezek használatát megbízhatóbban illeszti bele egy hosszabb folyamatba. Ez azoknál a megoldásoknál különösen fontos, ahol az AI nem csak „beszélget”, hanem ténylegesen műveleteket végez, adatot kér le, majd az eredményt tovább dolgozza fel.
Vizuális képességek
A modell jelenleg az OpenAI legerősebb látásalapú megoldása. Diagramok, dashboard-ok, felhasználói felületek értelmezésében több mint 50 százalékkal csökkentek a hibák. Ez nekem azért különösen érdekes, mert egyre több üzleti alkalmazás és belső rendszer vizuális elemekre épül, ahol eddig az AI gyakran félreértelmezett összefüggéseket.
Kódírás
Fejlesztői szemmel a kódolási képességek erősödése sem elhanyagolható. A ChatGPT 5.2 átveheti a vezetést is a komplex programozási feladatokat mérő benchmark-okon. Nem csak új kód generálásában jobb, hanem hibakeresésben, refaktorálásban és meglévő rendszerek javításában is. Ez nem azt jelenti, hogy kivált egy fejlesztőt, de nagyon komoly gyorsító eszközzé válik a mindennapi munkában.
Túlgondolás?
Technikai szempontból fontos újdonság, hogy a modell a feladat bonyolultságához igazítja a gondolkodását – Hurrá! Ez az ahol az 5.1-es modell is megbukott. Jó hír, hogy az API-ban külön beállítható, mennyi „érvelési energiát” használjon: a legegyszerűbb válaszoktól egészen az extra magas szintű, mély elemzésekig. Ez nem csak minőségi, hanem költségszempontból is releváns, mert pontosabban lehet optimalizálni a felhasználást.
Drágább lett, de nem mindenkinek
Az árakról is érdemes őszintén beszélni. A ChatGPT 5.2 körülbelül 40 százalékkal drágább, mint az 5-ös és az 5.1-es verziók. Ugyanakkor a gyorsítótárazott bemenetekre jelentős kedvezmény jár, és elérhető különböző feldolgozási módokban, beleértve a batch feldolgozást is. Ez azt jelzi, hogy a modell elsősorban professzionális, üzleti és fejlesztői felhasználásra lett pozícionálva.
A remény
Összességében én úgy látom, hogy a ChatGPT 5.2 egy érettebb, kiegyensúlyozottabb lépés előre. Nem forradalmi abban az értelemben, hogy mindent újraírna, de nagyon határozottan a „használhatóbb AI” irányába mozdul. Ha az 5-ös modell kicsit hűvös és merev volt, a 5.2 már inkább egy jól képzett, megbízható munkatárs benyomását kelti. Kezdőknek pedig azért különösen érdekes, mert jól mutatja, merre tart az AI: kevesebb látványos ígéret, több valódi, mindennap használható fejlődés.
Remélem hosszútávon sikerül kellemesen csalódnom ebben a modellben, ugyanis, jelenleg szinte teljesen átálltam Claude Sonnet 4.5 és Claude Opus 4.5 modellek pro verzióinak használatára. Nem csupán a mindennapokban, hanem a kódolásban is.
A felhős monitoring az egyik legösszetettebb terület az Azure-ben. Rengeteg szolgáltatás, beállítás, rövidítés és „best practice” kering körülötte, miközben a legtöbb ember csak azt szeretné tudni: látom-e, mi történik a virtuális gépemen; és ha több virtuális gépem van, tudom-e azok naplóbejegyzéseit egy helyen kezelni.
Nemrég az egyik mentoráltammal belekóstoltunk ebbe a világba. Ő kifejezetten rákapott a monitoring ízére, ami jó jel, viszont közben számomra is világossá vált, hogy nem a tankönyv szerinti megoldás a legjobb megközelítés ahhoz, hogy valóban megértsük ennek a világnak a működését.
Miért mondom ezt? Mert sokan úgy gondolják – és én is így mutattam be korábban –, hogy akkor kell beállítani a naplófájlok gyűjtését, amikor a virtuális gépet létrehozzuk. Hiszen amikor összetett rendszerekkel dolgozunk, általában egy előre beállított, finomhangolt monitoring rendszerbe illesztjük be az új gépeket.
Ezzel azonban pont azt a logikus, jól követhető utat kerülöm el, amelyen keresztül az érdeklődők a legkönnyebben elérik a céljukat: hogy gyorsan átlássák ezt a komplex világot.
Mit javaslok tehát? Kövessük a józan észt, és gondoljuk végig, mi egy alkalmazás vagy rendszer természetes evolúciója. Hogyan történik ez a valóságban, amikor kicsiben kezdünk?
Először létrehozok egy vagy több virtuális gépet, alapbeállításokkal, majd telepítem rájuk az alkalmazásaimat. Jön még egy gép, aztán még egy. Egy idő után azt veszem észre, hogy egy nagy, összetett rendszerem van, viszont vak vagyok: nem látom, mi történik a virtuális gépeimen, és nem látom a gépek által létrehozott naplóbejegyzéseket sem.
Ekkor jön a következő lépés: beállítom az Azure Monitor megoldását, hogy legyen szemem és fülem. És innentől már értelmezhető adatokat kapok arról, mi történik a rendszeremben.
Ugye milyen egyszerű így?
Ebben a cikkben erről – pontosabban ennek egy pici, de nagyon fontos szeletéről – fogok egy alap konfigurációt bemutatni. A fókusz a naplóbejegyzések központi kezelése lesz az Azure Monitoron belül.
Ennek két legfontosabb komponense:
a Log Analytics Workspace
és a Data Collection Rules (DCR)
Ezek adják az egész VM-alapú naplózás és megfigyelés gerincét.
Később górcső alá vesszük az Azure Monitor további elemeit is, hogy jobban belelássatok ebbe a nagyon komplex, mégis rendkívül izgalmas világba.
Nem elméleti áttekintést szeretnék adni, és nem is egy „mindent bele” vállalati monitoring architektúrát bemutatni. A célom sokkal egyszerűbb és gyakorlatiasabb:
megérteni, mi a szerepe a Log Analytics Workspace-nek,
tisztázni, mire valók a Data Collection Rules,
és végigmenni egy egyszerű beállításon Linux és Windows Server virtuális gépek esetén is.
Alapfogalmak és szerepek
Log Analytics Workspace (LAW) a központi adattároló, ahová minden log és metrika beérkezik. Gyakorlatilag egy speciális adatbázis, amely KQL (Kusto Query Language) lekérdezéseket támogat. Egy workspace több száz VM-et is kiszolgálhat, de szervezeti vagy biztonsági okokból létrehozhatsz többet is.
Data Collection Rule (DCR) határozza meg, hogy mit gyűjtsünk, honnan és hová küldjük. Ez a „szabálykönyv”, ami összeköti a forrásokat (VM-ek) a célponttal (LAW). A DCR-ek rugalmasak: különböző szabályokat alkalmazhatsz különböző VM-csoportokra.
Azure Monitor Agent (AMA) a VM-eken futó agent, ami a DCR alapján gyűjti és továbbítja az adatokat. Ez váltotta le a régi Log Analytics Agent-et (MMA) és a Diagnostics Extension-t.
A terv
Az alábbi lépéseket fogjuk követni tehát:
Virtuális gépek (Linux, Windows) létrehozása (nagyon felületesen, mert tényleg alapbeállításokkal hozzuk létre)
Log Analytics Workspace létrehozás
Data Collection Rule létrehozás és beállítás
Azure Monitor Agent ellenőrzése a Virtuális gépeken
Naplóbejegyzések lekérdezése központilag
Öt egyszerű lépés, ami segít megérteni hogyan működik ez a szörnyeteg.
1. lépés: Virtuális gépek létrehozása
Amikor elindul a vállalkozásunk, először egy vagy tövv gépet hozunk létre. Tegyük ezt most is.
Minden lépést a Portálon fogunk elvégezni, az egyszerűség kedvéért.
A Marketplace-n keresd meg: „Ubuntu 24.04 LTS – all plans including Ubuntu Pro”
Ebből hozz létre egy „Ubuntu Server 24.04 LTS”
Gép neve legyen „linux-monitor”
Méret legyen egy kicsi, pl.: Standard_B1s
Hitelesítés típusa legyen Nyilvános SSH-kulcs
Lemez esetén elegendő egy Standard SSD
Hálózatnál létrehozhatunk egy monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre az első virtuális gépünket
Windows vm
A Marketplace-n keresd meg: „Windows Server”
Ebből hozz létre egy „Windows Server 2022 Datacenter”
Gép neve legyen „windows-monitor”
Méret legyen egy kicsi, pl.: Standard_B2s
Rendszergazdai fióknál állítsunk be egy felhasználónevet és a hozzátartozó jelszót
Lemez esetén elegendő egy Standard SSD
Hálózatnál válasszuk a linux-nál létrehozott monitor-vnet nevű hálózatot
A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a második virtuális gépünket
2. lépés: Log Analytics Workspace létrehozása
Eljutottunk tehát oda, hogy megvannak a gépeink, de nem tudjuk mi is van velük, vagy mi történik az alkalmazásokkal. Kell nekünk egy központi tároló, ahová a gépeken keletkező naplóbejegyzések és/vagy metrikák beérkeznek. Most ezt hozzuk létre.
Felül a keresőben keresd meg: „Log Analytics-munkaterületek„, majd kattintsunk rá.
Kattints: „+ Létrehozás” gombra
Töltsd ki:
Előfizetés: válaszd ki
Erőforráscsoport: válaszd a korábban létrehozttat
Név: egyedi név (pl.: law-mentor)
Régió: válaszd azt amit az erőforráscsoportnál és a VM-eknél is használtál
Kattints: „Áttekintés és létrehozás”, majd hozd létre. 1-2 perc és létrejön.
Most már van egy adatbázisunk, ahová gyűjthetjük az adatokat.
3. lépés: Data Collection Rule létrehozás és beállítás
Egyre közelebb vagyunk a célunkhoz. Most hozzuk létre azt a szabályt, hogy a létező VM-ekről milyen adatokat szeretnénk látni a központi adatbázisban (Log Analytics Workspace)
Alap adatok
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Beállítások > Adatgyűjtési szabályok elemet és kattintsunk rá
Kattints: „+ Létrehozás” gombra
Add meg a szabály alap adatait:
Szabály neve: pl: dcr-vm-logs-all
Előfizetés és erőforráscsoport: ugyanaz, mint a LAW
Platform típusa: válaszd „All” (Ha Windows és Linux is kell. Mi most ezt szeretnénk)
Adatgyűjtési végpont: Nekünk ez most nem szükséges, mert Azure-on belüli gépekhez hozzuk létre
Kattints: „Következő: Erőforrások >” gombra
Erőforrások fül: Itt adod hozzá a VM-eket, amikről gyűjteni szeretnél. Kattints „+ Erőforrások hozzáadása” gombra és válaszd ki a VM-eket amelyeket korábban létrehoztál. (Az AMA agent automatikusan települ, ha még nincs fent.)
Kattints: „Következő: Gyűjtés és küldés >” gombra
Gyűjtés és küldés fül: Itt definiálod az adatforrásokat (mit olvasson be a VM-ekről)
Windows adatforrás
Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Windowsos eseménynaplók” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Mi most itt csak az Alapszintű elemeket fogjuk gyűjteni. Jelöld ki mindet.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megfelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Windows naplóbejegyzések betöltése készen áll
Linux adatforrás
Kattints „+ Adatforrás felvétele”
Adatforrás típusánál válaszd a „Linux Syslog” elemet. Ezzel lehetőséged van beolvasni azokat az eseménynapló-bejegyzéseket, amelyekre szükséged van. Ezeket nagyon részletesen testre lehet szabni.
Ezután be kel állítanunk, hogy mi a minimális naplózási szint, amit szeretnénk beállítani. Alapvetően senkinek nem javaslom, hogy beállítsa az LOG_INFO szintet, de a példánk miatt, most ezt tesszük.
Majd, szintén a példa kedvéért, kiválasztjuk az összes szolgáltatást.
Ebben az ablakban kattints „Következő: Cél >” gombra.
Ellenőrizd, hogy a megelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
Ezzel a Linux naplóbejegyzések betöltése is készen áll.
Szabály véglegesítése
Megvan a két adatforrásunk. A többi beállítást nem is módosítjuk, hanem hagyjuk úgy, ahogy az látjuk, tehát menjünk a Felülvizsgálat + létrehozás lapra
És hozzuk létre a szabályt.
Most várnunk kell 5-10 percet, amíg elindul az adatok betöltése. Amíg ez megtörténik, ellenőrizzük le mindegyik VM-ünk esetén, hogy a monitor ügynők települt-e.
Megjegyzés: A teljesítmény metrikák beállítása is hasonlóan történik, ott az adatforrás típusa lesz más.
4. lépés: Azure Monitor Agent ellenőrzése a Virtuális gépeken
Ezt mindkét típusú (Linux, Windows) virtuális gépnél ugyanott tudjuk megtenni.
Keressük meg az erőforráscsoportban a virtuális gép erőforrást (linux-monitor vagy windows-monitor) és kattintsunk rá
A bal oldali panelon keressük meg a Beállítások > Alkalmazások és bővítmények elemet és kattintsunk rá
Itt kell látnunk az AMA elemet
Windows esetén: AzureMonitorWindowsAgent
Linux esetén: AzureMonitorLinuxAgent
Ha ez hiányzik, akkor nem fogjuk tudni gyűjteni a naplóbejegyzéseket és metrikákat.
Most pedig elérkezett a pillanat amire vártunk: központilag le tudjuk kérdezni a begyűjtött adatokat. Azokat tudjuk elemezni, vagy további feldolgozást végezhetünk rajuk. Nincs határ.
Elemzések áttekintése
Amint az adatok begyűjtése elindul, a LAW munkába lendül és rengeteg hasznos információt biztosít számunkra. Ebből jelenleg csak az alap elemzési diagrammot szeretném megmutatni.
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak
Naplóbejegyzése a portálon
Most pedig megmutatom az ajtót a naplóbejegyzések keresésének végtelen univerzumába.
Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
Felül válaszd ki a megfelelő Workspace-t
Majd kattints a nevére
Megnyílik az elemzési áttekintő ablak
A bal oldali panelon keressük meg a Figyelés > Munküzetek elemet és kattintsunk rá.
Itt találsz előre elkészített elemet.
Mi most újat hozunk létre, mert az a legegyszerűbb. Kattints: „+ Új”
A megjelenő lapon a Log Analytics-munkaterület Naplók (Analytics) Lekérdezés rész a KQL query editor. Ide írhatod meg az egyedi lekérdezésedet, amit utána el is menthetsz.
Illeszd me az alábbit, majd kattints a Lekérdezés futtatása gombra
// Windows Információs bejegyzések az elmúlt 1 órából
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Information")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc
Ezt is próbáld ki:
// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(3h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc
És egyéb példák:
// Összes Windows Event az elmúlt 24 órából
Event
| where TimeGenerated > ago(24h)
| summarize count() by EventLog, EventLevelName
| order by count_ desc
// Windows hibák és figyelmeztetések
Event
| where TimeGenerated > ago(1h)
| where EventLevelName in ("Error", "Warning")
| project TimeGenerated, Computer, EventLog, EventLevelName, RenderedDescription
| order by TimeGenerated desc
// Linux syslog események
Syslog
| where TimeGenerated > ago(24h)
| summarize count() by Facility, SeverityLevel
| order by count_ desc
// Linux auth események (bejelentkezések)
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "auth" or Facility == "authpriv"
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc
// Adott VM összes logja
Event
| where Computer == "linux-monitor"
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc
Tippek
Ezzel végeztünk is. Ugye, hogy milyen sima volt?
Fontos: A KQL lekérdezéseket érdemes tanulmányozni, hogy elérd a kívánt eredményt.
Problémák elkerülése:
Amikor eldöntjük, mit gyűjtünk, rengeteg lehetőség van. Én azt javaslom, hogy tudatosan tervezzük meg mire is van igazán szükségünk, mert könnyű elkövetni az alábbi hibákat:
túl sok adat gyűjtése feleslegesen,
nem egyértelmű, hogy egy VM miért nem küld naplót,
Linux és Windows eltérő logikájának keverése (ezért sem optimális a jelenlegi beállításunk),
vagy egyszerűen az, hogy nem világos, mi történik a háttérben.
Költségoptimalizálás tippek:
Ne gyűjts mindent „Information” szinten, csak Warning és felette
Állíts be data retention limitet (30 nap alap, növelhető)
Használj data collection rule transformations-t a felesleges adatok szűrésére
Összefoglalás
Együtt beállítottunk egy teljes körű log gyűjtési megoldást Azure Monitor segítségével. Létrehoztunk egy Log Analytics Workspace-t, ami központi tárolóként szolgál minden begyűjtött adatnak.
Konfiguráltunk egy Data Collection Rule-t, amely Windows Event Logs és Linux Syslog forrásokból gyűjti az eseményeket, és hozzárendeltük a monitorozni kívánt VM-ekhez.
Az Azure Monitor Agent automatikusan települt a gépekre, így azok azonnal elkezdték küldeni az adatokat. A begyűjtött logokat a Log Analytics Workspace Naplók menüpontjában KQL lekérdezésekkel tudjuk elemezni és keresni.
Ha most ismerkedsz az Azure Monitoring-al, vagy eddig csak „kattontgattad”, mert muszáj volt, akkor ez a cikk neked szólt.
Rövid gyakorlás után biztos vagyok benne, hogy hamar összeáll a kép.
