Tartalomjegyzék

Bevezetés

A távoli asztali környezetek számos működési adatot generálnak, a CPU és memóriahasználattól kezdve a csatlakoztatott felhasználókig, egyidejű munkamenetekig és alkalmazásigényig. A kihívás az, hogy eldöntsük, mely jelek számítanak, és hogyan kapcsolódnak egymáshoz. Ez a cikk elmagyarázza, hogy mit követ nyomon a távoli asztali monitorozó szoftver, hogyan különbözik a munkamenet láthatósága a szervermonitorozástól, és hogyan használhatják az IT csapatok a valós idejű és történeti adatokat a teljesítményproblémák diagnosztizálására.

Mit figyel meg valójában a Remote Desktop Monitoring szoftver?

A távoli asztali monitorozás számos fogalmat magában foglal. Néhány eszköz a szerveroldali erőforrásokra összpontosít, míg mások a távoli asztali protokoll (RDP) vagy a távoli asztali szolgáltatások (RDS) használatával leltározzák a kapcsolatokat. Azok az eszközök, amelyek biztonságra összpontosító megközelítést alkalmaznak, auditálhatják és rögzíthetik a felhasználói tevékenységet.

Az IT számára értelmes, hogy ezeket az eszközöket 5 kategóriára bontsuk:

Megfigyelési réteg Amit válaszol Tipikus információ
Infrastruktúra Az host egészséges? CPU, memória, lemez, sávszélesség, elérhetőség
Kapcsolat Ki csatlakozott és mikor? Felhasználó, bejelentkezési idő, kapcsolat állapota
Munkamenet Mi történik a távoli munkamenetek során? Csatlakozott felhasználók, párhuzamos munkamenetek, időtartam, munkamenet állapota
Felhasználói élmény A távoli munkamenet válaszkész? Bemeneti késleltetés, késleltetés, bejelentkezési késleltetések, alkalmazás válaszkészsége
Tevékenység Milyen alkalmazások vagy tevékenységek érintettek? Alkalmazás használat, folyamatok, audit események vagy munkamenet felvételek

Ezek kapcsolódnak egymáshoz, de nem feltétlenül cserélhetők fel, mivel az egyik jelentheti a CPU telítettségét, de nem árulja el, hogy melyik munkamenet volt az első érintett, míg egy auditáló platform azonosíthatja, hogy ki csatlakozott, de nem magyarázza el, miért romlott a teljesítmény.

A munkamenet-felvételi szoftver ezt egy lépéssel tovább viszi azáltal, hogy részletes bizonyítékokat gyűjt arról, ami a távoli környezetben történt, további biztonsági, adatvédelmi, megőrzési és tárolási szempontokat bevezetve.

Az első kihívás tehát a távoli asztali monitorozó szoftverek összehasonlításakor az, hogy meghatározzuk, milyen láthatóságra van valójában szüksége az IT-nek.

Miért más a session szintű láthatóság, mint a szervermonitorozás?

Hagyományos szervermonitorozás az eszközök megkérdezik, hogy a gép rendben van-e. Magas a CPU kihasználtság? Alacsony a memória? Növekszik a lemez kihasználtság? Online van a szerver?

Ezek a mutatók továbbra is relevánsak egy RDS hosztolási forgatókönyvben, de van egy másik réteg, amelyet figyelembe kell venni. A megosztott RDS infrastruktúra azt jelenti, hogy a gazdagép szintjén a CPU, a memória, a tárolás és a hálózati kapacitás több felhasználó és alkalmazás között oszlik meg.

A munkamenet szintjén minden felhasználó alkalmazásainak és folyamataiknak egyedi igényeik vannak. Egy RD Session Host általában egészséges lehet, miközben az egyik felhasználó alkalmazásai lefagynak, vagy egy lassú munkamenet nem jelenti azt, hogy az egész szerver telítve van.

A különbség jelentős a hibaelhárítás szempontjából. Ha tíz felhasználó ugyanazon a szerveren egyszerre kezd lelassulni, érdemes először a szerver megosztott erőforrásait megvizsgálni. Ha csak egy felhasználónak vannak problémái, akkor a hiba valószínűleg az adott munkamenetre, annak alkalmazásaira és kapcsolatra korlátozódik.

A távoli asztali monitorozó eszközök a leghatékonyabbak, amikor lehetővé teszik az adminisztrátorok számára, hogy váltogassanak ezek között a nézőpontok között, és kapcsolatokat vonjanak a szerver általános állapota és az egyes felhasználói munkamenetek állapota között.

