Журнал производительности windows server — Ваш верный помощник с OS Windows

Как посмотреть логи Windows Server 2022. Журнал событий.

Операционная система Windows, системные службы и приложения записывают события и ошибки в системные журналы, чтобы в дальнейшем у системного администратора была возможность проверки операционной системы и диагностики проблем.

Получить доступ к этим записям можно через встроенное приложение Просмотр событий (Event Viewer). Есть несколько вариантов запуска данного приложения:

через меню Пуск – Просмотр событий (Start – Event Viewer)

в командной строке или в окне Выполнить набрать eventvwr.msc

в Диспетчере серверов в разделе Средства выбрать Просмотр событий (Server Manager – Tools – Event Viewer). В диспетчер серверов можно зайти, через меню «Пуск»

Описание интерфейса программы

Окно программы состоит из следующих компонентов:

1. Панель навигации позволяет выбрать конкретный журнал, записи которого необходимо просмотреть;

2. Список событий, содержащийся в выбранном журнале. В колонках выведена базовая информация о событии. Их можно отсортировать по датам, типам, категориям событий и т.д.;

3. Детальная информация о выбранном во второй панели событии. Также детальную информацию можно открыть в отдельном окне, если кликнуть по нужному событию два раза;

4. Панель быстрых действий, которые можно совершить с данным журналом или событием. Действия также доступны в контекстном меню (клик правой кнопкой мыши по журналу или событию).

Для удобства просмотра и управления системные журналы разбиты по категориям:

Приложения (Application) – как и гласит название, содержит события и ошибки приложений;
Безопасность (Security) – если в операционной системе включена и настроена функция аудита, журнал будет содержать записи, связанные с отслеживанием соответствующих событий (например, авторизация пользователя или попытки неудачного входа в операционную систему);
Система (System) – здесь регистрируются события операционной системы и системных сервисов;
Установка (Setup) – события, связанные с инсталляцией обновлений Windows, дополнительных приложений.

В разделе Журналы приложений и служб (Applications and Services Logs) можно найти более детальную информацию о событиях отдельных служб и приложений, зарегистрированных в операционной системе, что бывает полезно при диагностике проблем в работе отдельных сервисов.

Сами события также разделяются на типы:

Сведения (Information) — информируют о штатной работе приложений.
Предупреждение (Warning) — событие, свидетельствующее о возможных проблемах в будущем (например, заканчивается свободное место на диске – приложения могут продолжать работу в штатном режиме, но когда место закончится совсем, работа будет невозможна).
Ошибка (Error) — проблема, ведущая к деградации приложения или службы, потерям данных.
Критическое (Critical) — значительная проблема, ведущая к неработоспособности приложения или службы.
Аудит успеха (Success audit) — событие журнала Безопасность (Security), обозначающее успешно осуществленное действие, для которого включено отслеживание (например, успешный вход в систему).
Аудит отказа (Failure audit) — событие журнала Безопасность (Security) обозначающее безуспешную попытку осуществить действие, для которого включено отслеживание (например, ошибка входа в систему).

Как узнать, кто перезагрузил (выключил) сервер Windows?

Информация об учетной записи, которая отправила команду перезагрузки Windows сохраняется в журнал событий.

Откройте консоль Event Viewer и перейдите в раздел Windows Logs -> System;

2. Включите фильтр журнала событий в панели быстрых действий справа

3. В поле фильтра укажите EventID 1074 и нажмите OK;

4. В журнале событий останутся только события выключения (перезагрузки), откройте нужное событие

В событии от источника User32 будет указан пользователь, который инициировал перезагрузку Windows. В этом примере это пользователь Administrator.

В качестве пользователя, запустившего перезагрузку операционную систему может быть указан NT AUTHORITY\SYSTEM.

Это означает, что перезагрузку инициировала одна из служб или программ Windows, запущенная от имени SYSTEM.. Например, это может быть процесс службы wuauserv, который закончил установку обновлений Windows и выполнил перезагрузку согласно настроенной политике Windows Update или с помощью задания модуля PSWindowsUpdate.

The process C:\Windows\uus\AMD64\MoUsoCoreWorker.exe (WKS-PC11S22) has initiated the restart of computer WKS-PC11S22 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Service pack (Planned)
Reason Code: 0x80020010
Shutdown Type: restart
Comment:

Если у Вас виртуальный сервер, и он был перезагружен из панели управления VMmanager6, то в журнале может быть следующая запись:

По событию 1074 можно найти только причины корректных (штатных) перезагрузок сервера. Если Windows была перезагружена не штатно (например, при потере электропитания, или появления BSOD), тогда нужно искать события с EventID 6008.

Просмотр журнала производительности Windows

В просмотре событий Windows можно найти достаточное количество интересных вещей, например — посмотреть на проблемы с производительностью компьютера. Для этого в левой панели откройте Журналы приложений и служб — Microsoft — Windows — Diagnostics-Perfomance — тут вы можете наблюдать, есть ли среди событий какие-либо ошибки — они сообщают о том, что какой-то компонент или программа привела к замедлению загрузки Windows. По двойному клику по событию, вы можете вызвать подробную информацию о нем.

Источник

В этой статье мы рассмотрим особенности использования встроенных счетчиков производительности Performance Monitor для мониторинга состояния Windows Server. Счетчики PerfMon можно использовать для отслеживания изменений определенных параметров производительности сервера (алертов) и оповещать администратора в случае возникновения высокой загрузки или других нештатных состояниях.

Чаще всего для мониторинга работоспособности, доступности, загруженности серверов используются сторонние продукты. Если вам нужно получать информацию о производительности приложений либо железа только с одного-двух Windows-серверов, либо когда это нужно на непостоянной основе, либо возник более сложный случай, требующий глубокого траблшутинга производительности, то можно воспользоваться встроенным функционалом Windows Performance Monitor.

Performance Monitor имеет огромное количество счётчиков для получения информации о железе, операционной системе, установленном ПО в виде конкретных цифр. Performance Monitor может вести наблюдение за показателями производительности сервера в реальном времени или записывать историю.

