Въведение
Отдалечените работни среди генерират няколко слоя оперативни данни, от използването на CPU и памет до свързани потребители, едновременни сесии и търсене на приложения. Предизвикателството е да се реши кои сигнали са важни и как те се свързват. Тази статия обяснява какво проследява софтуерът за мониторинг на отдалечен работен плот, как видимостта на сесиите се различава от мониторинга на сървъри и как ИТ екипите могат да използват данни в реално време и исторически данни, за да диагностицират проблеми с производителността.
Какво всъщност наблюдава софтуерът за мониторинг на отдалечен работен плот?
Мониторингът на отдалечен работен плот обхваща редица концепции. Някои инструменти се фокусират върху ресурсите на сървъра, докато други инвентаризират връзките, използвайки протокола за отдалечен работен плот (RDP) или услугите за отдалечен работен плот (RDS). Инструментите, които приемат подход, насочен към сигурността, могат да одитират и записват потребителската активност.
За ИТ е логично да разделим тези инструменти на 5 категории:
| Слой за наблюдение | Какво отговаря | Типична информация |
|---|---|---|
| Инфраструктура | Здрав ли е хостът? | ЦПУ, памет, диск, честотна лента, наличност |
| Свързване | Кой се свърза и кога? | Потребител, време за вход, статус на връзката |
| Сесия | Какво се случва по време на отдалечени сесии? | Свързани потребители, едновременни сесии, продължителност, състояние на сесията |
| Потребителски опит | Отзивчива ли е отдалечената сесия? | Забавяне на входа, латентност, забавяния при влизане, отзивчивост на приложението |
| Дейност | Какви приложения или действия са включени? | Използване на приложението, процеси, одитни събития или записи на сесии |
Тези са свързани, но не непременно взаимозаменяеми, тъй като едно може да отчете наситеност на CPU, но да не разкрие коя сесия е била първата засегната, докато платформа за одит може да идентифицира кой се е свързал, но да не обясни защо производителността е влошена.
Софтуерът за запис на сесии прави тази стъпка по-далеч, като събира подробни доказателства за това, което се е случило в контекста на отдалечената среда, въвеждайки допълнителни съображения за сигурност, поверителност, задържане и съхранение.
Първото предизвикателство при сравняването на софтуер за мониторинг на отдалечен работен плот е да се определи видимостта, която ИТ всъщност изисква.
Защо видимостта на ниво сесия е различна от мониторинга на сървъра?
Традиционен наблюдение на сървъра инструменти питат дали машината работи добре. Висока ли е употребата на CPU? Ниска ли е паметта? Увеличава ли се употребата на диска? Онлайн ли е сървърът?
Тези метрики все още са актуални в сценарий на хостинг с RDS, но има още един слой, който трябва да се вземе предвид. Споделената RDS инфраструктура означава, че на ниво хост, CPU, памет, съхранение и мрежова капацитет са разпределени между множество потребители и приложения.
На ниво сесия, приложенията и процесите на всеки потребител имат уникални изисквания. RD Session Host може да бъде общо здрав, докато приложенията на един потребител замръзват, или една бавна сесия не означава, че целият сървър е на капацитет.
Разликата е значима за целите на отстраняване на проблеми. Ако десет потребители на същия сървър започнат да забавят работата си едновременно, има смисъл първо да се разгледат споделените ресурси на сървъра. Ако само един потребител изпитва проблеми, вероятността проблемът да е изолиран до тази сесия, нейните приложения и връзка е по-голяма.
Инструментите за мониторинг на отдалечен работен плот са най-ефективни, когато дават възможност на администраторите да превключват между тези перспективи и да правят връзки между общото състояние на сървъра и състоянието на отделните потребителски сесии.
Какви са най-важните метрики за отдалечен работен плот?
Няма единен показател, който да управлява здравето на среда за отдалечен работен плот. Администраторите изискват достатъчен контекст, за да интерпретират текущото натоварване, потреблението на ресурси и потребителското изживяване.
Колко потребители и сесии са активни?
Броят на сесиите предоставя основата за този разговор.
Релевантните данни включват свързани потребители, активни и прекъснати сесии, паралелни сесии разпределение между сървъри, пикови периоди и историческа конкурентност.
Тенденциите в конкуренцията имат предимство пред броя на служителите при оценка на производителността на система за отдалечен работен плот, тъй като капацитетът обикновено се определя от едновременната натовареност, а не от броя на регистрираните потребители. Машина, която обслужва 200 случайни потребители, може да бъде значително по-натоварена от едновременен брой сесии от 40 потребители, работещи с приложения с висока производителност.
Стойността на метриките за конкурентност, допълнени от статистиките за инфраструктурата, е да се установи дали има корелация между увеличението на свързаните потребители и растежа на потреблението на ресурси.
Държат ли ресурсите на сървъра в крак с търсенето на сесии?
CPU, памет, дискова активност и налично хранилище все още са основните метрики за мониторинг на отдалечен работен плот.
Интересният въпрос не е дали CPU е достигнал определен процент, а кога е бил под натиск и какво друго се е случвало в същото време.
Постоянно увеличение на CPU, например, може да корелира с сутрешния наплив при влизане, увеличен брой на едновременни сесии, планиран процес или интензивна употреба на конкретно бизнес приложение.
Връзката между двете обикновено е по-важна от стойността на използването.
Кои приложения и процеси генерират натоварването?
Видимостта на приложението допринася за допълнителен контекст.
Разбирането на приложенията, които се използват, когато търсенето нараства и кои процеси консумират най-много ресурси, позволява на администраторите да свързват потребителската активност с поведението на инфраструктурата.
Мониторингът на приложенията може да отговори на тези видове въпроси. Появява ли се проблем с производителността, когато конкретно приложение се използва интензивно? Има ли хостове на сесии, които изпълняват по-интензивен набор от приложения? Поддържат ли се или са лицензирани приложения, които рядко се използват?
Тази информация има стойност не само за отстраняване на проблеми, но и за общо управление на инфраструктурата и софтуера.
Допринася ли мрежовото или потребителското изживяване за проблема?
Сесиите на отдалечен работен плот са интерактивни по своята същност, което прави проблемите с мрежата или отзивчивостта веднага видими за крайните потребители.
Необходимостта от честотна лента трябва да се оценява в съчетание с други метрики за производителността на сървъра, тъй като сървърът може да има свободен капацитет на CPU и памет, докато връзките са забавени от тесен проход на друго място в комуникационната верига. Разбирането RDP производителност в мрежи с висока латентност може да помогне за разграничаване на проблемите с отзивчивостта на мрежата от ограниченията на ресурсите от страна на хоста.
Някои RDS средища могат да предложат повече информация за опита на крайния потребител в сравнение с други. Microsoft Performance Monitor, например, разполага с броячи за забавяне на потребителския вход, които могат да идентифицират забавяния на ниво сесия и процес. Microsoft документира функцията като метод за корелиране на номера на сесии, използване на CPU и отзивчивост на RD Session Host сървъри.
Не всички инструменти за мониторинг на отдалечен работен плот включват същите метрики за латентност или забавяне на входа. ИТ администраторите трябва да проверят какво всъщност предлага доставчикът по отношение на информация за потребителското изживяване, вместо да предполагат, че тя ще бъде налична.
Как мониторингът на Remote Desktop може да помогне на вашия екип, когато трябва да отстраните проблеми с бавни сесии?
Стойността на мониторинга на отдалечен работен плот най-добре се вижда, когато администраторите вземат множество сигнали и ги корелират.
Когато потребител посочи, че RDP е бавен, той описва ефекта, а не причината. Вашият първи приоритет е да разберете обхвата на проблема.
Има ли един потребител, който има проблеми? Има ли няколко потребители, които са на същия хост? Има ли потребители на множество сървъри с един и същ проблем?
С определен обхват на проблема, вашите наблюдателни прозрения могат да помогнат за фокусиране на търсенето ви:
| Симптом | Полезни проверки |
|---|---|
| Един потребител е бавен | Състояние на сесията, приложения, процеси, условия на свързване |
| Повечето потребители на един сървър са бавни | ЦПУ, памет, дисково I/O, използване на процеси, едновременни сесии |
| Потребителите на няколко сървъра са бавни | Споделени зависимости от мрежа или инфраструктура |
| Производителността намалява по едно и също време всеки ден | Конкуренция, планирани задачи, пикове на приложенията |
| Потребителите често се изключват. | Наличност на сървъра, мрежови условия, събития на услугата и свързването |
| Едно приложение постоянно работи зле | Използване на приложението, свързани процеси и потребление на ресурси |
Целта е корелация. Върховете на CPU означават повече в контекста на увеличаваща се конкурентност. Високото използване на пропускателна способност е по-забележително в лицето на множество оплаквания от потребители. Повтарящият се проблем с производителността е по-лесен за идентифициране, когато знаете, че същото приложение или натоварване се случва всеки път.
Наблюдението не винаги идентифицира основната причина, но улавя оперативния контекст, необходим на администраторите, за да стеснят обхвата на възможните заподозрени.
Отстраняването на проблеми на базата на паметта след факта не е същото като инспектирането на средата по време на инцидента.
Наблюдение в реално време, известия и исторически отчети: защо са важни всички те?
Наблюдението е полезно, когато ви позволява да отговорите на три различни оперативни въпроса: какво се случва в момента, кога ИТ трябва да предприеме действия и какво се е случило преди това?
Какво се случва в момента?
Наблюдението в реално време може да бъде използвано от администратори за проверка на текущото представяне на сървъра, регистрираните потребители, процесите на приложенията и мрежовата активност.
Тази информация може да се окаже жизненоважна по време на инцидент, тъй като позволява на администратора да установи дали все още има натиск върху ресурсите или се случва необичайно натоварване.
Стойността в реално време предоставя текущи данни, но това е всичко. Метриката е само информативна в момента. Нещо, което изглежда нормално сега, може да е било аномално, когато потребителят е изпитвал проблема.
Кога нещо изисква внимание?
Уведомленията преобразуват мониторинга от пасивно събиране на данни в проактивен и оперативен процес.
Администраторите определят какво заслужава внимание: продължителна употреба на процесора, натиск върху паметта, активност на диска, прекомерен брой активни потребители или време на неработоспособност на сървъра.
Прагове за наблюдение все още трябва да се прилага с общо разбиране; кратък пик в активността на CPU е за очакване, но повторното натоварване по време на пиковите сесии може да показва възникващ проблем с капацитета.
Какво се случи преди инцидента?
Историческите отчети разкриват модели, които живите метрики не могат. Microsoft препоръчва да се използва Събиране на данни от производителността да записвате производителността на броячи с течение на времето, когато разследвате интермитентни проблеми с производителността на Windows Server.
Кажете, че CPU достига 90 процента за пет минути. Ако това е изолирано събитие в иначе известен партиден процес, може да не показва проблем. Но ако CPU достига 90 процента всеки работен ден около същото време, когато конкурентността преминава даден праг, това е ценна информация за планиране на капацитета.
Историческите базови линии често са по-важни от индивидуалните прагове, защото показват какво е нормално за даден сървър, комбинация от приложения и потребителска популация.
В кои случаи родните инструменти за мониторинг на Windows са достатъчни?
Windows предоставя доста мощен инструментариум за отстраняване на проблеми.
Диспечерът на задачите и Мониторът на ресурсите показват текущото използване на ресурсите. Мониторът на производителността може да събира производствени броячи на Windows, включително забавянето на потребителския вход на ниво сесия и процес в поддържаните версии на Windows Server. Прегледът на събитията представя събития, свързани с операционната система и RDS, докато PowerShell може да се използва за запитвания и автоматизиране на много административни задачи.
За отстраняване на проблеми с един сървър или разследване на конкретен проблем, тези инструменти могат да се окажат достатъчни за опитен администратор.
Въпреки това, необходимостта от наблюдение на множество сървъри или преглед на ситуацията от перспективата на предишен инцидент може да изисква информацията да бъде извлечена от множество източници.
Централизираното наблюдение е полезно в ситуации, в които ИТ трябва да наблюдава повече от един хост чрез едно конзолно приложение, да запазва историческа информация за по-късна употреба, да сравнява системи и времеви рамки, да докладва за активността на потребителите и съвместимостта или да настройва известия.
Стойността на такъв подход не е непременно в метриките, които Windows не предоставя.
Става въпрос по-скоро за способността да се консолидира, съхранява и корелира тази информация, за да стане по-изпълнима за администраторите.
Означава ли това, че записвате потребителите, ако използвате мониторинг на сесии за отдалечен работен плот?
Не. Условията често се използват взаимозаменяемо, но мониторингът на сесии и записването на сесии имат значително различен обхват и възможности.
Докато мониторингът на сесии за отдалечен работен плот може да наблюдава само свързани потребители, едновременни сесии, използване на ресурси, история на сесиите или използване на приложения, записването на сесии би уловило много по-подробен набор от данни за дейностите в отдалечената сесия в зависимост от продукта, като съдържанието на екрана, дейностите на приложенията, дейностите в клипборда или други събития.
Записването на сесии може да има смисъл за специфични сценарии с привилегирован достъп, достъп от трети страни, одит или сигурност, но поставя допълнителни въпроси относно запазването, достъпа, съхранението и поверителността.
За повечето ежедневни операции с отдалечен работен плот, способността да се записват всички детайли на сесията е ненужна и нежелана от ИТ екипа, тъй като те се нуждаят само от достатъчно информация за сесията за наблюдения и анализ на производителността.
Как можете да подобрите планирането на капацитета, като използвате мониторинг на Remote Desktop?
Когато става въпрос за инфраструктура за отдалечен работен плот, плътността на натоварването е важен фактор.
Броят на конфигурираните акаунти казва малко за броя на simultanните потребители, приложенията, които използват, и тяхната интензивност.
Историческото наблюдение прави тази информация достъпна.
Чрез анализ на едновременните потребители и сравняването им с използването на CPU, памет, диск и мрежа, ИТ администраторите получават приложима информация за своята среда. Те виждат кога натоварванията започват да влияят на инфраструктурата, кои работни натоварвания са отговорни и дали тенденцията нараства.
Тази информация може да се използва за оправдаване на действия като балансиране на натоварването между хостовете, добавяне на повече сървъри, добавяне на повече ресурси към съществуващите сървъри, планиране на тежки приложения или разследване на приложения, които консумират непропорционално голямо количество ресурси.
Този подход е много по-точен от обща препоръка, основана на потребители на сървър. Microsoft’s Насоки за размер на хост сесии за отдалечен работен плот по подобен начин препоръчва оценка на типа натоварване, плътността на потребителите и измерванията на потребителското изживяване, вместо да се разчита на една единствена обща стойност на капацитета. Две компании с еднаква потребителска база могат да имат значително различни изисквания към приложенията и инфраструктурата.
Какъв тип изисквания трябва да търсите, когато търсите софтуер за мониторинг на отдалечен работен плот?
Най-добрият софтуер за мониторинг на отдалечени работни станции не е непременно продуктът, който събира най-много данни. Това е този, който предоставя необходимото ниво на видимост за управляваната среда.
За повечето ИТ операции екипи, ключовите изисквания са ясни:
- с централизирана видимост на множество сървъри
- информация за текущите потребители и паралелни сесии
- Наблюдение на CPU, памет, диск и мрежа
- видимост на приложенията и процесите
- исторически отчети и анализ на тенденции
- конфигурируеми известия
- практически възможности за докладване и експортиране
Платформата също така трябва да улесни корелацията. Броят на сесиите става по-ценен, когато администраторите могат да ги сравняват с натоварването на сървъра. Използването на приложенията става по-полезно, когато може да се разглежда с течение на времето.
Разходите за внедряване и администриране също имат значение. Платформа за мониторинг, предназначена да опрости отдалечената инфраструктура, не трябва да въвежда непропорционална сложност на инфраструктурата или управлението сама по себе си.
Накрая, проверете точно какво имат предвид доставчиците с термини като мониторинг на сесии, мониторинг на потребители и мониторинг на отдалечен работен плот. Една платформа може да означава отчет за свързани потребители, друга може да предоставя метрики за отзивчивост на RDP, докато трета може да предлага пълно записване на екрана.
Терминологията може да звучи подобно. Видимостта, която се предоставя, може да бъде много различна.
Как TSplus може да опрости мониторинга на отдалечен работен плот?
За ИТ екипи, управляващи инфраструктурата за отдалечен работен плот на Windows, ние предоставяме активността на сървъра и потребителите в централизирана среда за мониторинг. Администраторите могат да следят използването на CPU, памет, диск и честотна лента, докато също така проследяват свързаните потребители, паралелните сесии и активността на приложенията, което им помага да свържат производителността на инфраструктурата с действителното търсене на отдалечен работен плот.
TSplus Сървърно наблюдение също така предоставя исторически отчети и конфигурируеми известия, така че администраторите да могат да идентифицират повтарящи се модели на натоварване, вместо да разчитат само на текущи метрики. Това улеснява разследването на проблеми с производителността, установяването на практични бази и предвиждането на изискванията за капацитет на множество сървъри, без да се въвежда пълно записване на сесиите на потребителите.
Заключение
Ефективното наблюдение на отдалечен работен плот е свързано с корелация, а не с събиране на най-голямото възможно количество метрики. Производителността на сървъра, активността на сесиите, търсенето на приложения и условията в мрежата стават по-полезни, когато администраторите могат да ги разглеждат заедно.
Тази комбинирана гледна точка помага на ИТ да различава изолирани проблеми на потребителите от задръствания в хост средата, да разбира повтарящи се модели на производителност и да взема по-добри решения за капацитет, докато средите за отдалечен работен плот растат.