Mik a legfontosabb távoli asztali mutatók?

Senki nem egyetlen mérőszám határozza meg a távoli asztali környezet egészségét. Az adminisztrátoroknak elegendő kontextusra van szükségük a jelenlegi terhelés, erőforrás-felhasználás és a felhasználói élmény értelmezéséhez.

Hány felhasználó és munkamenet aktív?

A munkamenet-összegek képezik ennek a beszélgetésnek az alapját.

A releváns adatok közé tartoznak a csatlakozott felhasználók, az aktív és a leválasztott munkamenetek. párhuzamos munkamenet számlálás , szerverek közötti elosztás, csúcsidőszakok és történelmi egyidejűség.

A párhuzamos felhasználói trendek előnyt élveznek a létszámokkal szemben egy távoli asztali rendszer teljesítményének értékelésekor, mivel a kapacitást jellemzően a párhuzamos terhelés határozza meg, nem pedig a regisztrált felhasználók száma. Egy gép, amely 200 alkalmi felhasználót szolgál ki, jelentősen nagyobb terhelésnek lehet kitéve, mint egy 40 felhasználós párhuzamos munkamenet, amely nagy teljesítményű alkalmazásokat futtat.

A párhuzamossági mutatók értéke, amelyet az infrastruktúra statisztikái egészítenek ki, annak megállapítására szolgál, hogy van-e összefüggés a csatlakozott felhasználók számának növekedése és az erőforrás-fogyasztás növekedése között.

A szerver erőforrásai lépést tartanak a munkamenet igényeivel?

A CPU, memória, lemezaktivitás és elérhető tároló továbbra is a legfontosabb mutatók a távoli asztal figyeléséhez.

Az érdekes kérdés nem az, hogy a CPU elérte-e a bizonyos százalékot, hanem az, hogy mikor volt terhelés alatt és mi történt még ugyanabban az időben.

Például egy folyamatos CPU-terhelés összefügghet a reggeli bejelentkezési rohamokkal, a párhuzamos munkamenetek számának növekedésével, egy ütemezett folyamattal vagy egy adott üzleti alkalmazás intenzív használatával.

A két dolog közötti kapcsolat általában fontosabb, mint a kihasználási érték.

Mely alkalmazások és folyamatok hajtják a terhelést?

Az alkalmazás láthatósága további kontextust biztosít.

A használt alkalmazások megértése, amikor a kereslet megnő, és hogy mely folyamatok fogyasztják a legtöbb erőforrást, lehetővé teszi az adminisztrátorok számára, hogy a felhasználói tevékenységet összekapcsolják az infrastruktúra viselkedésével.

Az alkalmazásfigyelés foglalkozhat ezekkel a kérdésekkel. Megjelenik teljesítményprobléma, amikor egy adott alkalmazást intenzíven használnak? Vannak olyan munkamenetgazdák, amelyek intenzívebb alkalmazáskészletet futtatnak? Karbantartanak vagy licencelnek olyan alkalmazásokat, amelyeket ritkán használnak?

Ez az információ értékkel bír, nemcsak a hibaelhárítás szempontjából, hanem az általános infrastruktúra és szoftveradminisztráció szempontjából is.

Hozzájárul a hálózat vagy a felhasználói élmény a problémához?

A távoli asztali munkamenetek természetüknél fogva interaktívak, így a hálózati vagy válaszidő problémák azonnal észlelhetők a végfelhasználók számára.

A sávszélességet más szerver teljesítménymutatókkal együtt kell értékelni, mivel egy szervernek lehet szabad CPU- és memória kapacitása, miközben a kapcsolatok lelassulnak a kommunikációs lánc más pontján lévő szűk keresztmetszet miatt. A megértés RDP teljesítmény magas késleltetésű hálózatokon segíthet megkülönböztetni a hálózati válaszidő problémáit a gazdaoldali erőforrás-korlátozásoktól.

Néhány RDS környezet több végfelhasználói élménybeli betekintést kínálhat, mint mások. A Microsoft Performance Monitor például rendelkezik Felhasználói Bemeneti Késleltetés számlálókkal, amelyek képesek azonosítani a késleltetéseket a munkamenet és a folyamat szintjén. A Microsoft ezt a funkciót a munkamenetszámok, a CPU használat és a válaszidő összekorrelálásának módszereként dokumentálja RD Session Host szervereken.

Nem minden távoli asztali megfigyelő eszköz tartalmazza ugyanazokat a késleltetési vagy bemeneti késleltetési mutatókat. Az IT-adminisztrátoroknak érdemes ellenőrizniük, hogy mit kínál valójában egy szolgáltató a felhasználói élmény információival kapcsolatban, ahelyett, hogy feltételeznék, hogy azok jelen lesznek.

