Ha már éles üzemmódban megy a szoftverünk...

Mire tudjuk használni a Splunkot? Hogyan tudjuk a teljes szoftver és a felhasználók interakcióinak követésére használni az alkalmazást? Mikor és hogyan érdemes nekikezdeni a használatának? Többek között ezekre a kérdésekre kapjuk meg a cikkben a válaszokat.

Splunk az alkalmazás- és üzemeltetéstámogatásban

A felhasználók a legjobb tesztelők. No nem azért, mert értenek az alkalmazás működéséhez vagy a fejlesztéshez, hanem azért, mert ők tudják a legügyesebben kiválasztani azokat az opciókat és lehetőségeket az alkalmazásunkban, amelyeknek a tesztelése kimaradt, vagy amelyek az itt-ott fellelhető apróbb hibákat feltárják. Mit tehetünk, hogy a felhasználói élmény ne csökkenjen, az alkalmazást fejlesztő valamint üzemeltető szakembereink vállán levő terhek ne növekedjenek, és a bekövetkező esetleges hibákról mégis gyorsan tudomást szerezzünk?

A modern IT rendszerek bonyolult hálózatot alkotnak a vállalati infrastruktúrában. Az alkalmazások tranzakciós adatai több különböző rendszeren futnak keresztül, érintve hálózati és biztonsági eszközökön túl front-end és back-end alkalmazás szervereket, adatbázisokat. Virtualizáció használatával, mivel az alkalmazásunk nincs egy bizonyos hardverhez kötve, újabb szint kerül be a rendszer bonyolultságába.

A különböző rendszereink eltérő módon és formátumban generálnak adatot magukból, amelyekhez jellemzően egyedi, sziget alkalmazásokat lehet társítani mind a teljesítmény, mind pedig a működés monitorozására. Az ilyen sziget megoldások esetén, bár az adott komponens felügyeletét megfelelően látják el, nincs lehetőség a teljes tranzakciós folyamatok követésére, felügyeletére, illetve nincs lehetőség a különböző rendszerekből összegyűlt adatok érdemi és korrelált áttekintésére. Ehhez adódnak mind a rendszer, mind pedig az alkalmazás szintű konfigurációk, amelyek változásainak monitorozása nem csak biztonsági, hanem üzemeltetési szempontból is kritikus lehet. Szintén fontos, hogy az összegyűjtött adatok megfelelő részhalmaza csak a megfelelő személyek számára legyen hozzáférhető, de úgy, hogy az adott területért felelős szakember gyorsan és hatékonyan tudjon eljutni ahhoz az elemi eseményig, amely a felmerült problémát okozta.

Melyek azok a kérdések, amelyekre az informatikai és a fejlesztési csoportnak válaszolnia kell?

  • Megfelelő sebességűek a tranzakciók?
  • Fut a kiszolgáló szerver?
  • Fut a kiszolgáló alkalmazás?
  • Megfelelően gyors a bejelentkezés?
  • Hol van az alkalmazás esetleges lassulásának oka? A front-end alkalmazásban? A back-end alkalmazásban? Az adatbázisban?

Hogyan lehet a Splunk a szolgálatunkra?

A Splunk egy alkalmazás, amely képes bármilyen ASCII-alapú adat fogadására és indexelésére, amely indexek segítségével képes a tárolt adatokat a felhasználók számára gyorsan és egyszerűen elérhetővé tenni. Mivel a Splunk nem relációs adatbázist használ az adatok tárolására, így nincs előre definiált séma sem – azaz nem kell előre tudunk és eldöntenünk, hogy milyen adatokat tudunk fogadni.

A szoftver fejlesztési ideje alatt is már képes a Splunk bekapcsolódni a monitorozásba. Gondoljunk csak arra, hogy a központi forráskódmenedzsment eszközök (pl. SVN, GIT) is rendelkeznek konfigurációs fájlokkal, amelyeket lehetőségünk van monitorozni, a változásokat akár évekre visszakeresni, megtekinteni. A kódot készítő fejlesztők munkája (kód hozzáadása, törlése, módosítása, stb) is követhetővé válik a rendszer által generált logokon keresztül. Amennyiben központilag menedzselt felhasználókat használnak a bejelentkezéshez, egyszerű illesztéssel akár Microsoft Active Directory infrastruktúrából kinyerhető információkkal nem csak egyedi azonosítókat, hanem teljes, akár polgári neveket is hozzárendelhetünk egy-egy tevékenységhez. A fejlesztés menetéről folyamatos, akár időközönként küldött, visszatekintő statisztikaként, akár valós idejű grafikonként megjelenítve láthatjuk, hogy milyen tevékenység zajlik éppen. Amennyiben olyan belső hiba és tervezett funkció (feature) kezelő szoftvert használunk, amely akár adatbázisban, akár logokban képes az egyedi azonosítókat (pl Bug ID) tárolni, valamint a fejlesztő a forráskódon történő munka során a megjegyzéseiben feltüntetni az adott sorszámot, a Splunk kimutatásaiban egyértelműen összerendelhetőek a nyitott és lezárt jegyek, valamint az ezen dolgozó fejlesztők tevékenysége. Kis ügyességgel akár időnyilvántartás is készíthető – hiszen a rendszerből kinyerhető az egyes tevékenységek mérhető időtartama.

