cloud

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:

1. Virtuális gépek (Linux, Windows) létrehozása (nagyon felületesen, mert tényleg alapbeállításokkal hozzuk létre)
2. Log Analytics Workspace létrehozás
3. Data Collection Rule létrehozás és beállítás
4. Azure Monitor Agent ellenőrzése a Virtuális gépeken
5. 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.

Linux vm

1. Hozzunk létre egy erőforráscsoportot, ebbe fogunk most dolgozni
2. A Marketplace-n keresd meg: „Ubuntu 24.04 LTS – all plans including Ubuntu Pro”
3. Ebből hozz létre egy „Ubuntu Server 24.04 LTS”
4. Gép neve legyen „linux-monitor”
5. Méret legyen egy kicsi, pl.: Standard_B1s
6. Hitelesítés típusa legyen Nyilvános SSH-kulcs
7. Lemez esetén elegendő egy Standard SSD
8. Hálózatnál létrehozhatunk egy monitor-vnet nevű hálózatot
9. 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
10. És hozzuk létre az első virtuális gépünket

Windows vm

1. A Marketplace-n keresd meg: „Windows Server”
   
2. Ebből hozz létre egy „Windows Server 2022 Datacenter”
3. Gép neve legyen „windows-monitor”
4. Méret legyen egy kicsi, pl.: Standard_B2s
5. Rendszergazdai fióknál állítsunk be egy felhasználónevet és a hozzátartozó jelszót
6. Lemez esetén elegendő egy Standard SSD
7. Hálózatnál válasszuk a linux-nál létrehozott monitor-vnet nevű hálózatot
8. 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
9. É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.

1. Felül a keresőben keresd meg: „Log Analytics-munkaterületek„, majd kattintsunk rá.
   
2. Kattints: „+ Létrehozás” gombra
3. 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

1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
   
2. A bal oldali panelon keressük meg a Beállítások > Adatgyűjtési szabályok elemet és kattintsunk rá
3. Kattints: „+ Létrehozás” gombra
4. 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
     
5. Kattints: „Következő: Erőforrások >” gombra
6. 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.)
7. Kattints: „Következő: Gyűjtés és küldés >” gombra
8. 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

1. Kattints „+ Adatforrás felvétele”
2. 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.
3. Mi most itt csak az Alapszintű elemeket fogjuk gyűjteni. Jelöld ki mindet.
   
4. Ebben az ablakban kattints „Következő: Cél >” gombra.
5. Ellenőrizd, hogy a megfelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
   
6. Ezzel a Windows naplóbejegyzések betöltése készen áll

Linux adatforrás

1. Kattints „+ Adatforrás felvétele”
2. 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.
   
3. 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.
4. Majd, szintén a példa kedvéért, kiválasztjuk az összes szolgáltatást.
   
5. Ebben az ablakban kattints „Következő: Cél >” gombra.
6. Ellenőrizd, hogy a megelelelő LAW-ba mennek-e az adatok majd. Ha igen, kattints az Adatforrás felvétele gombra.
7. Ezzel a Linux naplóbejegyzések betöltése is készen áll.

Szabály véglegesítése

1. 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
2. É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.

1. Keressük meg az erőforráscsoportban a virtuális gép erőforrást (linux-monitor vagy windows-monitor) és kattintsunk rá
2. A bal oldali panelon keressük meg a Beállítások > Alkalmazások és bővítmények elemet és kattintsunk rá
3. 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.

5. lépés: Naplóbejegyzések lekérdezése központilag

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.

1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
2. A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
3. Felül válaszd ki a megfelelő Workspace-t
   
4. Majd kattints a nevére
5. 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.

1. Felül a keresőben keresd meg: „Monitorozás”, majd kattintsunk rá.
2. A bal oldali panelon keressük meg a Betekintések > Log Analytics-munkaterületek elemet és kattintsunk rá.
3. Felül válaszd ki a megfelelő Workspace-t
4. Majd kattints a nevére
5. Megnyílik az elemzési áttekintő ablak
6. A bal oldali panelon keressük meg a Figyelés > Munküzetek elemet és kattintsunk rá.
7. Itt találsz előre elkészített elemet.
   
8. Mi most újat hozunk létre, mert az a legegyszerűbb. Kattints: „+ Új”
9. 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.
10. 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.