Hogyan segíthet a Remote Desktop Monitoring a csapatának, amikor lassú munkameneteket kell hibaelhárítani?

A távoli asztali megfigyelés értéke legjobban akkor látható, amikor az adminisztrátorok több jelet vesznek és összekorrelálnak őket.

Amikor egy felhasználó rámutat, hogy az RDP lassú, akkor a hatást írja le, nem az okot. Az elsődleges prioritásod, hogy megértsd a probléma terjedelmét.

Egy felhasználónak vannak problémái? Van több felhasználó, aki ugyanazon a hoszton van? Vannak felhasználók több szerveren ugyanazzal a problémával?

A probléma körének meghatározásával a megfigyelési betekintéseid segíthetnek a keresésed fókuszálásában:

Tünet Hasznos ellenőrzések
Egy felhasználó lassú. Munkamenet állapot, alkalmazások, folyamatok, kapcsolati feltételek
A legtöbb felhasználó egy szerveren lassú. CPU, memória, lemez I/O, folyamat használat, egyidejű munkamenetek
A több szerveren lévő felhasználók lassúak. Megosztott hálózati vagy infrastruktúra függőségek
A teljesítmény napi szinten romlik. Párhuzamosság, ütemezett feladatok, alkalmazáscsúcsok
A felhasználók gyakran megszakadnak Szerver elérhetőség, hálózati feltételek, szolgáltatási és kapcsolati események
Egy alkalmazás folyamatosan rosszul teljesít. Alkalmazás használat, kapcsolódó folyamatok és erőforrás-felhasználás

A cél a korreláció. A CPU csúcsok többet jelentenek a párhuzamosság növekedésének kontextusában. A magas sávszélesség kihasználtság figyelemre méltóbb, ha több felhasználói panasz is érkezik. Egy visszatérő teljesítményprobléma könnyebben azonosítható, ha tudja, hogy ugyanaz az alkalmazás vagy terhelés fordul elő minden alkalommal.

A monitoring nem mindig azonosítja a gyökérokot, de rögzíti az üzemeltetők által szükséges működési kontextust, hogy szűkítsék a lehetséges gyanúsítottak körét.

A memória alapú hibaelhárítás utólag nem ugyanaz, mint a környezet vizsgálata az incidens időpontjában.

Valós idejű megfigyelés, figyelmeztetések és történeti jelentések: Miért fontosak ezek mind?

A monitoring hasznos, amikor lehetővé teszi, hogy három különböző működési kérdésre válaszolj: mi történik jelenleg, mikor kell az IT-nek lépéseket tennie, és mi történt korábban?

Mi történik éppen most?

A valós idejű megfigyelést az adminisztrátorok használhatják a jelenlegi szerver teljesítmény, a bejelentkezett felhasználók, az alkalmazásfolyamatok és a hálózati tevékenység ellenőrzésére.

Ez az információ életfontosságú lehet egy incidens során, mivel lehetővé teszi az adminisztrátor számára, hogy megállapítsa, van-e még nyomás az erőforrásokon vagy szokatlan terhelés zajlik-e.

A valós idejű érték aktuális adatokat szolgáltat, de ennyi. A mutató jelenleg csak tájékoztató jellegű. Ami most normálisnak tűnik, az abnormális volt, amikor a felhasználó tapasztalta a problémát.

Mikor igényel valami figyelmet?

Az értesítések a megfigyelést passzív adatgyűjtésből proaktív és operatív folyamattá alakítják.

A rendszergazdák meghatározzák, mi érdemel figyelmet: tartós processzorhasználat, memória nyomás, lemezaktivitás, túlzott aktív felhasználók vagy szerverleállás.

Monitoring küszöbértékek még mindig ésszerűen kell alkalmazni; egy rövid CPU aktivitáscsúcsra számítani lehet, de a csúcsidőszakok alatt tartós nyomás kapacitásproblémát jelezhet.

Mi történt az incidens előtt?

A történeti jelentések olyan mintázatokat tárnak fel, amelyeket az élő metrikák nem tudnak. A Microsoft azt javasolja, hogy használja Teljesítményfigyelő adatgyűjtés a teljesítményszámlálók időbeli rögzítése, amikor időszakos Windows Server teljesítményproblémákat vizsgálunk.