Основные возможности Performance Monitor, которые можно использовать отдельно или совместно с другими сторонними системами мониторинга (типа Zabbix, Nagios, Cacti и другие):

cистема мониторинга при выводе информации о производительности сначала обращается к Performance Monitor;
главной задачей системы мониторинга является оповещение о наступлении тревожного момента, аварии, а у Performance Monitor – собрать и предоставить диагностические данные.

Текущие значения производительности Windows можно получить из Task Manager, но Performance Monitor умеет несколько больше:

Task Manager работает только в реальном времени и только на конкретном (локальном) хосте;
в Performance Monitor можно подключать счётчики с разных серверов, вести наблюдение длительное время и собранную информацию сохранять в файл;
в Task Manager очень мало показателей производительности.

Мониторинг производительности процессора с Perfomance Monitor

Для снятия данных о производительности процессора воспользуемся несколькими основными счётчиками:

\Processor\% Processor Time — определяет уровень загрузки ЦП, и отслеживает время, которое ЦП затрачивает на работу процесса. Уровень загрузки ЦП в диапазоне в пределах 80-90 % может указывать на необходимость добавления процессорной мощности.
\Processor\%Privileged Time — соответствует проценту процессорного времени, затраченного на выполнение команд ядра операционной системы Windows, таких как обработка запросов ввода-вывода SQL Server. Если значение этого счетчика постоянно высокое, и счетчики для объекта Физический диск также имеют высокие значения, то необходимо рассмотреть вопрос об установке более быстрой и более эффективной дисковой подсистемы (см. более подробную статью об анализе производительности дисков с помощью PerfMon).
\Processor\%User Time — соответствует проценту времени работы CPU, которое он затрачивает на выполнение пользовательских приложений.

Запустите Performance Monitor с помощью команды perfmon. В разделе Performance Monitor отображается загрузкой CPU в реальном времени с помощью графика (параметр Line), с помощью цифр (параметр Report), с помощью столбчатой гистограммы (параметр Histogram bar) (вид выбирается в панели инструментов). Чтобы добавить счетчики, нажмите кнопку “+” (Add Counters).

Картинка с сайта: winitpro.ru

Слева направо двигается линия в реальном времени и отображает график загрузки процессора, на котором можно увидеть, как всплески, так и постоянную нагрузку.

Например, вам нужно посмотреть загрузку процессора виртуальными машинами и самим Hyper-V. Выберите группу счетчиков Hyper-V Hypervisor Logical Processor, выберите счетчик % Total Run Time. Вы можете показывать нагрузку по всем ядрам CPU (Total), либо по конкретным (HV LP №), либо всё сразу (All Instances). Выберем Total и All Instances.

Группы сборщиков данных в PerfMon

Чтобы не сидеть целый за наблюдением движения линии, создаются группы сбор данных (Data Collector Set), задаются для них параметры и периодически просматриваются.

Чтобы создать группу сбора данных, нужно нажать на разделе User Defined правой кнопкой мыши, в меню выбрать New -> Data Collector Set. Выберите Create manually (Advanced) -> Create Data Logs и включите опцию Performance Counter. Нажмите Add и добавите счётчики. В нашем примере % Total Run Time из группы Hyper-V Hypervisor Logical Processor и Available MBytes из Memory. Установите интервал опроса счётчиков в 3 секунды.

Далее вручную запустите созданный Data Collector Set, нажав на нём правой кнопкой мыши и выбрав в меню пункт Start.

запустить сбор данных в perfomance monitor

Через некоторое время можно просмотреть отчёт. Для этого в контекстном меню группы сбора данных нужно выбрать пункт Latest Report. Вы можете посмотреть и проанализировать отчёт производительности в виде графика. Отчёт можно скопировать и переслать. Он хранится в C:\PerfLogs\Admin\CPU_Mon и имеет расширение .blg.

Если нужно на другом сервере запустить такой же набор счётчиков, как на первом, то их можно переносить экспортом. Для этого в контекстном меню группы сбора данных выберите пункт Save Template, укажите имя файла (расширение .xml). Скопируйте xml файл на другой сервер, создайте новую группу сбора данных, выберите пункт Create from a template и укажите готовый шаблон.

Создание Alert для мониторинга загрузки CPU

В определённый критический момент в Performance Monitor могут срабатывать алерты, которые помогают ИТ-специалисту прояснить суть проблемы. В первом случае алерт может отправить оповещение, а во втором – запустить другую группу сбора данных.

Чтобы создать алерт в PerfMon, нужно создать ещё один Data Collector Set. Укажите его имя CPU_Alert, выберите опцию Create manually (Advanced), а затем — Performance Counter Alert. Добавьте счётчик % Total Run Time из Hyper-V Hypervisor Logical Processor, укажите границу загрузки 50 %, при превышении которой будет срабатывать алерт, установите интервал опроса счётчика в 3 секунды.

Далее нужно зайти в свойства данной группы сбора информации, перейти на вкладку Alert Action, включить опцию Log an entry in the application event log и запустить группу сбора данных. Когда сработает алерт, в журнале (в консоли Event Viewer в разделе Applications and Services Logs\Microsoft\Windows\Diagnosis-PLA\Operational) появится запись:

“Performance counter \Processor(_Total)\% Processor Time has tripped its alert threshold. The counter value of 100.000000 is over the limit value of 50.000000. 50.000000 is the alert threshold value”.

Performance counter Time has tripped its alert threshold

Здесь же рассмотрим и второй случай, когда нужно запустить другую группу сбора данных. Например, алерт срабатывает при достижении высокой загрузки CPU, делает запись в лог, но вы хотите включить сбор данных с других счётчиков для получения дополнительной информации. Для этого необходимо в свойствах алерта в меню Alert Action в выпадающем списке Start a data collector set выбрать ранее созданную группу сбора, например, CPU_Mon. Рядом находится вкладка Alert Task, в которой можно указать разные аргументы либо подключить готовую задачу из консоли Task Scheduler, указав её имя в поле Run this task when an alert is triggered. Будем использовать второй вариант.

привязка data collector set в perfmon к задаче в task Scheduler

