)
)
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 távoli asztali megfigyelő 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ágorientált 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ába sorolják:
| 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, rendelkezésre állás |
| 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, egyidejű 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éslekedések, alkalmazásreakciók |
| 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 felcserélhetők, 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-nyilvántartó szoftver ezt egy lépéssel továbbviszi azáltal, hogy részletes bizonyítékokat gyűjt arról, mi történt a távoli környezet keretein belül, 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, míg egy 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 semmilyen metrika nem szabályozza 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 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 távoli asztal figyelésének kulcsfontosságú mutatói.
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.
Egy folyamatos CPU-csúcs például összefügghet a reggeli bejelentkezési rohammal, a párhuzamos munkamenetek megnövekedett számával, 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 kezelheti ezeket a kérdéseket. 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ákat 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 figyelembe é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 terjedelmé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 felhasználók több szerveren 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 lecsatlakoznak. | A szerver elérhetősége, 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 monitorozás 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 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álaszoljon: 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 most?
A valós idejű megfigyelést az adminisztrátorok felhaszná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ó létfontossá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 monitoringot 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.
Figyelési küszöbök 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ára utalhat.
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ép egy adott küszöböt, az értékes információ a kapacitás tervezéséhez.
A történelmi alapvonalak gyakran fontosabbak, mint az egyes küszöbértékek, mert megmutatják, mi számít normálisnak 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 támogatott Windows Server verziókon. Az Eseménynéző az operációs rendszerrel és az RDS-sel kapcsolatos eseményeket mutatja be, 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 vagy a helyzet korábbi események szempontjából történő áttekintésének szükségessége 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 a párhuzamossá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 összekapcsoljuk, 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ésének képessége 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 Távoli Asztal Figyelés 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 az információt.
A párhuzamos felhasználók elemzésével és összehasonlításával a CPU-val, memóriával, lemezzel és hálózati kihasználtsággal 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 gazda 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ási és infrastruktúra igé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ózati megfigyelés
- 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és és az 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 pontosan, mit értenek a szolgáltatók 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, egy központosított megfigyelési környezetbe hozzuk a szerver- és felhasználói tevékenységet. 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 csatlakoztatott 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 alapvonalak megállapítását és a kapacitásigények előrejelzését több szerver között anélkül, hogy teljes felhasználói munkamenet rögzítést vezetnének be.
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 gazdagépen tapasztalható 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.
)
)
)
