Просмотр логов SharePoint 2013, 2016 и 2019

Портальная система SharePoint, с одной стороны, является очень гибкой и кастомизируемой. С другой стороны, является далеко не самой легкой системой в поддержке и администрировании. Особенно в случаях, когда что-то перестало работать 🙁 В такие ситуациях, в первую очередь, стоит смотреть системные журналы и журналы SharePoint. Именно в этой статье мы наглядно посмотрим – как выглядит просмотр логов SharePoint – куда смотреть и какие инструменты использовать.

Краткая вводная по работе логами SharePoint

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

В стандартные журналы, которые мы можем посмотреть через EventViewer (Просмотр событий), SharePoint пишет крайне мало. Причем, как по объему, так и по количеству. В то же время, в свои собственные журналы (ULS – Unified Logging Service) SharePoint пишет очень много системной информации. Можно сказать, протоколирует практически любые действия и запросы к системе.

Расположение системных журналов SharePoint 2013:

%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\15\Logs

Расположение системных журналов SharePoint 2016 и 2019:

%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\16\Logs

Просмотр логов SharePoint

Мы рассмотрим два вида журналов, которые есть у SharePoint – журналы Windows и собственные журналы. Для первых используется Event Viewer, для вторых ULS Viewer и PowerShell.

Event Viewer (Просмотр событий)

Просмотр логов SharePoint через Event Viewer осуществляется довольно привычным для всех администраторов систем Windows – через соответствующую оснастку.

В системном журнале Windows события SharePoint записываются в ветку “Application” (Приложений).

Для удобства фильтрации мы можем выставить следующие критерии фильтрации:

При таких условия фильтрации мы получим все события от системы SharePoint, которые были зарегистрированы в системном журнале.

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

Для просмотра всего объема событий необходимо анализировать ULS логи.

ULS Viewer

Для анализа журналов ULS (Unified Logging Service) есть специальный инструмент – ULS Viewer. Скачать его можно вот по этой ссылке.

Копия дистрибутива (на 15.01.2021) доступна по ссылке ниже:

Запускаем ulsviewer:

Откроется главное окно программы:

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

ULS Viewer попытается определить расположение директории с ULS журналами:

В моем случае это был SharePoint 2016, т.е. расположение журналов было следующее – %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\16\Logs.

После этого начнется сбор сведений в режиме реального времени:

Спешу предупредить – событий будет крайне много, и чем больше нагрузка на вашу систему, тем больше будет запротоколировано событий. Как по мне – много лучше, чем мало 🙂 Всегда можно применить пару фильтров или другим образом отсечь часть событий.

В любой момент мы можем поставить на паузу сбор событий:

Ниже привожу пример события с ошибкой приведен ниже:

Это пример события с ошибкой доступа к реестру. Посмотрите скриншот выше – здесь вы можете увидеть гораздо больше информации, чем, к примеру, в системном журнале:

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

Вы также можете посмотреть какой-то один определенный журнал:

И найти нужный вам журнал. Например:

Соответственно, журнал откроется в отдельном окне и будет обновляться в режиме реального времени:

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

Модуль SharePoint для PowerShell

Есть еще один способ просмотра сообщений в журналах – PowerShell. Однако, лично мне не очень удобно пользоваться этим методом. Точнее я крайне редко им пользуюсь. В основном – это когда нужно сделать выгрузку точно известного события. Например, по EventID. При живом дебаге – когда не известно почему что-то сломалось и в чем причина я использую первые два метода – EventViewer и ULS Viewer.

Самый простой пример – получение вообще всех событий. Запускаем SharePoint Management Shell и выполняем команду:

Get-SPLogEvent

Теперь попробуем вывести все ошибки:

Get-SPLogEvent | Where-Object {$_.Level -eq "CRITICAL" }

Пример ниже – поиск по конкретному ID события. Раз мы на протяжении всей статьи рассматриваем пример с отказом доступа к реестру, то используем ID этого события.

Get-SPLogEvent | Where-Object {$_.EventID -eq 6616}

Пример получения более развернутой информации по одному сообщению:

 Get-SPLogEvent | Where-Object {$_.EventID -eq 6616} | Select-Object -First 1 | Format-List

Как видно их примеров выше – использование PowerShell далеко не самое удобное занятие. Лично мне этот способ показался не очень удобным. Но если бы мне нужна была какая-то аналитическая информация, например, в виде таблицы Excel, то я бы рассматривал PowerShell для её выгрузки.

Заключение

В этой статье мы рассмотрели способы, с помощью которых можно осуществлять просмотр логов SharePoint. Основные инструменты это – EventViewer, ULS Viewer и PowerShell. Каждый из этих инструментов мы рассмотрели наглядно. Рассмотреть все сценарии применения и использования было бы очень не просто. Однако, мы рассмотрели базовые сценарии работы, которые вы можете адаптировать уже под ваши потребности.

Добавить комментарий

Ваш адрес email не будет опубликован.