С помощью Task Scheduler можно выполнить какие-то действия: выполнить команду, отправить письмо или вывести сообщение на экран (сейчас последниед ве функции не поддерживаются, считаются устаревшими (deprecated)). Для вывода на уведомления на экран можно использовать скриптом PowerShell. Для этого в консоли Task Scheduler создайте новую задачу, на вкладке Triggers выберите One time, на вкладке Actions в выпадающем поле Action выбирите параметр Start a program, в поле Program/Script укажите powershell.exe, а в поле Add arguments (optional) следующий код:
-WindowStyle hidden -Command "& {[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('Внимание, CPU загружен', 'Посмотреть')}"

вывод оповещения alert на экран при высокой загрузке cpu в perfmon

Для отправки письма вы можете воспользоваться командлетом PowerShell Send-MailMessage или стороннюю утилиту mailsend.exe.. Для этого создайте аналогичное задание в Task Scheduler, в поле Program/Script укажите полный путь к утилите (у нас C:\Scripts\Mail\mailsend.exe), а в поле Add arguments (optional) через параметры нужно передать значения: электронный адрес, адрес и номер порта SMTP-сервера, текст письма и заголовка, пароль:

-to [email protected] -from [email protected] -ssl -port 465 -auth -smtp smtp.ddd.com -sub Alarm -v -user [email protected] +cc +bc -M "Alarm, CPU, Alarm" -pass "it12345"

где +cc означает не запрашивать копию письма, +bc — не запрашивать скрытую копию письма.

Источник

Когда необходимо добиться максимального быстродействия и стабильности работы Windows Server, следует обратить внимание на встроенные счетчики производительности и средства анализа. Счетчики производительности и средства анализа позволяют найти слабые места и определить, что можно улучшить с помощью мониторинга текущих показателей производительности системы и средств накопления данных (журналов) о загруженности и производительности сервера. Для верной интерпретации полученных фактов необходимо понимать взаимосвязи аппаратных компонентов, влияющих на производительность сервера (Windows или Linux), и правильно использовать имеющиеся инструменты.

Главные аппаратные компоненты, которые можно модернизировать с целью повышения производительности сервера, это процессор, память, дисковая подсистема и сетевой интерфейс. Первые три компонента являются внутренними для сервера, а четвертый, сетевой интерфейс, обеспечивает взаимодействие сервера с внешним миром. Внутренняя производительность сервера определяет, будет ли сетевой интерфейс задействован на полную мощность, а от сетевого интерфейса зависит, смогут ли клиенты воспользоваться общей производительностью системы. Все четыре компонента играют важную роль и являются взаимозависимыми.

В данной статье мы рассмотрим влияние, оказываемое этими компонентами на производительность, и процесс их мониторинга средствами Windows. Но сначала нужно определить взаимосвязь этих компонентов. Затем я расскажу о том, какие счетчики производительности имеются в Windows и как они соотносятся с аппаратными компонентами. В заключение будет показано, как мониторинг производительности позволяет повысить производительность системы.

Системный подход и определение базового уровня

При мониторинге и анализе производительности серверов Windows важно использовать системный подход и учитывать взаимное влияние аппаратных компонентов. Например, при высокой загрузке процессора не следует автоматически считать, что проблема исключительно в процессоре. Нужно учесть влияние, оказываемое памятью и загрузкой жесткого диска. Возможно, система использует слишком большой объем виртуальной памяти? В этом случае высокая загрузка процессора может оказаться симптомом нехватки оперативной памяти, а не недостаточной вычислительной мощности процессора.

Анализ работы сотен серверов Windows позволяет прийти к общему заключению: использование самых быстрых процессоров далеко не всегда решает проблемы производительности. Конечно, заманчиво для решения проблемы производительности добавить процессорной мощи, но вспомним правило из реальной жизни: если потерял дорогу в городе, то чем быстрее едешь дальше — тем вернее потеряешься еще больше. Для серверов это означает, что процессор просто быстрее отрабатывает больше циклов ожидания, пока не завершится прохождение действительно узкого места, вызвавшего задержку обработки задания.

При анализе производительности сервера Windows следует сопоставлять работу всех четырех основных компонентов одновременно. Системный подход подсказывает, что надо рассматривать систему в целом, а не отдельные компоненты. Благодаря применению системного подхода действительная причина проблемы будет обнаружена быстрее.

Перед тем как перейти к исследованию счетчиков производительности, следует пояснить необходимость выбора базового уровня. Базовый уровень производительности представляет собой такой уровень быстродействия сервера, когда система работает с нагрузкой, и операции выполняются с приемлемой для решения задачи скоростью. Базовый уровень производительности определяется при мониторинге и сохранении журналов производительности сервера во время нормальной работы сервера. Я предпочитаю отслеживать уровень производительности в течение всего нормального рабочего дня организации, например с 9:00 до 18:00. После того как журналы производительности созданы, можно открыть инструментарий анализа производительности системы и просмотреть моменты наибольшей загруженности системы. Если производительность сервера в эти моменты была приемлемой, можно сделать вывод, что сервер обладает достаточной производительностью для решаемого класса задач.

С течением времени в большинстве организаций нагрузка на сервер возрастает. Пользователи осваивают систему, начинают работать более активно, используют новые функции, поэтому требования к быстродействию сервера возрастают. Кроме того, обычно к системе подключаются еще и новые пользователи. Все эти факторы могут привести к тому, что производительность сервера со временем может оказаться недостаточной. В таком случае следует собрать новые журналы счетчиков производительности и сравнить их с исходным базовым уровнем, чтобы определить проблемные области. При дальнейшем обсуждении необходимо иметь в виду, что следует рассматривать показания счетчиков производительности в сравнении с базовым уровнем, а не просто как результаты текущих измерений.

Счетчик производительности центрального процессора

