Общие сведения о централизованной службе ведения журнала в Lync Server 2013

 

Последнее изменение раздела: 2013-02-22

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

  • Centralized Logging Service Agent ClsAgent.exe — это исполняемый файл службы, который взаимодействует с контроллером и получает команды, выданные контроллером администратором. Агент выполняется как служба на каждом компьютере Lync Server. Когда агент получает команду, он выполняет команду, отправляет сообщения определенным компонентам для трассировки и записывает журналы трассировки на диск. Он также считывает журналы трассировки для своего компьютера и отправляет данные трассировки обратно контроллеру при запросе. ClsAgent прослушивает команды на следующих портах: TCP 50001, TCP 50002 и TCP 50003.

  • Centralized Logging Service Controller ClsControllerLib.dll является подсистемой выполнения команд для командной консоли Lync Server и для ClsController.exe. CLSControllerLib.dll команды "Пуск", "Остановить", "Очистить" и "Поиск" в ClsAgent. When search commands are sent, the resulting logs are returned to the ClsControllerLib.dll and aggregated. Контроллер отвечает за отправку команд агенту, получение состояния этих команд и управление данными файла журнала поиска по мере их возврата от всех агентов на любом компьютере в области поиска и агрегирование данных журнала в значимый и упорядоченный выходной набор. Сведения в следующих разделах посвящены использованию командной консоли Lync Server. ClsController.exe возможности ограничены подмножеством функций и функций, доступных в оболочке управления Lync Server. Справка по ClsController.exe ClsController доступна в командной строке, введя в каталог по умолчанию C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent.

Взаимодействие ClsController и ClsAgent

Связь между CLSController и CLSAgent.

Команды выдают с помощью интерфейса командной строки Windows Server или командной консоли Lync Server. The commands are executed on the computer you are logged in to and sent to the ClsAgent locally or to the other computers and pools in your deployment.

ClsAgent поддерживает файл индекса всех файлов .CACHE, которые имеются на локальном компьютере. ClsAgent размещает их так, чтобы они равномерно распределялись по томам, определенным параметром CacheFileLocalFolders, и не занимали более 80% места на каждом томе (расположение и процент локального кэша можно настроить с помощью командлета Set-CsClsConfiguration). ClsAgent также отвечает за удаление с локального компьютера устаревших кэшированных файлов журнала трассировки событий (файлов ETL). По истечении двухнедельного срока (этот временной интервал настраивается с помощью командлета Set-CsClsConfiguration) эти файлы копируются в общую папку и удаляются с локального компьютера. Дополнительные сведения см. в описании командлета Set-CsClsConfiguration. При получении запроса поиска условия поиска используются для выбора набора кэшированных ETL-файлов для выполнения поиска на основании значений из индекса, поддерживаемого агентом.

Примечание.

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

Результирующие файлы журналов можно считывать и анализировать с помощью различных средств, в том числе с помощью Snooper.exe и других средств, способных считывать текстовые файлы, таких как Notepad.exe. Snooper.exe входит в состав средств отладки Lync Server 2013 и доступна в виде веб-загрузки https://go.microsoft.com/fwlink/?LinkId=285257.

Как и OCSLogger, централизованная служба ведения журнала имеет несколько компонентов для трассировки и предоставляет параметры для выбора флагов, таких как TF_COMPONENT и TF_DIAG. Централизованная служба ведения журнала также сохраняет параметры уровня ведения журнала OCSLogger.

Самое важное преимущество использования командной консоли Lync Server над командной строкой ClsController заключается в том, что вы можете настраивать и определять новые сценарии с помощью выбранных поставщиков, предназначенных для проблемного пространства, настраиваемых флагов и уровней ведения журнала. The scenarios available to ClsController are limited to those that are defined for the executable.

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

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

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

Важно

Сценарий AlwaysOn не выполняется в развертывании по умолчанию. Этот сценарий необходимо явно запустить. После запуска он будет выполняться, пока не будет явно остановлен, а состояние выполнения будет сохраняться между перезагрузками компьютеров. Дополнительные сведения о сценариях запуска и остановки см. в разделах "Использование запуска для централизованной службы ведения журнала" для записи журналов в Lync Server 2013 и "Остановка для централизованной службы ведения журнала" в Lync Server 2013.

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

Совет

Если в Lync Server отображается проблемный сценарий, начните с вопроса: "Что я уже знаю о проблеме?" При количественной оценке границ проблемы можно исключить большую часть операционных сущностей в Lync Server.
Рассмотрим пример сценария, в котором пользователи не получают актуальные результаты при поиске контактов. Нет необходимости искать проблемы в компонентах мультимедиа, Корпоративная голосовая связь, конференц-связи и ряде других компонентов. Неизвестно только то, где фактически возникла проблема: в клиенте или на стороне сервера? Контакты собираются из Active Directory репликатором пользователей и доставляются клиенту с помощью сервера адресной книги (ABServer). ABServer получает обновления из базы данных RTC (куда их записывает репликатор пользовательских данных) и собирает их в файлы адресной книги, по умолчанию в 1:30. Клиенты Lync Server получают новую адресную книгу по случайному расписанию. Так как вы знаете, как работает процесс, вы можете сократить поиск потенциальной причины проблемы, связанной с данными, собранными из Active Directory репликатором пользователей, abServer не получает и не создает файлы адресной книги или клиенты не загружают файл адресной книги.