A már elkészült és „élesben” használt, illetve tesztelési fázisban levő verziókat futtató infrastruktúra elemei által generált logok, valamint az ezeket vezérlő konfigurációk is vizsgálhatóvá válnak a Splunk adatelemző szoftver segítségével. A logot generáló szoftverekhez értő szakemberek egyszerű és gyors módszerrel, úgynevezett „field extraction-nel” képesek a számukra releváns adatokat kiemelni a logokból, majd kimutatásokat készíteni belőlük. Ezek a kivonatok azután a teljes rendszerre érvényessé válnak, azaz bármilyen régi adaton is használhatóak. Az így kiemelt adatok adják az alapjait a kimutatásoknak, dashboardoknak.

A modern alkalmazások és keretrendszerek esetén sok esetben a rendszerek több soros log, illetve debug adatokat generálnak, amelyek összefűzése, egyben értelmezése még a feladat-specifikus támogató szoftvereknek is nehézséget okoznak. A Splunk képes az események nyitó és záró karakterisztikáját ismerve egyben kezelni akár több ezer soros java trace logokat is, valamint ezekből a fenti „field extraction”-módszerrel releváns adatokat megjeleníteni. A fejlesztők, amennyiben a szoftver által generált normál, illetve debug logokban egyértelműen meghatározzák, hogy az adott hiba hol keletkezett a szoftverben, könnyen azonosíthatják akár a fejlesztési, akár a konfigurációs problémákat.

Mivel a Splunk képes a kiszolgáló rendszerek teljes vertikumából fogadni az adatokat, lehetőségünk van a szoftver és felhasználók teljes interakciójának a követésére és elemzésére. Az egyedi azonosítók segítségével követhetővé válik a kérés-válasz kommunikáció, illetve a pontos időpecsételés segítségével akár az adott feladat elvégzésére fordított idő is. Az így kapott információk akár átalakítva is megjeleníthetők, illetve összehasonlíthatók a múltbéli adatokkal. Az eltéréseket grafikonon is meg lehet jeleníteni, illetve az éles rendszer esetén akár az előző időszeletben (pl. vizsgálat ideje előtti 5 perc), illetve a megelőző időszak azonos időpontjához mérve (pl. minden hétfőn délután 1-kor) beállított százalékos eltérés esetén akár riasztást is képes küldeni. Így a felhasználók jelzése előtt kezdhetjük el vizsgálni az alkalmazásunk működését, a válaszidőváltozás okait.

Hogyan kezdjünk neki?

A Splunk alkalmazás akár Windows, akár Unix-alapú központon képes futni. Telepítsük a legfrissebb verziót az általunk preferált operációs rendszerre, akár virtuális környezetben is, majd kezdjünk el adatokat gyűjteni. A fejlesztők és üzemeltetők kezdjék el a saját, nyers logokon történő kereséseiket a szabadszavas keresőt alkalmazva átültetni, illetve mentsék el ezeket a kereséseket későbbi használatra. Emeljünk ki fontos adatokat („field extaction”), és kezdjünk el kimutatásokat, dashboardokat összeállítani a jellemző hibák és működési karakterisztikák kimutatására. A meglevő grafikonok alapján határozzuk meg azokat a küszöbértékeket, amelyek az alkalmazásunk normális működését jellemzik, valamint állítsuk be azokat az értékeket vagy eltérési százalékokat, amelyek bekövetkezése esetén automatikus jelzést várunk el a rendszertől. Kezdjünk el újabb rendszereket, vagy ugyan azon rendszerek más adatait beirányítani a Splunk rendszerünkbe, hogy az ezekben tárolt információ segítségével is vizsgálni tudjuk az alkalmazásaink működését.

Amennyiben kíváncsi, hogyan lehet többet kihozni a Splunk-ból, hallgassa meg az alkalmazás- és üzemeltetéstámogatásról szóló Flexion-IS Kft. előadását az ITBN konferencián.

Szerző:
Flexion-IS Kft.

<< Vissza