Средство мониторинга надежности и производительности Reliability and Performance Monitor в Windows Server 2008 и инструмент для измерения производительности системы System Performance в Windows Server 2003 R2 предоставляют администраторам важные счетчики производительности, отражающие работу главных компонентов сервера. Средство измерения производительности системы часто называют системным монитором, хотя в заголовке его окна написано Performance. Основные счетчики производительности центрального процессора предоставляются объектами Processor и Process. Наиболее информативными являются счетчики процента загруженности процессора, % Processor Time, процента работы в пользовательском режиме, % User Time, и процента работы в привилегированном режиме, % Privileged Time. Предоставляемые объектом Processor, эти счетчики позволяют отслеживать как загрузку отдельных процессоров сервера, так и общую загрузку всех процессоров (см. экран 1). Эти же счетчики доступны через объект Process, и в этом случае они позволяют определить использование процессоров отдельными или всеми процессами, выполняемыми на сервере.

Если вы видите, что счетчик процента загруженности процессора для объекта Processor имеет высокое значение, вы можете с помощью объекта Process настроить мониторинг для каждого отдельного процесса. Это позволит определить, какие из процессов требуют больше всего процессорного времени. Возможно, некоторые процессы могут быть перенесены на другие серверы, а могут даже обнаружиться лишние процессы, которые можно остановить без ущерба для работы сервера. Просто удивительно, как много бывает на сервере Windows неиспользуемых процессов, которые могут замедлять работу сервера, поскольку ядро Windows вынуждено тратить часть ресурсов на управление этими процессами. Примерами таких процессов являются неиспользуемые приложения автозапуска и службы и дополнительные компоненты приложений, выполняемые в отдельных процессах.

Счетчик процента загруженности процессора включает суммарное время выполнения задач в пользовательском режиме и режиме ядра операционной системы. С технической точки зрения это время, в течение которого не выполняется процесс бездействия системы System Idle. Процесс бездействия системы выполняется все время, когда не выполняются другие процессы, использующие процессорное время. По моим наблюдениям, загрузка сервера может считаться высокой, если среднее значение счетчика процента загруженности процессора превышает 65–70%.

Счетчики процента работы в пользовательском режиме (% User Time) и процента работы в привилегированном режиме (% Privileged Time) позволяют по отдельности отслеживать время процессов в пользовательском режиме и режиме ядра. Они могут помочь определить, где находится источник проблем — в пользовательских приложениях или в самой операционной системе. При этом необходимо учитывать архитектуру Windows. Большинство операций выполняется в режиме ядра, поэтому часто более 70% операций может выполняться в режиме ядра или привилегированном режиме.

Счетчики памяти

Наиболее важные счетчики использования памяти с точки зрения общего анализа быстродействия сервера находятся в объекте памяти Memory (экран 2).

По-моему, наиболее информативными являются счетчики доступной памяти в килобайтах, Available Kbytes и обмена страниц в секундах, Pages/sec. Счетчик доступной памяти в КБ показывает значения в более удобном виде, чем слишком детальный Available Bytes и слишком грубый счетчик Available Mbytes.

Счетчик Pages/sec показывает количество страниц виртуальной памяти, которые считываются или записываются в секунду. Для большинства систем размер страницы составляет 4 Кбайт, так что если взять показания данного счетчика, умноженные на 4, то получим представление об объеме данных, перемещаемом между оперативной памятью и дисковой системой за секунду.

Счетчики жестких дисков

Счетчики жестких дисков разделены на два объекта для логического диска LogicalDisk и физического диска PhysicalDisk. Эти счетчики очень близки по смыслу, но различаются способом идентификации дисков. Логический диск определяет диск по букве диска, а физический диск — по номеру (диск 0). Оба объекта показывают одинаковую информацию для одного выбранного счетчика. Но если требуется отслеживать активность для всех разделов физического диска, следует использовать объект физического диска PhysicalDisk. Основные счетчики, на которые следует обратить внимание, — это средняя длина очереди диска Average Disk Queue Length, скорость обмена с диском в байт/с Disk bytes/sec и свободной памяти в мегабайтах Free Megabytes.

Счетчик Average Disk Queue Length показывает, успевает ли накопитель отработать все запросы от выполняющихся процессов. Обычно в качестве порогового значения устанавливают длину очереди, состоящую из двух элементов. Если среднее число элементов в очереди более двух, это может служить симптомом повышенной нагрузки на дисковую систему. Этот счетчик тоже следует сопоставлять с базовым уровнем. Например, если за базовый уровень выбрано значение 2,3 элемента в очереди, и быстродействие системы при этом приемлемое, то, когда в будущем при возникновении проблем с общей производительностью сервера дисковая подсистема покажет те же или даже более низкие уровни загрузки, источник проблемы, скорее всего, следует искать в другом месте. Нормальное быстродействие определяется статистически, а какое быстродействие считать хорошим или плохим — понятие относительное, зависящее от исполняемых приложений и требований, которые пользователи предъявляют к системе.

Счетчик Disk bytes/sec может показать, соответствует ли работа диска заявленным производителем характеристикам. Иногда диски, для которых заявлена определенная скорость работы, в действительности могут работать с меньшей скоростью. Данный счетчик позволяет это обнаружить. Часто для решения проблемы снижения производительности дисковой системы по сравнению с заявленной достаточно обновить драйвер контроллера диска.

В сущности, Free Megabytes не является счетчиком производительности, но его можно использовать для прогнозирования потребления дискового пространства. Например, если ежемесячно измерять объем свободного пространства для каждого тома, можно определить скорость увеличения объема, занимаемого данными на диске. Журнал потребления дискового пространства поможет прогнозировать сроки, когда потребуется перенос устаревших данных в архив или увеличение объема дискового пространства.

Счетчики сетевых интерфейсов

Наконец, рассмотрим счетчики сетевых интерфейсов, доступ к которым предоставляется объектом Network Interface. Два главных счетчика — общей скорости в байт/с Bytes Total/sec и длины очереди вывода Output Queue Length. Счетчик Bytes Total/sec следует сопоставлять с принятым базовым уровнем. Если сетевой обмен значительно возрастает по сравнению с базовым уровнем, обычно это означает, что нагрузка на сервер существенно возросла по сравнению с нагрузкой, которая наблюдалась при определении базового уровня. Но это может также служить индикатором сетевой атаки или показывать необходимость разгрузки некоторых процессов. Счетчик Output Queue Length поможет определить, что требуется предпринять. Если среднее значение счетчика более двух, это значит, что сетевой интерфейс (или пропускная способность сетевой инфраструктуры) не справляется с передачей данных, предоставляемых сервером. Другими словами, сервер выдает данные с большей скоростью, чем сетевой интерфейс в состоянии передать.

