SharePoint 2010: Наблюдение за SharePoint

Наблюдение — один из более нередко упускаемых из виду качеств работы с фермой SharePoint. Наблюдение позволяет отвечать на вопросы наподобие «Насколько отлично все работает?» и «Будет ли это работать завтра?».

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

Трассировочные файлы SharePoint

SharePoint записывает трассировочную информацию при помощи системы Unified Logging System (единая система ведения журналов, ULS). ULS — это набор файлов, в которые записывают данные SharePoint и ее службы. Вы сможете использовать эти журнальчики при работе с компонентами своей разработки, чтоб записывать информацию об их функционировании таким макаром, что ее автоматом можно увязать с другими событиями, происходящими на ферме.

SharePoint автоматом делает новый журнальный файл ULS каждые 30 минут, чтоб ограничить размер каждого файла. Эти файлы, все же, возможно окажутся достаточно большенными. По дефлоту они хранятся в каталоге LOGS в ветки 14. LOGS. Если вы использовали путь для установки, предлагаемый по дефлоту, это будет папка C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14LOGS.

Одна из первых опций, которые производятся на новейшей производственной серверной ферме, — перемещение этих файлов на другой жесткий диск на каждом сервере фермы. Диск 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 выслеживает частоту, с которой записывается каждое событие. Если она лицезреет, что одно и то же сообщение записывается более 5 раз в течение 2-ух минут, она отражает данный факт в журнальчике и прекращает записывать информацию о каждом таком событии. Она будет записывать итоговые данные о событиях каждые две минутки до того времени, пока поток событий не иссякнет. Тогда она возвратится к записи каждого действия.

Защита от переполнения журналов событий применима только к журнальчикам событий 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 и журнальчикам событий, а не заместо их. Активизация сохранения огромных объемов данных в журнальчиках может привести к тому, что эти данные станут неуправляемыми. Задумайтесь, какие инструменты использовать для тех либо других целей, и настройте их подходящим образом. Похлопочите о том, чтоб вам хватило места для хранения журналов и файлов базы данных, когда вы начнете использовать их полностью. Исчерпание места для этих журналов может привести к потере критически принципиальной инфы в самый плохой момент.

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.