Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Виртуальный рабочий стол Azure использует службу журналов Azure Monitor для сбора, индексирования и хранения данных, созданных вашей средой. По этой причине модель ценообразования Azure Monitor основана на количестве данных, которые вводятся и обрабатываются (или "приняты") рабочей областью Log Analytics в гигабайтах в день. Стоимость рабочей области Log Analytics зависит не только от объема собранных данных, но и от выбранного плана оплаты Azure и времени хранения данных, формируемых вашей средой.
В этой статье описаны следующие аспекты, которые помогут вам понять, как работает ценообразование в Azure Monitor.
- Как заранее оценить затраты на прием данных и хранение перед включением этой функции
- Как измерять и контролировать прием и хранение, чтобы снизить затраты при использовании этой функции
Примечание.
Все размеры и цены, перечисленные в этой статье, являются лишь примерами для демонстрации того, как работает оценка. Более точную оценку на основе модели ценообразования Azure Monitor Log Analytics и региона Azure см. в статье Цены на Azure Monitor.
Оценка затрат на прием данных и хранение
Рекомендуется использовать предопределенный набор данных, записанных в качестве журналов в рабочей области Log Analytics. В следующем примере оценки мы рассмотрим оплачиваемые данные в конфигурации по умолчанию.
Стандартные наборы данных для Аналитики виртуальных рабочих столов Azure:
- Счетчики производительности из узлов сеансов
- Журналы событий Windows с узлов сеансов
- Виртуальный рабочий стол Azure диагностика из инфраструктуры службы
Затраты на прием и хранение данных зависят от размера среды, работоспособности и использования. Пример оценки, который мы будем использовать в этой статье для расчета ожидаемых диапазонов затрат, основан на работоспособных виртуальных машинах, работающих от легкого до энергопотребления, на основе наших рекомендаций по выбору размера виртуальных машин, чтобы вычислить диапазон ожидаемых затрат на прием данных и хранение.
Виртуальная машина с легким использованием, которую мы будем использовать в нашем примере, включает следующие компоненты:
- 4 виртуальных ЦП, 1 диск
- 16 сеансов в день
- Средняя продолжительность сеанса составляет 2 часа (120 минут)
- 100 процессов на сеанс
Виртуальная машина потребления энергии, которую мы будем использовать в нашем примере, включает следующие компоненты:
- 6 виртуальных ЦП, 1 диск
- 6 сеансов в день
- Средняя продолжительность сеанса 4 часа (240 минут)
- 200 процессов на сеанс
Оценка приема счетчика производительности
Счетчики производительности показывают, как работают системные ресурсы. Прием данных счетчика производительности зависит от размера и использования среды. В большинстве случаев счетчики производительности должны составлять от 80 до 99 % от приема данных для Аналитики Виртуальных рабочих столов Azure.
Прежде чем приступить к оценке, важно понимать, что каждый счетчик производительности отправляет данные с определенной частотой. Мы задаем частоту выборки по умолчанию в минуту (вы также можете изменить эту скорость в параметрах), но эта скорость будет применяться при различных коэффициентах умножения в зависимости от счетчика. На скорость влияют следующие факторы:
Для коэффициента на виртуальную машину каждый счетчик отправляет данные на виртуальную машину в вашей среде с частотой выборки по умолчанию в минуту во время работы виртуальной машины. Вы можете оценить количество записей, отправляемых этими счетчиками в день, умножив частоту выборки по умолчанию в минуту на количество виртуальных машин в вашей среде, а затем умножив это число на среднее время работы виртуальной машины в день.
Подводя итоги, выполните приведенные ниже действия.
Частота выборки по умолчанию в минуту × количество ядер ЦП в номере SKU виртуальной машины × количество виртуальных машин × среднее время работы виртуальной машины в день = количество записей, отправленных в день
Для коэффициента ЦП каждый счетчик отправляет по умолчанию частоту выборки в минуту на каждую виртуальную ЦП на каждой виртуальной машине в вашей среде во время работы виртуальной машины. Вы можете оценить количество записей, которые счетчики будут отправлять в день, умножив частоту выборки по умолчанию в минуту на количество ядер ЦП в номере SKU виртуальной машины, а затем умножив это число на количество минут, выполняемых виртуальной машиной, и количество виртуальных машин в вашей среде.
Подводя итоги, выполните приведенные ниже действия.
Частота выборки по умолчанию в минуту × количество ядер ЦП в номере SKU виртуальной машины × количество минут, в течение которых виртуальная машина выполняется × число виртуальных машин = количество записей, отправленных в день
Для коэффициента на диск каждый счетчик отправляет данные с частотой выборки по умолчанию для каждого диска на каждой виртуальной машине в вашей среде. Количество записей, отправляемых этими счетчиками в день, равно частоте выборки по умолчанию в минуту, умноженной на количество дисков в номере SKU виртуальной машины, умноженной на 60 минут в час и, наконец, умноженной на среднее время активности виртуальной машины.
Подводя итоги, выполните приведенные ниже действия.
Частота выборки по умолчанию в минуту × количество дисков в номере SKU виртуальной машины × 60 минут в час × количество виртуальных машин × среднее время работы виртуальной машины в день = количество записей, отправленных в день
Для коэффициента на сеанс каждый счетчик отправляет данные с частотой выборки по умолчанию для каждого сеанса в вашей среде во время подключения сеанса. Вы можете оценить количество записей, которые эти счетчики будут отправлять в день, умножив частоту выборки по умолчанию в минуту на среднее число сеансов в день и среднюю продолжительность сеанса.
Подводя итоги, выполните приведенные ниже действия.
Частота выборки по умолчанию в минуту × сеансов в день × средняя длительность сеанса = количество записей, отправленных в день
Для каждого фактора процесса каждый счетчик отправляет данные по умолчанию для каждого процесса в каждом сеансе в вашей среде. Вы можете оценить количество записей, которые эти счетчики будут отправлять в день, умножив частоту выборки по умолчанию в минуту на среднее количество сеансов в день, а затем умножив это на среднюю длительность сеанса и среднее количество процессов в сеансе.
Подводя итоги, выполните приведенные ниже действия.
Частота выборки по умолчанию в минуту × сеансов в день × средняя продолжительность сеанса × среднее число процессов в сеансе = количество записей, отправленных в день
В следующей таблице перечислены 20 счетчиков производительности, собираемых Аналитикой виртуальных рабочих столов Azure, и их тарифы по умолчанию.
| Имя счетчика | Частота выборки по умолчанию | Коэффициент частоты |
|---|---|---|
| Свободное место на логическом диске(C:)\% | 60 секунд | На диск |
| Логический диск(C:)\Средняя длина очереди диска | 30 секунд | На диск |
| Логический диск(C:)\Средн. Диск с/передача | 60 секунд | На диск |
| Логический диск(C:)\Текущая длина очереди диска | 30 секунд | На диск |
| Memory(*)\Available Mbytes | 30 секунд | На виртуальную машину |
| Память(*)\Ошибки страницы/с | 30 секунд | На виртуальную машину |
| Память(*)\Pages/с | 30 секунд | На виртуальную машину |
| Использование памяти(*)\% зафиксированных байтов | 30 секунд | На виртуальную машину |
| PhysicalDisk(*)\Средняя длина очереди диска | 30 секунд | На диск |
| PhysicalDisk(*)\Avg. Disk sec/Read | 30 секунд | На диск |
| PhysicalDisk(*)\Avg. Disk sec/Transfer | 30 секунд | На диск |
| PhysicalDisk(*)\Avg. Disk sec/Write | 30 секунд | На диск |
| Сведения о процессоре(_Total)\% времени процессора | 30 секунд | На ядро или ЦП |
| Службы терминалов(*)\Активные сеансы | 60 секунд | На виртуальную машину |
| Службы терминалов(*)\Неактивные сеансы | 60 секунд | На виртуальную машину |
| Службы терминалов(*)\Всего сеансов | 60 секунд | На виртуальную машину |
| Задержка ввода пользователя на процесс(*)\Максимальная задержка ввода | 30 секунд | За процесс |
| Задержка ввода пользователя на сеанс(*)\Максимальная задержка ввода | 30 секунд | За сеанс |
| RemoteFX Network(*)\Current TCP RTT | 30 секунд | На виртуальную машину |
| Сеть RemoteFX(*)\Текущая пропускная способность UDP | 30 секунд | На виртуальную машину |
Если мы оцениваем размер каждой записи в 200 байт, пример виртуальной машины с небольшой рабочей нагрузкой с частотой выборки по умолчанию будет отправлять примерно 90 мегабайт данных счетчика производительности в день на виртуальную машину. Между тем, пример виртуальной машины с рабочей нагрузкой питания будет отправлять примерно 130 мегабайт данных счетчика производительности в день на одну виртуальную машину. Однако размер записей и использование среды могут отличаться, поэтому мегабайты в день развертывания могут отличаться.
Дополнительные сведения о счетчиках производительности задержки ввода см. в статье Счетчики производительности задержки ввода пользователя.
Оценка приема журнала событий Windows
Журналы событий Windows — это источники данных, собираемые агентом Azure Monitor или агентом Log Analytics на виртуальных машинах Windows. Вы можете собирать события из стандартных журналов, таких как Система и Приложение, а также из пользовательских журналов, созданных приложениями, которые необходимо отслеживать.
Ниже приведены события Windows по умолчанию для Аналитики виртуальных рабочих столов Azure:
- Приложение
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Администратор
- Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
- Системные
- Microsoft-FSLogix-Apps/Operational
- Microsoft-FSLogix-Apps/Администратор
События Windows отправляют события всякий раз, когда среда соответствует условиям события. Компьютеры в работоспособном состоянии будут отправлять меньше событий, чем компьютеры в неработоспособных состояниях. Так как количество событий непредсказуемо, для этой оценки мы используем диапазон от 1000 до 10 000 событий на виртуальную машину в день на основе примеров из работоспособных сред. Например, если мы оцениваем размер каждой записи события в этом примере в 1500 байт, это будет примерно от 2 до 15 мегабайт данных о событиях в день для указанной среды.
Дополнительные сведения о настройке сбора данных журнала событий Windows с помощью агента Azure Monitor см. в статье Сбор событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor.
Дополнительные сведения о событиях Windows см. в разделе Свойства записей событий Windows.
Оценка приема диагностика
Служба диагностика создает журналы действий как для действий пользователя, так и для административных действий.
Ниже перечислены имена журналов действий, отслеживаемых счетчиком диагностики:
- WVDCheckpoints
- WVDConnections
- WVDErrors
- WVDFeeds
- WVDManagement
- WVDAgentHealthStatus
Служба отправляет диагностические сведения всякий раз, когда среда соответствует условиям, необходимым для создания записи. Так как количество диагностических записей непредсказуемо, для этой оценки мы используем диапазон от 500 до 1000 событий на виртуальную машину в день на основе примеров из работоспособных сред.
Например, если мы оцениваем размер каждой диагностической записи в этом примере в 200 байтов, то общий объем данных, которые будут приниматься, будет меньше 1 МБ на виртуальную машину в день.
Дополнительные сведения о категориях журнала действий см. в статье Виртуальный рабочий стол Azure диагностика.
Измерение данных счетчика производительности и управление ими
Реальные затраты на мониторинг будут зависеть от размера среды, использования и работоспособности. Сведения о том, как измерять прием данных в рабочей области Log Analytics, см. в статье Анализ использования в рабочей области Log Analytics.
Счетчики производительности, используемые узлами сеансов, являются одним из крупнейших источников приема данных для Аналитики виртуальных рабочих столов Azure. В этом запросе отображаются все счетчики производительности, включенные в среде, а не только счетчики по умолчанию для Аналитики виртуальных рабочих столов Azure. Эти сведения помогут вам понять, на какие области следует ориентироваться для снижения затрат.
Выполните следующий пользовательский шаблон запроса для рабочей области Log Analytics, чтобы отслеживать частоту приема и мегабайты для счетчика производительности за последний день:
Примечание.
Обязательно замените значения заполнителей шаблона значениями, которые используются в среде. В противном случае запрос не будет работать.
let WVDHosts = dynamic(['host1.contoso.com', 'host2.contoso.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames = dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes / Records
| sort by Records desc
Оценка общих затрат
Наконец, давайте оценим общую стоимость. В этом примере предположим, что мы пришли к следующим результатам на основе примеров значений в предыдущих разделах:
| Источник данных | Оценка размера в день (в мегабайтах) |
|---|---|
| Счетчики производительности | 90-130 |
| События | 2-15 |
| Диагностика Виртуального рабочего стола Azure | < 1 |
В этом примере общий объем приема данных для Аналитики виртуальных рабочих столов Azure составляет от 92 до 145 мб на виртуальную машину в день. Иными словами, каждые 31 день каждая виртуальная машина принимать примерно от 3 до 5 гигабайт данных.
Используя модель оплаты по мере использования по умолчанию для цен на Log Analytics, вы можете оценить затраты на сбор и хранение данных Azure Monitor в месяц. В зависимости от приема данных вы также можете рассмотреть модель резервирования емкости для ценообразования Log Analytics.
Управление приемом данных для снижения затрат
В этом разделе объясняется, как измерять прием данных и управлять ими для снижения затрат.
Сведения об управлении правами и разрешениями для книги см. в разделе Управление доступом.
Примечание.
Удаление точек данных повлияет на соответствующие визуальные элементы в Аналитике Виртуальных рабочих столов Azure.
Параметры Log Analytics
Ниже приведены некоторые рекомендации по оптимизации параметров Log Analytics для управления приемом данных.
- Используйте назначенную рабочую область Log Analytics для ресурсов Виртуального рабочего стола Azure, чтобы убедиться, что Log Analytics собирает только счетчики производительности и события для виртуальных машин в развертывании Виртуального рабочего стола Azure.
- Настройте параметры хранилища Log Analytics для управления затратами. Вы можете сократить срок хранения, оценить, будет ли ценовая категория фиксированного хранилища более экономичной, или установить границы на объем данных, которые можно принять, чтобы ограничить влияние неработоспособного развертывания. Дополнительные сведения см. в статье Сведения о ценах на журналы Azure Monitor.
Удаление избыточных данных
Наша конфигурация по умолчанию — это единственный набор данных, который мы рекомендуем использовать для Аналитики виртуальных рабочих столов Azure. Вы всегда можете добавить дополнительные точки данных и просмотреть их в браузере "Диагностика узла: узел" или создать для них пользовательские диаграммы, однако добавление данных увеличит затраты на Log Analytics. Их можно удалить для экономии средств.
Измерение данных счетчика производительности и управление ими
Реальные затраты на мониторинг будут зависеть от размера среды, использования и работоспособности. Сведения о том, как измерять прием данных в рабочей области Log Analytics, см. в статье Анализ использования в рабочей области Log Analytics.
Счетчики производительности, используемые узлами сеансов, вероятно, будут крупнейшим источником данных, которые будут приниматься для Аналитики виртуальных рабочих столов Azure. Следующий пользовательский шаблон запроса для рабочей области Log Analytics позволяет отслеживать частоту и мегабайты, которые были приема данных для каждого счетчика производительности за последний день:
let WVDHosts = dynamic(['host1.contoso.com', 'host2.contoso.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames = dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes / Records
| sort by Records desc
Примечание.
Обязательно замените значения заполнителей шаблона значениями, которые используются в среде. В противном случае запрос не будет работать.
В этом запросе отображаются все счетчики производительности, включенные в среде, а не только счетчики по умолчанию для Аналитики виртуальных рабочих столов Azure. Эти сведения помогут вам понять, в каких областях следует сократить затраты, например уменьшить частоту счетчика или полностью удалить ее.
Вы также можете снизить затраты, удалив счетчики производительности. Сведения о том, как удалить счетчики производительности или изменить существующие счетчики, чтобы уменьшить их частоту, см. в статье Настройка счетчиков производительности.
Управление журналами событий Windows
События Windows вряд ли вызовют всплеск приема данных, если все узлы работоспособны. Неработоспособный узел может увеличить количество событий, отправляемых в журнал, но эти сведения могут иметь решающее значение для устранения проблем с узлом. Мы рекомендуем сохранить их. Дополнительные сведения об управлении журналами событий Windows см. в статье Настройка журналов событий Windows.
Управление диагностика
Виртуальный рабочий стол Azure диагностика должен составлять менее 1 % затрат на хранение данных, поэтому мы не рекомендуем удалять их. Чтобы управлять диагностика Виртуального рабочего стола Azure, используйте Log Analytics для функции диагностика.
Дальнейшие действия
Дополнительные сведения о Аналитике виртуальных рабочих столов Azure см. в следующих статьях:
- Используйте Аналитику виртуальных рабочих столов Azure для мониторинга развертывания.
- Используйте глоссарий , чтобы узнать больше о терминах и понятиях.
- Если у вас возникла проблема, проверка наше руководство по устранению неполадок за помощью.
- Дополнительные сведения об управлении затратами на мониторинг см. в статье Затраты и использование Azure Monitor .