Сохранение значений счетчиков

Теперь, когда рассмотрены 10 основных счетчиков быстродействия, которые помогают следить за главными факторами, определяющими быстродействие сервера, рассмотрим подробнее, каким образом эти счетчики можно получить и сохранить. Ниже приведены инструкции, как получить данные этих счетчиков с помощью инструмента Performance для Windows 2003 R2 или Windows 2003.

Запустите инструмент Performance, выбрав Start, All Programs, Administrative Tools, Performance. Вы увидите, что счетчики Pages/sec, Avg. Disk Queue Length, и % Processor Time уже загружены.
Для добавления счетчиков нажмите кнопку со значком плюс (или клавишами Ctrl+I).
По умолчанию выбран объект Processor. В разделе выбора счетчиков Select counters from list выделите % Privileged Time и нажмите Add.
При необходимости прокрутите список, выделите счетчик % User Time и нажмите Add.
Выберите объект логического диска LogicalDisk и добавьте счетчики Disk bytes/sec и Free Megabytes, как описано в п. 3 и 4.
Выберите объект Memory и добавьте счетчик Available Kbytes.
Наконец, выберите объект Network Interface и добавьте счетчики Bytes Total/sec и Output Queue Length.

После выбора нужных счетчиков нажмите OK; графики должны иметь вид, как на экране 3.

По умолчанию мониторинг счетчиков выполняется автоматически и продолжается до тех пор, пока вы не остановите процесс. Уровень загрузки сервера может изменяться в зависимости от интенсивности работы. Загрузка счетчиков быстродействия в инструмент измерения производительности позволяет осуществлять мониторинг текущей деятельности, но это только одно из применений. Теперь следует создать журнал сведений о производительности, необходимый для определения базового уровня. Приведенные ниже инструкции позволяют создать журнал данных о производительности сервера за любой выбранный промежуток времени.

Запустите инструмент Performance, как описывалось ранее.

В левой панели окна Performance разверните узел журналов и оповещений производительности Performance Logs and Alerts.
Щелкните правой кнопкой мыши на Counter Logs и выберите изменение настроек журнала New Log Settings.
Введите имя журнала, например «Базовый_уровень_1».
На вкладке General нажмите кнопку добавления счетчиков Add Counters и добавьте счетчики, значения которых требуется сохранить.
Перейдите на вкладку журналов Log Files и выберите удобный для анализа формат файла журнала. Я рекомендую использовать текст с разделителем запятыми (CSV), как наиболее удобный для анализа в Microsoft Excel.
На вкладке расписания Schedule укажите время для автоматического запуска и остановки журнала или выберите запуск вручную. Эту операцию можно выполнить после того, как журнал уже создан.
Нажмите ОК.
Если система запросит создание папки для журналов, нажмите Yes.

Таким образом, журналы производительности настроены. Подготовив журнал для сохранения описанных в данной статье 10 счетчиков производительности, вы получите хорошую основу для определения базового уровня. Применяйте эти настройки для сбора показателей, соответствующих нормальной работе систем. Если вдруг пользователи начнут жаловаться на недостаточную производительность, вы сможете сравнить текущие журналы со старыми данными, когда все было хорошо. На экране 4 представлены два линейных графика Excel 2007, построенных из файлов CSV инструмента Performance.

Измеряйте быстродействие системы относительно базового уровня

Инструмент Performance предоставляет счетчики, которые могут использоваться для измерения быстродействия аппаратного обеспечения системы относительно рекомендуемых значений или базового уровня. Главным условием успешного использования инструмента является правильный выбор счетчиков производительности. Следует иметь в виду, что при установке серверных приложений Microsoft (Microsoft SQL Server, Microsoft Exchange Server, Microsoft IIS) в систему добавляются новые счетчики производительности для установленного приложения.

Том Карпентер (carpenter@sysedco.com) — старший консультант в компании SYSEDCO. Тренер и автор ряда книг, в том числе SQL Server 2005 Implementation and Maintenance (McGraw-Hill)

Источник

Что такое Монитор Производительности?

Монитор производительности — это мощный инструмент, который предоставляет данные в реальном времени и исторические данные о производительности системы в Windows Server 2019. Он позволяет администраторам отслеживать различные показатели производительности, помогая в диагностике проблем, оптимизации выделения ресурсов и обеспечении бесперебойной работы сервера.

Основные функции монитора производительности

Монитор производительности предлагает несколько продвинутых функций, разработанных для комплексного анализа системы.

Сбор данных в реальном времени: Отслеживание производительности системы по мере ее происходит, обеспечивая немедленную диагностику и устранение проблем. Это крайне важно для решения внезапных снижений производительности или неожиданного поведения в приложениях.
Анализ исторических данных: Собирайте и анализируйте данные со временем, чтобы выявить тенденции и периодические проблемы. Эта функция является неотъемлемой для долгосрочной настройки производительности и планирования мощности, предоставляя понимание паттернов, которые могут быть неочевидны при мониторинге в реальном времени.
Наборы сбора данных, настраиваемые пользователем: создавайте наборы для сбора конкретных метрик на основе уникальных требований. Эти наборы могут быть настроены для мониторинга конкретных служб, приложений или аппаратных компонентов, обеспечивая гибкость в управлении производительностью.
Удаленный мониторинг: Управляйте несколькими серверами из одного интерфейса с использованием интеграции с Windows Admin Center. Эта функция позволяет администраторам контролировать производительность сети серверов без необходимости физического доступа, улучшая эффективность и время реакции.
Улучшенная визуализация: Несколько типов графиков и улучшенный пользовательский интерфейс для более легкой интерпретации данных. Эти визуальные средства включают линейные графики, гистограммы и столбчатые диаграммы, которые помогают быстро понять показатели производительности и выявить аномалии.