A CPU 90 százalékra emelkedik öt percig. Ha ez egy elszigetelt eset egy máskülönben ismert tétel feldolgozásában, akkor nem feltétlenül jelez problémát. De ha a CPU minden hétköznap körülbelül ugyanabban az időben 90 százalékra emelkedik, amikor a párhuzamosság átlépi a megadott küszöböt, az értékes információ a kapacitás tervezéséhez.

A történelmi alapvonalak gyakran fontosabbak, mint az egyéni küszöbértékek, mert megmutatják, mi a normális egy adott szerver, alkalmazáskeverék és felhasználói populáció esetében.

Mikor elegendőek a natív Windows megfigyelő eszközök?

A Windows már egy meglehetősen robusztus eszközkészletet biztosít a hibaelhárításhoz.

A Feladatkezelő és az Erőforrás-figyelő megjeleníti a jelenlegi erőforrás-használatot. A Teljesítménymérő képes gyűjteni a Windows teljesítményszámlálóit, beleértve a session és folyamat szintű Felhasználói Bemeneti Késleltetést a Windows Server támogatott verzióin. Az Eseménynéző az operációs rendszerrel és az RDS-hez kapcsolódó eseményekkel foglalkozik, míg a PowerShell használható sok adminisztrációs feladat lekérdezésére és automatizálására.

Egyetlen szerver hibaelhárításához vagy egy adott probléma kivizsgálásához ezek az eszközök elegendőnek bizonyulhatnak egy tapasztalt adminisztrátor számára.

Azonban a több szerver figyelésének szükségessége vagy a helyzet korábbi előfordulásának szempontjából történő áttekintése megkövetelheti, hogy az információt több forrásból nyerjék ki.

A központosított megfigyelés hasznos olyan helyzetekben, amikor az IT-nak több mint egy gazdagépet kell figyelnie egy konzolon keresztül, történeti információkat kell mentenie későbbi felhasználásra, rendszereket és időkereteket kell összehasonlítania, jelentéseket kell készítenie a felhasználói tevékenységről és egyidejűségről, vagy figyelmeztetéseket kell beállítania.

Egy ilyen megközelítés értéke nem feltétlenül abban rejlik, hogy a Windows nem biztosít metrikákat.

Inkább abban rejlik a képesség, hogy ezt az információt összevonjuk, tároljuk és összefüggésbe hozzuk, hogy a rendszergazdák számára hasznosabbá tegyük.

Jelenti ez azt, hogy rögzíti a felhasználókat, ha használja a Remote Desktop Session Monitoring-ot?

Nem. A kifejezéseket gyakran felcserélhetően használják, de a munkamenet figyelése és a munkamenet rögzítése jelentősen eltérő terjedelmet és képességeket jelent.

Míg a távoli asztali munkamenet figyelése csak a csatlakozott felhasználókat, egyidejű munkameneteket, erőforrás-használatot, munkamenet-történetet vagy alkalmazás-használatot figyelheti meg, a munkamenet rögzítése sokkal részletesebb adatokat rögzítene a távoli munkamenetben zajló tevékenységekről, a terméktől függően, mint például a képernyő tartalma, alkalmazás tevékenységek, vágólap tevékenységek vagy egyéb események.

A felvételi ülések értelmesek lehetnek bizonyos kiváltságos hozzáférés, harmadik fél általi hozzáférés, auditálás vagy biztonsági forgatókönyvek esetén, de további kérdéseket vetnek fel a megőrzéssel, hozzáféréssel, tárolással és adatvédelemmel kapcsolatban.

A legtöbb napi távoli asztali művelethez a munkamenet minden részletének rögzítése felesleges és nem kívánatos az IT csapat számára, mivel csak annyi információra van szükségük a munkamenetről, amennyi a teljesítmény megfigyeléséhez és elemzési célokhoz elegendő.

Hogyan javíthatja a kapacitás-tervezést a Remote Desktop Monitoring használatával?

A távoli asztali infrastruktúra esetében a terhelési sűrűség fontos szempont.

A konfigurált fiókok száma keveset mond a párhuzamos felhasználók számáról, az általuk futtatott alkalmazásokról és azok intenzitásáról.

A történelmi megfigyelés elérhetővé teszi ezt az információt.

A párhuzamos felhasználók elemzésével és a CPU, memória, lemez és hálózati kihasználtságokkal való összehasonlításukkal az IT-adminisztrátorok hasznos betekintést nyernek a környezetükbe. Látják, mikor kezdik a terhelések befolyásolni az infrastruktúrát, mely munkaterhelések felelősek ezért, és hogy a tendencia növekszik-e.

