)
)
Introductie
Remote desktopomgevingen genereren verschillende lagen operationele gegevens, van CPU- en geheugengebruik tot verbonden gebruikers, gelijktijdige sessies en applicatievraag. De uitdaging is om te beslissen welke signalen belangrijk zijn en hoe ze zich verhouden. Dit artikel legt uit wat remote desktop monitoringsoftware bijhoudt, hoe sessiezicht verschilt van servermonitoring, en hoe IT-teams realtime en historische gegevens kunnen gebruiken om prestatieproblemen te diagnosticeren.
Wat monitort Remote Desktop Monitoring Software eigenlijk?
Remote desktop monitoring omvat een aantal concepten. Sommige tools richten zich op server-side bronnen, terwijl andere verbindingen in kaart brengen met behulp van het Remote Desktop Protocol (RDP) of Remote Desktop Services (RDS). Tools die een beveiligingsgerichte aanpak hanteren, kunnen gebruikersactiviteit auditen en registreren.
Voor IT is het logisch om deze tools in 5 categorieën op te splitsen:
| Monitoringlaag | Wat het beantwoordt | Typische informatie |
|---|---|---|
| Infrastructuur | Is de host gezond? | CPU, geheugen, schijf, bandbreedte, beschikbaarheid |
| Verbinding | Wie heeft verbinding gemaakt en wanneer? | Gebruiker, inlogtijd, verbindingsstatus |
| Sessie | Wat gebeurt er tijdens externe sessies? | Verbonden gebruikers, gelijktijdige sessies, duur, sessietoestand |
| Gebruikerservaring | Is de externe sessie responsief? | Invoervertraging, latentie, aanmeldvertragingen, applicatieresponsiviteit |
| Activiteit | Welke applicaties of acties zijn betrokken? | Toepassingsgebruik, processen, auditgebeurtenissen of sessierecords |
Deze zijn gerelateerd maar niet noodzakelijkerwijs uitwisselbaar, aangezien iemand een CPU-saturatie kan rapporteren maar niet kan onthullen welke sessie als eerste werd beïnvloed, terwijl een auditplatform kan identificeren wie verbinding heeft gemaakt maar niet kan uitleggen waarom de prestaties verslechterden.
Sessie-opnamesoftware gaat een stap verder door gedetailleerd bewijs te verzamelen van wat er is gebeurd binnen de context van de externe omgeving, en introduceert verdere overwegingen op het gebied van beveiliging, privacy en het bewaren en opslaan van gegevens.
De eerste uitdaging bij het vergelijken van software voor het monitoren van externe desktops is om de zichtbaarheid te identificeren die IT daadwerkelijk nodig heeft.
Waarom sessieniveau zichtbaarheid anders is dan servermonitoring?
Traditioneel server monitoring tools vragen of de machine het goed doet. Is het CPU-gebruik hoog? Is het geheugen laag? Stijgt het schijfgebruik? Is de server online?
Deze statistieken zijn nog steeds relevant in een RDS-hostingscenario, maar er is een andere laag om te overwegen. Gedeelde RDS-infrastructuur betekent dat op het hostniveau CPU, geheugen, opslag en netwerkcapaciteit worden verdeeld tussen meerdere gebruikers en applicaties.
Op het sessieniveau hebben de applicaties en processen van elke gebruiker unieke eisen. Een RD-sessiehost kan over het algemeen gezond zijn terwijl de applicaties van één gebruiker vastlopen, of een trage sessie betekent niet dat de hele server vol is.
Het verschil is betekenisvol voor het oplossen van problemen. Als tien gebruikers op dezelfde server tegelijkertijd traag worden, is het logisch om eerst naar de gedeelde bronnen van de server te kijken. Als slechts één gebruiker problemen ondervindt, is het probleem waarschijnlijk meer geïsoleerd tot die sessie, de toepassingen en de verbinding.
Remote desktop monitoring tools zijn het meest effectief wanneer ze beheerders in staat stellen om tussen deze perspectieven te schakelen en verbindingen te leggen tussen de algehele gezondheid van de server en de staat van individuele gebruikerssessies.
Wat zijn de belangrijkste metrics voor Remote Desktop?
Geen enkele maatstaf bepaalt de gezondheid van een remote desktop-omgeving. Beheerders hebben voldoende context nodig om de huidige werklast, het resourceverbruik en de gebruikerservaring te interpreteren.
Hoeveel gebruikers en sessies zijn actief?
Sessieaantallen vormen de basis voor dit gesprek.
Relevante gegevenspunten zijn onder andere verbonden gebruikers, actieve en verbroken sessies, concurrentiesessie tellingen , distributie over servers, piekperioden en historische gelijktijdigheid.
Concurrentietrends hebben voorrang boven het aantal medewerkers bij het evalueren van de prestaties van een remote desktop-systeem, aangezien de capaciteit doorgaans wordt gedefinieerd door de gelijktijdige werklast, in plaats van het aantal geregistreerde gebruikers. Een machine die 200 casual gebruikers bedient, kan aanzienlijk meer belast zijn dan een gelijktijdige sessie van 40 gebruikers die high-performance applicaties draaien.
De waarde van gelijktijdigheidsstatistieken, aangevuld met infrastructuurstatistieken, is om vast te stellen of er een correlatie is tussen de toename van het aantal verbonden gebruikers en de groei van het resourceverbruik.
Houden serverbronnen gelijke tred met de vraag naar sessies?
CPU, geheugen, schijfactiviteit en beschikbare opslag zijn nog steeds de belangrijkste metrics voor het monitoren van een externe desktop.
De interessante vraag is niet of de CPU een bepaald percentage bereikte, maar wanneer deze onder druk stond en wat er tegelijkertijd nog meer gebeurde.
Een constante CPU-piek kan bijvoorbeeld samenhangen met de ochtend inlogpiek, een verhoogd aantal gelijktijdige sessies, een geplande proces of een intensief gebruik van een bepaalde zakelijke applicatie.
De verbinding tussen de twee is meestal belangrijker dan de gebruikswaarde.
Welke applicaties en processen drijven de werklast aan?
Toepassingszichtbaarheid draagt bij aan extra context.
Het begrijpen van de toepassingen die worden gebruikt, wanneer de vraag toeneemt en welke processen de meeste middelen verbruiken, stelt beheerders in staat om gebruikersactiviteit te koppelen aan het gedrag van de infrastructuur.
Toepassingsmonitoring kan deze soorten vragen aanpakken. Doet zich een prestatieprobleem voor wanneer een specifieke toepassing intensief wordt gebruikt? Zijn er sessiehosts die een intensievere set toepassingen draaien? Worden er toepassingen onderhouden of gelicentieerd die zelden worden gebruikt?
Deze informatie heeft waarde, niet alleen voor probleemoplossing, maar ook voor algemene infrastructuur en softwarebeheer.
Draagt het netwerk of de gebruikerservaring bij aan het probleem?
Remote desktop sessies zijn van nature interactief, waardoor netwerk- of responsiviteitsproblemen onmiddellijk duidelijk zijn voor eindgebruikers.
Bandbreedte moet worden geëvalueerd in combinatie met andere prestatiemetingen van de server, aangezien een server mogelijk over extra CPU- en geheugencapaciteit beschikt terwijl verbindingen worden vertraagd door een knelpunt elders in de communicatielijn. Begrijpen RDP-prestaties op netwerken met hoge latentie kan helpen om netwerkresponsiviteitsproblemen te onderscheiden van beperkingen van bronnen aan de hostzijde.
Sommige RDS-omgevingen kunnen meer inzichten in de eindgebruikerservaring bieden dan andere. Microsoft Performance Monitor heeft bijvoorbeeld User Input Delay-tellers die vertragingen op sessie- en procesniveaus kunnen identificeren. Microsoft documenteert de functie als een methode om sessienummers, CPU-gebruik en responsiviteit op RD Session Host-servers te correleren.
Niet alle tools voor het monitoren van externe desktops bevatten dezelfde latentie- of invoervertragingseisen. IT-beheerders moeten dubbel controleren wat een leverancier daadwerkelijk biedt op het gebied van informatie over de gebruikerservaring in plaats van aan te nemen dat dit aanwezig zal zijn.
Hoe kan Server Monitoring uw team helpen bij het oplossen van trage sessies?
De waarde van het monitoren van externe desktops is het beste zichtbaar wanneer beheerders meerdere signalen verzamelen en deze met elkaar in verband brengen.
Wanneer een gebruiker aangeeft dat RDP traag is, beschrijft hij het effect, niet de oorzaak. Uw eerste prioriteit is om de reikwijdte van het probleem te begrijpen.
Heeft één gebruiker problemen? Zijn er meerdere gebruikers die op dezelfde host zitten? Zijn er gebruikers op meerdere servers met hetzelfde probleem?
Met de reikwijdte van het probleem gedefinieerd, kunnen uw monitoringinzichten helpen uw zoektocht te richten:
| Symptoom | Nuttige controles |
|---|---|
| Een gebruiker is traag | Sessie status, applicaties, processen, verbindingsvoorwaarden |
| De meeste gebruikers op één server zijn traag | CPU, geheugen, schijf I/O, procesgebruik, gelijktijdige sessies |
| Gebruikers op verschillende servers zijn traag | Gedeelde netwerk- of infrastructuurafhankelijkheden |
| De prestaties verslechteren dagelijks op hetzelfde tijdstip. | Gelijktijdigheid, geplande taken, applicatiepieken |
| Gebruikers worden vaak losgekoppeld | Serverbeschikbaarheid, netwerkomstandigheden, service- en verbindingsgebeurtenissen |
| Een applicatie presteert herhaaldelijk slecht | Toepassingsgebruik, gerelateerde processen en hulpbronnenverbruik |
Het doel is correlatie. CPU-pieken betekenen meer in de context van toenemende gelijktijdigheid. Hoge bandbreedtebenutting is opmerkelijker in het licht van meerdere gebruikersklachten. Een terugkerend prestatieprobleem is gemakkelijker te identificeren wanneer je weet dat dezelfde applicatie of werklast elke keer voorkomt.
Monitoring identificeert niet altijd de onderliggende oorzaak, maar het legt wel de operationele context vast die nodig is voor beheerders om het aantal mogelijke verdachten te verkleinen.
Probleemoplossing op basis van geheugen achteraf is niet hetzelfde als het inspecteren van de omgeving op het moment van het incident.
Realtime monitoring, waarschuwingen en historische rapporten: waarom zijn ze allemaal belangrijk?
Monitoring blijkt voordelig wanneer het je in staat stelt om drie verschillende operationele vragen te beantwoorden: wat gebeurt er momenteel, wanneer moet IT actie ondernemen, en wat is er eerder gebeurd?
Wat gebeurt er op dit moment?
Realtime monitoring kan door beheerders worden gebruikt om de huidige serverprestaties, ingelogde gebruikers, applicatieprocessen en netwerkactiviteit te onderzoeken.
Deze informatie kan van vitaal belang zijn tijdens een incident, omdat het de beheerder in staat stelt vast te stellen of er nog druk op de middelen staat of dat er een ongebruikelijke belasting plaatsvindt.
De realtime waarde biedt actuele gegevens, maar dat is het. De metriek is op dit moment alleen informatief. Iets dat nu normaal lijkt, kan abnormaal zijn geweest toen de gebruiker het probleem ondervond.
Wanneer vereist iets aandacht?
Alerts transform monitoring van passieve dataverzameling in een proactief en operationeel proces.
Beheerders geven aan wat aandacht verdient: aanhoudend processorgebruik, geheugendruk, schijfactiviteit, overmatig aantal actieve gebruikers of serveruitval.
Monitoringdrempels moet nog met gezond verstand worden toegepast; een korte piek in CPU-activiteit is te verwachten, maar terugkerende druk tijdens pieksessies kan wijzen op een opkomend capaciteitsprobleem.
Wat is er gebeurd vóór het voorval?
Historische rapporten onthullen patronen die live statistieken niet kunnen. Microsoft raadt aan om gebruik te maken van Gegevensverzameling van de Prestatiemonitor om prestatiemetingen in de tijd vast te leggen bij het onderzoeken van intermitterende prestatieproblemen van Windows Server.
Zeg dat de CPU 90 procent bereikt gedurende vijf minuten. Als dat een geïsoleerd voorval is in een anderszins bekende batchverwerking, geeft het mogelijk geen probleem aan. Maar als de CPU elke werkdag rond dezelfde tijd 90 procent bereikt wanneer de gelijktijdigheid een bepaalde drempel overschrijdt, is dat een waardevol stuk informatie voor capaciteitsplanning.
Historische basislijnen zijn vaak belangrijker dan individuele drempels, omdat ze je laten zien wat normaal is voor een bepaalde server, applicatiemix en gebruikerspopulatie.
In welke gevallen zijn native Windows-monitoringtools voldoende?
Windows biedt al een behoorlijk robuuste toolkit voor probleemoplossing.
De Taakbeheerder en Resource Monitor tonen het huidige gebruik van middelen. Prestatiemonitor kan Windows-prestatiecounters verzamelen, inclusief de vertraging van gebruikersinvoer op sessie- en procesniveau op ondersteunde versies van Windows Server. De Logboeken tonen gebeurtenissen met betrekking tot het besturingssysteem en RDS, terwijl PowerShell kan worden gebruikt om veel beheertaken te query'en en te automatiseren.
Voor probleemoplossing op een enkele server of onderzoek naar een specifiek probleem, kunnen deze tools voldoende blijken te zijn voor een ervaren beheerder.
Echter, de noodzaak om meerdere servers te monitoren of de situatie vanuit het perspectief van een eerdere gebeurtenis te bekijken, kan vereisen dat de informatie uit meerdere bronnen wordt gehaald.
Gecentraliseerd toezicht is nuttig in situaties waarin IT meer dan één host via één console moet monitoren, historische informatie voor later gebruik moet opslaan, systemen en tijdsbestekken moet vergelijken, rapport moet uitbrengen over gebruikersactiviteit en gelijktijdigheid, of waarschuwingen moet instellen.
De waarde van een dergelijke benadering ligt niet noodzakelijkerwijs in de statistieken die Windows niet biedt.
Het gaat eerder om de mogelijkheid om deze informatie te consolideren, op te slaan en te correleren om het actiegerichter te maken voor beheerders.
Betekent dit dat je gebruikers opneemt als je Remote Desktop-sessie monitoring gebruikt?
Nee. De termen worden vaak door elkaar gebruikt, maar sessiemonitoring en sessieregistratie hebben aanzienlijk verschillende reikwijdte en mogelijkheden.
Hoewel het monitoren van externe desktop-sessies alleen verbonden gebruikers, gelijktijdige sessies, hulpbronnengebruik, sessiegeschiedenis of applicatiegebruik kan observeren, zou sessieregistratie een veel gedetailleerdere set gegevens vastleggen over de activiteiten binnen de externe sessie, afhankelijk van het product, zoals de inhoud van het scherm, applicatieactiviteiten, klembordactiviteiten of andere gebeurtenissen.
Opnamesessies kunnen zinvol zijn voor specifieke scenario's met betrekking tot privileged-access, third-party-access, auditing of beveiliging, maar het roept aanvullende vragen op over retentie, toegang, opslag en privacy.
Voor de meeste dagelijkse remote desktop-activiteiten is de mogelijkheid om alle details van een sessie vast te leggen onnodig en ongewenst door het IT-team, aangezien ze alleen voldoende informatie over de sessie nodig hebben voor prestatieobservaties en analyse doeleinden.
Hoe kunt u uw capaciteitsplanning verbeteren door gebruik te maken van Remote Desktop Monitoring?
Als het gaat om remote desktop-infrastructuur, is laaddichtheid een belangrijke overweging.
Het aantal geconfigureerde accounts zegt weinig over het aantal gelijktijdige gebruikers, de applicaties die ze draaien en hun intensiteit.
Historische monitoring maakt die informatie beschikbaar.
Door gelijktijdige gebruikers te analyseren en deze te vergelijken met CPU-, geheugen-, schijf- en netwerkutilisaties, krijgen IT-beheerders bruikbare inzichten in hun omgeving. Ze zien wanneer de belasting de infrastructuur begint te beïnvloeden, welke werkbelastingen verantwoordelijk zijn en of de trend toeneemt.
Die informatie kan worden gebruikt om acties te rechtvaardigen, zoals het balanceren van de werklast tussen hosts, het toevoegen van meer servers, het toevoegen van meer middelen aan bestaande servers, het plannen van zware applicaties of het onderzoeken van applicaties die een onevenredig groot aantal middelen verbruiken.
Die aanpak is veel nauwkeuriger dan een algemene aanbeveling op basis van gebruikers per server. Microsofts Begeleiding voor het dimensioneren van Remote Desktop-sessieserver evenzo wordt aanbevolen om het type werklast, de gebruikersdichtheid en de gebruikerservaringmetingen te evalueren in plaats van te vertrouwen op een enkele generieke capaciteitswaarde. Twee bedrijven met dezelfde gebruikersbasis kunnen heel verschillende eisen stellen aan applicaties en infrastructuur.
Welke type vereisten moet u zoeken wanneer u een software voor het monitoren van Remote Desktop zoekt?
De beste software voor het monitoren van externe desktops is niet per se het product dat de meeste gegevens verzamelt. Het is degene die het niveau van zichtbaarheid biedt dat nodig is voor de beheerde omgeving.
Voor de meeste IT-operatieteams zijn de belangrijkste vereisten eenvoudig:
- c gecentraliseerde zichtbaarheid over meerdere servers
- huidige gebruikers en gelijktijdige-sessie informatie
- CPU-, geheugen-, schijf- en netwerkbewaking
- toepassing en proces zichtbaarheid
- historische rapporten en trendanalyse
- configureerbare waarschuwingen
- praktische rapportage- en exportopties
Het platform moet ook correlatie eenvoudig maken. Sessietellingen worden waardevoller wanneer beheerders ze kunnen vergelijken met de serverbelasting. Toepassingsgebruik wordt nuttiger wanneer het in de loop van de tijd kan worden onderzocht.
Implementatie- en beheerskosten zijn ook belangrijk. Een monitoringplatform dat bedoeld is om de externe infrastructuur te vereenvoudigen, mag geen onevenredige infrastructuur- of beheerscomplexiteit met zich meebrengen.
Controleer ten slotte precies wat leveranciers bedoelen met termen zoals sessiemonitoring, gebruikersmonitoring en remote desktop monitoring. Het ene platform kan rapportage van verbonden gebruikers betekenen, een ander kan RDP-responsiviteitseisen bieden, terwijl een ander mogelijk volledige schermopnames aanbiedt.
De terminologie kan vergelijkbaar klinken. De geleverde zichtbaarheid kan heel verschillend zijn.
Hoe kan TSplus het monitoren van Remote Desktop vereenvoudigen?
Voor IT-teams die de Windows-remote desktopinfrastructuur beheren, brengen we server- en gebruikersactiviteit in een gecentraliseerde monitoromgeving. Beheerders kunnen het CPU-, geheugen-, schijf- en bandbreedtegebruik volgen, terwijl ze ook verbonden gebruikers, gelijktijdige sessies en applicatieactiviteit bijhouden, wat hen helpt de prestaties van de infrastructuur te relateren aan de werkelijke vraag naar remote desktop.
TSplus Server Monitoring biedt ook historische rapportage en configureerbare waarschuwingen, zodat beheerders terugkerende werkbelastingpatronen kunnen identificeren in plaats van alleen op live statistieken te vertrouwen. Dit maakt het gemakkelijker om prestatieproblemen te onderzoeken, praktische basislijnen vast te stellen en capaciteitsvereisten over meerdere servers te anticiperen zonder volledige gebruikerssessie-opnames in te voeren.
Conclusie
Effectieve monitoring van externe desktops draait om correlatie, niet om het verzamelen van de grootste mogelijke set aan statistieken. Serverprestaties, sessieactiviteit, applicatievraag en netwerkcondities worden nuttiger wanneer beheerders ze samen kunnen onderzoeken.
Die gecombineerde weergave helpt IT om geïsoleerde gebruikersproblemen te onderscheiden van knelpunten op hostniveau, terugkerende prestatiepatronen te begrijpen en betere capaciteitsbeslissingen te nemen naarmate de omgevingen voor externe bureaubladen groeien.
)
)
)