Дополнительные функции

Оповещения и уведомления: Настройте оповещения, чтобы уведомлять администраторов, когда счетчики производительности превышают заранее определенные пороги, обеспечивая проактивное управление.
Сценарии и автоматизация: используйте PowerShell или другие языки сценариев для автоматизации задач мониторинга, сокращая ручное вмешательство и обеспечивая постоянное отслеживание производительности.

Пользуясь этими функциями, Performance Monitor помогает ИТ-специалистам поддерживать надежную производительность сервера, эффективно выявлять и устранять проблемы, а также оптимизировать выделение ресурсов для различных рабочих нагрузок.

Настройка монитора производительности на Windows Server 2019

Доступ к монитору производительности

Для доступа к Монитору производительности выполните следующие шаги:

Откройте Windows Admin Center: Убедитесь, что у вас установлен и настроен Windows Admin Center.
Перейдите в Диспетчер серверов: Откройте Диспетчер серверов из ваших административных инструментов.
Выберите Монитор производительности: Выберите Монитор производительности из списка доступных инструментов в Менеджере сервера.

Создание наборов сбора данных

Наборы сбора данных (DCS) необходимы для отслеживания конкретных показателей производительности со временем. Вот как создать DCS:

Открыть Монитор Производительности: Запустите инструмент Монитор Производительности.
Щелкните правой кнопкой мыши на наборах сбора данных: Выбрать

New

>

Data Collector Set

.
Следуйте мастеру: добавьте счетчики производительности, установите интервалы выборки и укажите форматы журналов.

Настройка счетчиков

Счетчики — это конкретные метрики, которые отслеживает Монитор Производительности. Примеры включают использование ЦП, использование памяти и активность диска.

Выберите счетчики: выберите соответствующие счетчики для ваших потребностей в мониторинге.
Настроить интервал выборки: Установите, как часто данные выбираются (например, каждые 15 секунд).
Укажите формат журнала: выберите между форматами, такими как двоичный, текстовый или SQL.

Использование шаблонов для наборов сборщика данных

Для оптимизации развертывания DCS на нескольких серверах вы можете использовать шаблоны:

Создание и настройка DCS: Установите DCS на сервере-эталоне.
Экспорт конфигурации: Экспорт конфигурации DCS в файл шаблона XML.
Импортировать шаблон на другие серверы: используйте шаблон для воспроизведения настройки на других серверах.

Использование Монитора производительности для устранения неполадок

Мониторинг в реальном времени

Для немедленного устранения неполадок ценно реальное мониторинг. Администраторы могут добавлять счетчики на лету, чтобы видеть, как система работает в текущих условиях. Данные в реальном времени позволяют быстро выявлять и устранять проблемы, такие как всплески ЦП, утечки памяти или узкие места ввода-вывода диска.

Добавление счетчиков в реальном времени

Откройте Монитор Производительности: Перейдите к инструменту Монитор Производительности.
Добавить счетчики: Нажмите

+

иконка для добавления новых счетчиков.
Выберите соответствующие метрики: выберите метрики, соответствующие проблеме, которую вы решаете.

Анализ исторических данных

Мониторинг производительности позволяет собирать и анализировать исторические данные. Эта возможность критически важна для выявления временных проблем, которые не могут быть легко воспроизведены в реальном времени. Исторические данные могут раскрывать закономерности и тенденции, помогая в долгосрочном планировании производительности и управлении мощностью.

Анализ исторических данных

Открыть сохраненные данные: Загрузить исторические журналы производительности из Монитора производительности.
Изучите тенденции: ищите повторяющиеся проблемы или тенденции со временем.
Генерация отчетов: Создание подробных отчетов для обмена результатами с заинтересованными сторонами.

Оповещения и уведомления

Настройка оповещений на основе порогов производительности может помочь в проактивном мониторинге. Монитор производительности может срабатывать оповещения, когда определенные счетчики превышают установленные пределы, позволяя администраторам принимать корректирующие действия до того, как проблемы усугубятся.

Настройка оповещений

Создать новое оповещение: В Мониторе производительности щелкните правой кнопкой мыши на Оповещения и выберите

New Alert

.
Установите пороги: Определите условия, при которых срабатывает предупреждение (например, использование ЦП > 80%).
Настроить действия: Укажите действия, такие как отправка уведомлений по электронной почте или запуск сценариев.

Лучшие практики мониторинга производительности

Регулярный мониторинг

Постоянный мониторинг показателей производительности помогает в раннем обнаружении потенциальных проблем. Регулярный мониторинг обеспечивает плавную и эффективную работу систем. Внедрение запланированного сбора данных и регулярного анализа журналов производительности может предотвратить превращение мелких проблем в крупные проблемы. Использование автоматизированных инструментов для сбора данных с определенной периодичностью снижает вероятность человеческой ошибки и обеспечивает полное охватывание. Кроме того, регулярный мониторинг помогает выявить тенденции и сезонные колебания нагрузки, что критично для планирования мощности и выделения ресурсов.

Пользовательские панели.

Используйте настраиваемые панели инструментов для фокусировки на критических метриках, важных для вашей среды. Настройка представлений под конкретные потребности повышает эффективность мониторинга. Используйте Центр администрирования Windows для создания и настройки панелей инструментов, отображающих ключевые показатели эффективности (KPI) на лету. Настраиваемые панели инструментов обеспечивают централизованный обзор состояния системы, что упрощает обнаружение аномалий и снижение производительности.

Создание пользовательских панелей.

Откройте Windows Admin Center: перейдите на вкладку «Панель инструментов», чтобы начать создание пользовательского представления.
Добавить виджеты: перетащите виджеты для наиболее важных метрик, таких как использование ЦП, использование памяти и пропускная способность сети.
Сохранить и поделиться: Сохраните панель и поделитесь ею с вашей командой. Общие панели гарантируют, что все члены команды имеют доступ к одной и той же информации и могут эффективно сотрудничать при решении проблем и задач оптимизации.

Сотрудничество