Az információ felhasználható olyan intézkedések indoklására, mint a terhelés egyensúlyának megteremtése a hosztok között, további szerverek hozzáadása, meglévő szerverekhez további erőforrások hozzáadása, nehéz alkalmazások ütemezése vagy olyan alkalmazások vizsgálata, amelyek aránytalanul nagy mennyiségű erőforrást fogyasztanak.

Ez a megközelítés sokkal pontosabb, mint a felhasználók szerverenkénti általános ajánlása. Microsoft’s Távoli asztali munkamenet hoszt méretezési útmutató hasonlóan javasolja a munkaterhelés típusa, a felhasználói sűrűség és a felhasználói élmény méréseinek értékelését, ahelyett, hogy egyetlen általános kapacitási számra támaszkodnánk. Két, azonos felhasználói bázissal rendelkező cégnek teljesen eltérő alkalmazás- és infrastruktúraigényei lehetnek.

Milyen típusú követelményeket érdemes figyelembe venni, amikor távoli asztali megfigyelő szoftvert keres?

A legjobb távoli asztali megfigyelő szoftver nem feltétlenül az a termék, amely a legtöbb adatot gyűjti. Az az, amelyik a kezelt környezethez szükséges láthatósági szintet biztosít.

A legtöbb IT üzemeltetési csapat számára a kulcsfontosságú követelmények egyértelműek:

  • c centralizált láthatóság több szerver között
  • aktív felhasználók és egyidejű munkamenet információ
  • CPU, memória, lemez és hálózat figyelése
  • alkalmazás- és folyamatláthatóság
  • történeti jelentések és trendelemzés
  • konfigurálható figyelmeztetések
  • praktikus jelentési és exportálási lehetőségek

A platformnak a korrelációk egyszerűsítését is lehetővé kell tennie. A session számok értékesebbé válnak, amikor az adminisztrátorok össze tudják hasonlítani őket a szerver terhelésével. Az alkalmazás használata hasznosabbá válik, amikor időben megvizsgálható.

A telepítési és adminisztrációs többlet is számít. Egy olyan megfigyelő platform, amely a távoli infrastruktúra egyszerűsítésére szolgál, nem szabad, hogy aránytalan infrastruktúra- vagy menedzsmentbonyolultságot vezessen be.

Végül ellenőrizze, hogy a szolgáltatók pontosan mit értenek olyan kifejezések alatt, mint a munkamenet-figyelés, a felhasználó-figyelés és a távoli asztali figyelés. Az egyik platform a csatlakoztatott felhasználók jelentését jelentheti, a másik RDP válaszidő-mutatókat kínálhat, míg egy harmadik teljes képernyőfelvételt kínálhat.

A terminológia hasonlónak tűnhet. A nyújtott láthatóság nagyon eltérő lehet.

Hogyan egyszerűsítheti a TSplus a távoli asztali megfigyelést?

Az IT csapatok számára, akik Windows távoli asztali infrastruktúrát kezelnek, a szerver- és felhasználói tevékenységet egy központosított megfigyelési környezetbe hozzuk. A rendszergazdák nyomon követhetik a CPU, memória, lemez és sávszélesség használatát, miközben figyelemmel kísérik a csatlakozott felhasználókat, a párhuzamos munkameneteket és az alkalmazás tevékenységet, segítve őket abban, hogy a infrastruktúra teljesítményét a tényleges távoli asztali igényhez kapcsolják.

TSplus Szerver Figyelés történeti jelentéseket és konfigurálható figyelmeztetéseket is biztosít, így az adminisztrátorok az élő metrikákra való támaszkodás helyett az ismétlődő munkaterhelési minták azonosítására képesek. Ez megkönnyíti a teljesítményproblémák kivizsgálását, a gyakorlati alapértékek meghatározását és a kapacitásigények előrejelzését több szerveren anélkül, hogy teljes felhasználói munkamenet rögzítést kellene bevezetni.

Következtetés

A hatékony távoli asztali monitorozás a korrelációról szól, nem pedig a lehető legnagyobb metrikakészlet összegyűjtéséről. A szerver teljesítménye, a munkamenet aktivitása, az alkalmazás iránti kereslet és a hálózati feltételek hasznosabbá válnak, amikor az adminisztrátorok együtt tudják őket megvizsgálni.

Ez a kombinált nézet segít az IT-nek megkülönböztetni az elszigetelt felhasználói problémákat a hoszt szintű szűk keresztmetszetektől, megérteni a visszatérő teljesítménymintákat, és jobb kapacitásbeli döntéseket hozni, ahogy a távoli asztali környezetek növekednek.

További olvasmányok

back to top of the page icon