Наблюдение — один из наиболее часто упускаемых из виду аспектов работы с фермой SharePoint. Наблюдение позволяет отвечать на вопросы наподобие «Насколько хорошо все работает?» и «Будет ли это работать завтра?».
Важная часть управления любой ИТ-системой — сбор диагностической информации, которой можно воспользоваться при решении проблем или чтобы понять, что творится с системой. Подобно любому Windows-приложению, SharePoint записывает сведения о важных событиях в журналы событий Windows. Эти сообщения содержат информацию о процессах, которые запущены или остановлены, происшедших ошибках и любых других событиях, которые могут коррелировать с событиями, не связанными с SharePoint.
Трассировочные файлы SharePoint
SharePoint записывает трассировочную информацию с помощью системы Unified Logging System (единая система ведения журналов, ULS). ULS — это набор файлов, в которые записывают данные SharePoint и ее службы. Вы можете использовать эти журналы при работе с компонентами собственной разработки, чтобы записывать информацию об их функционировании таким образом, что ее автоматически можно увязать с другими событиями, происходящими на ферме.
SharePoint автоматически создает новый журнальный файл ULS каждые тридцать минут, чтобы ограничить размер каждого файла. Эти файлы, тем не менее, могут оказаться довольно большими. По умолчанию они хранятся в каталоге LOGS в ветви 14. LOGS. Если вы использовали путь для установки, предлагаемый по умолчанию, это будет папка C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS.
Одна из первых настроек, которые выполняются на новой производственной серверной ферме, — перемещение этих файлов на другой жесткий диск на каждом сервере фермы. Диск C критически важен для функционирования ОС. Несмотря на сжатие, файлы ULS могут быстро заполнить диск и вывести систему из строя.
ULS можно и нужно настроить так, чтобы не допустить заполнения дискового пространства ненужными файлами. Вы можете настроить соответствующие параметры в Central Administration (CA) в разделе Monitoring | Configure Diagnostic Logging.
Можно задать, сколько дней следует хранить файлы журналов каждого сервера. По умолчанию это 14 дней. Файлы ULS, которые старше этого количества дней, автоматически удаляются из системы. Если вам нужно запоминать в журналах большие объемы данных или хранить журналы неограниченное время, возможно, будет лучше резервировать и удалять файлы каждые 30 минут, когда каждый файл закрывается и создается следующий файл.
Можно также задать максимальное количество дискового пространства. При достижении этого предела самые старые журнальные файлы автоматически удаляются, чтобы освободить место. ULS-журналы записываются как обычные текстовые файлы, поэтому их можно читать с помощью текстового редактора, например, Notepad. Однако, возможно, что их окажется сложно прочитать напрямую, поскольку они не отформатированы для удобства чтения и могут быть очень большими.
Чтобы упростить работу с этими файлами, Microsoft предлагает ULSViewer — вы можете скачать это приложение. Microsoft не поддерживает ULSViewer, но он будет полезен на мелких и средних фермах SharePoint. Организациям с очень крупными средами SharePoint имеет смысл потратиться на Microsoft System Center или системы управления от сторонних производителей.
Регулирование событий
SharePoint — большая и сложная программная платформа. Поэтому она может генерировать огромное количество трассировочных данных. Чтобы ограничить воздействие ведения журналов со всей этой информацией на вашу среду, можно настроить SharePoint, ограничив сохранение событий в журналах в зависимости от категории события, серьезности события и того, где будет отражаться событие — в журнале событий Window или трассировочном файле ULS.
Категория события описывает, откуда взялось событие и к чему оно относится. Например, Excel Services Application может добавить в журнал событие, связанное с обращением к внешним данным. Можно настраивать каждую категорию по отдельности или вместе с другими типами событий.
Серьезность событий определяет, насколько вероятно, что событие повлияет на остальные элементы системы. Событиям, данные о которых направляются в журнал событий Windows, назначаются следующие уровни серьезности (по возрастанию): Verbose, Information, Warning, Error или Critical. В журналах ULS используются уровни серьезности Verbose, Medium, High, Monitorable и Unexpected.
При настройке ведения журналов событий задайте один из этих уровней в качестве минимального уровня записываемых событий. Например, если вести журнал событий на уровне Information, в журнал будут попадать все события, кроме событий уровня Verbose. Можно настроить отдельный уровень серьезности для каждой категории событий и каждого адресата. Это позволит ограничить количество генерируемой трассировочной информации и, в то же время, запоминать самую важную информацию.
По умолчанию все события с уровнем серьезности Information и выше записываются в журнал событий Windows. События уровня Medium и выше записываются в трассировочные файлы ULS. Эти параметры означают, что записывается значительное количество событий, но трафик, связанный с заполнением журнала событий, минимален. Они подходят для большинства ферм.
Защита от переполнения журналов событий
SharePoint 2010 может предотвращать переполнение журналов событий, приводящее к чрезмерному разрастанию файлов журналов. Переполнение событиями происходит, когда компонент обнаруживает проблему, сообщает о ней и продолжает испытывать ту же самую проблему. В результате журналы событий быстро заполняются. Это даже может привести к смешной ситуации, когда вы теряете исходную причину ошибки из-за того, что журнал событий перезаписал ее сообщениями об ошибках, являющихся побочным эффектом настоящей проблемы.
Чтобы избежать этой ситуации, SharePoint 2010 отслеживает частоту, с которой записывается каждое событие. Если она видит, что одно и то же сообщение записывается более пяти раз в течение двух минут, она отражает этот факт в журнале и прекращает записывать информацию о каждом таком событии. Она будет записывать итоговые данные о событиях каждые две минуты до тех пор, пока поток событий не иссякнет. Тогда она вернется к записи каждого события.
Защита от переполнения журналов событий применима только к журналам событий Windows, но не к трассировочным журнальным файлам ULS. По умолчанию эта функция активна. Ее можно отключить на той же странице, где вы настраивали регулирование событий. Вы также можете задать пороговое количество и период молчания при выявлении переполнения событиями с помощью Windows PowerShell, но не в CA.
Идентификаторы взаимосвязи
Поскольку различные компоненты SharePoint могут генерировать такое огромное количество данных о событиях и трассировочных данных, может оказаться сложным понять, как события связаны между собой. Журналы хранят данные о событиях последовательно, в том порядке, в котором они записаны. Последовательно обрабатываемые запросы могут генерировать события, которые перемешаются в журнале. SharePoint решает эту проблему с помощью идентификаторов взаимосвязи.
Идентификатор взаимосвязи — это GUID, назначаемый каждому процессу SharePoint, создаваемому по запросу. Событие, записанное SharePoint в результате запроса, связывается с идентификатором взаимосвязи этого запроса. Кроме того, идентификаторы взаимосвязи включаются в некоторые сообщения об ошибках, записи журнала событий и другие интерфейсы, такие как Developer Dashboard. Developer Dashboard — это диагностическая панель, которую можно активизировать для отладки, если со страницей SharePoint возникнут проблемы.
База данных журналов SharePoint
В SharePoint 2010 введена еще одна форма профилактического ведения журналов — так называемая база данных журналов SharePoint. Эта база данных собирает различные данные со всех серверов фермы. Благодаря этому вы получаете единый источник информации, и не требуется явно активизировать ведение журналов или комбинировать журнальные файлы.
База данных журналов хранится в базе данных SQL Server с именем WSS_Logging. В этой базе данных множество таблиц, к которым сложно выполнять запросы напрямую. К счастью, Microsoft разработала ряд представлений, упрощающих получение информации из этих таблиц.
Большая часть данных, хранящихся в этой базе, собирается набором заданий, выполняемых по таймеру. Чтобы на новых фермах не происходил неконтролируемый сбор данных, эти задания по умолчанию отключены. Чтобы собирать информацию, предоставляемую этими Diagnostic Data Providers, просто активизируйте в CA задания, выполняемые по таймеру:
- Diagnostic Data Provider: Event Log
- Diagnostic Data Provider: Performance Counters - Database Servers
- Diagnostic Data Provider: Performance Counters - Web Front Ends
- Diagnostic Data Provider: SQL Blocking Queries
- Diagnostic Data Provider: SQL DMV
- Diagnostic Data Provider: SQL Memory DMV
- Diagnostic Data Provider: Trace Log
Имеется несколько категорий информации базы данных журналов, по которой вы можете получать отчеты. В отличие от ULS или журнала событий Windows, эти представления содержат информацию со всех серверов фермы. Эти данные охватывают все содержимое фермы, в том числе диагностическую информацию, информацию о работоспособности и использовании функций:
- Журналы ULS
- Журналы событий Windows
- Счетчики производительности для памяти, ввода-вывода и использования процессора
- SQL Server Dynamic Management Views (DMV)
- Информация об использовании различных функций
- Данные об обходах, выполненных поисковыми службами (search service crawling), и запросов к ним
- Задания, выполняемые по таймеру
Не думайте, что вас всегда будут только имеющиеся на данный момент представления, отражающие данные, доступные в этой базе данных. Когда вы зададите новый тип информации для сбора, в WSS_Logging появятся новые таблицы и представления для работы с этой информацией. Эти объекты базы данных создаются по запросу, когда в них возникает потребность.
Важно помнить, что база данных журналов ведется в дополнение к ULS и журналам событий, а не вместо них. Активизация сохранения больших объемов данных в журналах может привести к тому, что эти данные станут неуправляемыми. Подумайте, какие инструменты использовать для тех или иных целей, и настройте их соответствующим образом. Позаботьтесь о том, чтобы вам хватило пространства для хранения журналов и файлов базы данных, когда вы начнете использовать их в полной мере. Исчерпание пространства для этих журналов может привести к потере критически важной информации в самый неудачный момент.
Информация, содержащаяся в этих таблицах, полезна как для диагностирования проблем, так и для планирования будущих обновлений и расширений функциональности. Эта база данных хранит информацию за достаточно большие периоды, поэтому с ее помощью можно наблюдать за тенденциями в области производительности, интенсивности использования и эффективности поиска.