Совместное использование рабочих пространств и шаблонов способствует сотрудничеству среди членов команды, обеспечивая, что все находятся на одной волне и следуют лучшим практикам. Такой коллективный подход улучшает общее управление системой и позволяет разделять ответственность за поддержание здоровья сервера. Использование общих шаблонов для наборов сборщиков данных обеспечивает согласованность конфигураций мониторинга на разных серверах и в различных средах. Регулярные обзоры команды производительности данных и панелей инструментов помогают согласовывать приоритеты и планы действий.

Реализация систем оповещения

Настройка автоматических оповещений о критических порогах производительности обеспечивает своевременное вмешательство. Оповещения могут быть настроены для отправки уведомлений по электронной почте, SMS или интегрированы с инструментами управления ИТ-сервисами. Эти оповещения обеспечивают проактивное управление, информируя администраторов о потенциальных проблемах до их влияния на пользователей.

Почему выбрать TSplus

Для тех, кто хочет улучшить свои возможности управления сервером, рассмотрите возможность исследования.

Мониторинг сервера TSplus

, комплексное решение, которое предлагает программное обеспечение для мониторинга серверов и веб-сайтов в реальном времени для удаленных рабочих инфраструктур. Посетите TSplus, чтобы узнать больше о наших решениях.

Заключение

Windows Server 2019 Performance Monitor — это универсальный и мощный инструмент для поддержания оптимальной производительности сервера. Пользуясь его продвинутыми функциями, ИТ-специалисты могут гарантировать эффективную работу своих систем, идентифицировать и решать проблемы незамедлительно, а также оптимизировать использование ресурсов эффективно.

Источник

Автор статьи — Михаил Комаров, MVP — Cloud and Datacenter Management

В данной статье будут рассмотрены:

механизм работы со счетчиками производительности;
настройка сборщиков данных как с помощью графического интерфейса, так и с помощью командной строки;
создание черного ящика для записи данных.

Также рассмотрим и обсудим работу с утилитой PAL и ее применение для сбора и анализа данных, включая типовые проблемы локализованных систем.

В общем виде задачу о производительности можно представить в виде трех частей: сбор данных, анализ полученных данных и создание черного ящика для упреждающего мониторинга проблемной системы.

Сбор данных

Начнем со всем давно известного Performance Monitor. Это стандартная утилита, которая входит во все современные редакции Windows. Вызывается либо из меню, либо из командной строки или строки поиска в Windows 8/10 вводом команды perfmon. После запуска утилиты мы видим стандартную панель, в которой можем добавить и удалить счетчики, изменить представление и масштабировать графики с данными.

Также есть сборщики данных, с помощью которых производится сбор данных о производительности системы. При определённых навыках и сноровке операции по добавлению счетчиков и настройке параметров сбора данных можно производить из графического интерфейса. Но когда возникает задача настройки сбора данных с нескольких серверов, разумнее использовать утилиты командой строки. Вот этими утилитами мы и займемся.

Первая утилита — это Typeperf, которая может выводить данные со счетчиков производительности на экран или в файл, а также позволяет получить список счетчиков, установленных в системе. Примеры использования.

Выводит на экран загрузку процессора с интервалом 1 сек.:

typeperf "\Processor(_Total)\% Processor Time"

Выводит в файл названия счётчиков производительности, связанные с объектом PhysicalDisk:

typeperf -qx PhysicalDisk -o counters.txt

В нашем случае мы можем использовать утилиту Typeperf, чтобы создать файл с нужными нам счетчиками, который в дальнейшем будем использовать как шаблон для импорта счетчиков в сборщик данных.

Следующая утилита – Logman. Данная утилита позволяет создавать, изменять и управлять различными сборщиками данных. Мы будем создавать сборщик данных для счетчиков производительности. Вот, например, краткая справка по команде Logman, которая относится к счетчикам производительности и управлению сборщиком данных.

Разберем несколько примеров, которые нам понадобятся в дальнейшем.

Создадим сборщик данных с именем DataCollector_test, импортировав счетчики производительности из файла test.xml:

logman import DataCollector_test -xml C:\PerfTest\test.xml

Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером:

logman update DataCollector_test -f bincirc -max 600

Изменение пути файла с данными производительности по умолчанию:

logman update DataCollector_test -o C:\PerfTest\Test_log.blg

Запуск коллектора данных DataCollector_test:

logman start DataCollector_test

Остановка коллектора данных DataCollector_test:

logman stop DataCollector_test

Отметим, что все эти действия можно производить с удаленным компьютером.

Рассмотрим еще одну утилиту — Relog, которая позволяет производить манипуляции с файлом данных после работы сборщика данных. Вот ее описание:

Ниже несколько сценариев применения этой утилиты.

Извлечение данных счетчиков производительности из файла logfile.blg с применением фильтра со списком счетчиков counters.txt и записью результата в бинарный формат:

relog logfile.blg -cf counters.txt -f bin

Извлечение списка счетчиков производительности из logfile.blg в текстовый файл counters.txt:

relog logfile.blg -q -o counters.txt

Напрямую работать с этой утилитой мы не будем, но информация о ней в дальнейшем поможет в случае возникновения проблем в файле PowerShell, который генерирует утилита PAL.

Отметим еще один момент, некоторые системы анализа требуют данные с наименованиями счетчиков производительности на английском языке. Если интерфейс нашей системы на русском языке, то нам необходимо проделать следующие манипуляции: завести локального пользователя, дать ему права на сбор данных (обычно дают права локального администратора), войти в систему под ним и в свойствах системы изменить язык интерфейса.

Обязательно выйти из системы и зайти во второй раз под этим пользователем для инициализации английского интерфейса и выйти из системы. Далее указать в сборщике данных, что сбор данных будет производиться от имени этого пользователя.

После этого имена счетчиков и файлов будут на английском языке.

Также отметим возможность сбора данных для SQL Server с помощью утилиты из состава продукта. Это SQLDIAG, которая обрабатывает журналы производительности Windows, журналы событий Windows, трассировки SQL Server Profiler, сведения о блокировках SQL Server и сведения о конфигурации SQL Server. Указать, какие типы сведений нужно собирать с помощью программы SQLdiag, можно в файле конфигурации SQLDiag.xml.

Для конфигурирования файла SQLDiag.xml можно использовать инструмент PSSDIAG с codeplex.com.

Вот так выглядит окно этого инструмента.

В итоге, процесс сбора данных для SQL может выглядеть так. С помощью PSSDIAG мы формируем xml-файл. Далее посылаем этот файл клиенту, который запускает SQLDIAG c нашим xml-файлом на удаленном сервере и присылает нам для анализа результат работы в виде blg-файла, который мы будем анализировать в следующей части.

Анализ данных с помощью утилиты PAL

Данная утилита написана Clint Huffman, который является PFE-инженером Microsoft и занимается анализом производительности систем. Также он является одним из авторов авторизованного курса Vital Sign, который читается в Microsoft и доступен для корпоративных заказчиков, в том числе в России на русском языке. Утилита распространяется свободно, ссылку на нее я приведу ниже.

Вот так выглядит стартовое окно утилиты.

На вкладке Counter Log задаётся путь к файлу данных со счетчиками производительности, собранными ранее. Также мы можем задать интервал, за который будет производиться анализ.

На вкладке Threshold File находится список шаблонов, которые можно экспортировать в формат xml и использовать как список счетчиков для сборщика данных. Обратите внимание на большой выбор шаблонов для анализа производительности для различных систем. Пример загрузки из командной строки был показан выше. Самое ценное, что в этих заранее подготовленных шаблонах установлены граничные значения для этих параметров, которые будут использованы в дальнейшем для анализа собранных данных!!!

Вот так, например, выглядят граничные значения для счётчиков дисковой производительности:

Мы можем создавать свои шаблоны с использованием нужных счетчиков, которые будут подстроены под нужды нашей организации.

Действуем по следующему алгоритму: на рабочей станции запускаем утилиту PAL, переходим на вкладку Threshold File и экспортируем шаблон в виде xml-файла. На основании этого файла на сервере создаем сборщик данных и запускаем сборку информации.
После сбора данных копируем полученный файл на рабочую станцию, чтобы анализом не нагружать сервер, возвращаемся на вкладку Counter Log, указываем путь к файлу. Снова переходим на Threshold File и выбираем тот самый шаблон, который экспортировали для сборщика данных.

Переключаемся на вкладку Question и указываем объем оперативной памяти на сервере, на котором был осуществлён сбор данных. В случае 32-битной системы заполним UserVa.

Переходим к вкладке Output Options, на которой задаем интервал разбиения для анализа. Значение по умолчанию AUTO делит интервал на 30 равных частей.

Вкладка File Output выглядит довольно обычно, указываем на ней путь к файлам итоговых отчетов в формате HTML или XML.

Вкладка Queue показывает итоговый скрипт на PowerShell. В общем можно сказать, что утилита собирает параметры, которые она подставляет в скрипт PAL.PS1.

Итоговая вкладка задает параметры исполнения. Можно одновременно запустить несколько скриптов и указать число потоков на процессоре. Хотелось бы акцентировать внимание, что обработку blg делает не утилита, а скрипт PowerShell, и это открывает возможности для полной автоматизации анализа логов. Например, каждые сутки перезапускается сборщик данных, в результате освобождается текущий blg-файл и создаётся новый. Старый файл копируется на специальный сервер, где будет запускаться скрипт, обрабатывающий данный файл. После этого готовый HTML- или XML-файл с результатами перемещается в определённую директорию или высылается на почтовый ящик.

Обратите внимание, что утилита должна работать только в английской локализации. Иначе получим сообщение об ошибке.

Также файл с данными должен быть с названиями счетчиков на английском. Выше я указывал, как это сделать. После нажатия Finish запустится скрипт PowerShell, время работы которого зависит от объёма данных и быстродействия рабочей станции.

Итогом работы утилиты будет отчет в выбранном формате, в котором есть графики и числовые данные, позволяющие понять, что происходило в системе за заданный период с учетом граничных значений алертов в шаблоне на вкладке Threshold File. В общем, анализ HTML-файла позволит на начальном этапе определить проблемные места в системе и понять, куда двигаться дальше, как в плане более тонкого мониторинга, так и в плане модернизации или переконфигурирования системы. В блоге Clint Huffman есть скрипт, которым можно конвертировать файл шаблона с граничными условиями в более понятный формат.

Черный ящик

Иногда возникает необходимость в превентивном мониторинге проблемной системы. Для этого мы создадим «черный ящик», в который будем записывать данные производительности. Вернемся к скриптам, описанным ранее.

Создадим сборщик данных c именем BlackBox, импортировав счетчики производительности из файла SystemOverview.xml, который выгрузили из утилиты PAL или создали самостоятельно:

logman import BlackBox -xml C:\ BlackBox\SystemOverview.xml

Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером 600 МБ (около 2 суток при стандартном наборе счетчиков):

logman update BlackBox -f bincirc -max 600

Изменение пути файла с данными производительности по умолчанию:

logman update BlackBox -o C:\ BlackBox \ BlackBox _log.blg

Запуск коллектора данных BlackBox:

logman start BlackBox

Данный скрипт создает задачу перезапуска сборщика данных в случае перезапуска системы:

schtasks /create /tn pal /sc onstart /tr "logman start BlackBox " /ru system

На всякий случай поправим свойства диспетчера данных, чтобы не заполнить место на диске, так как после перезапуска сборщика данных создается новый файл с лимитом 600 МБ.

Отметим, что скопировать файл с данными можно только при остановленном сборщике данных. Остановить же последний можно скриптом или с помощью графического интерфейса.

Остановка коллектора данных BlackBox:

logman stop BlackBox

На этом закончим часть, посвященную сбору и первичному анализу производительности.

Ресурсы

Performance Monitor
https://technet.microsoft.com/en-us/library/cc749154.aspx

Утилита PAL
https://pal.codeplex.com/

Блог Clint Huffman
http://blogs.technet.com/b/clinth/

Книга Clint Huffman
Windows Performance Analysis Field Guide
http://www.amazon.com/dp/0124167012/ref=wl…=I2TOVTYHI6HDHC

Источник