Идеальное рабочее место администратора системы DIRECTUM #3. Лог-файлы в DIRECTUM.

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

Но для начала вспомним, что мы уже рассматривали:

• Изначальная идея: Идеальное место администратора DIRECTUM - много интересных программ и даже аппаратной части (бубен прилагается), огромное пространство для дисскусий и обмена мнениями.
• #0: Идеальное рабочее место администратора системы DIRECTUM #0. Вводная часть. - небольшое вступление, объясняющее причину создания цикла статей.
• #1: Идеальное рабочее место администратора системы DIRECTUM #1. Скриншоты. - топ программ для создания снимков экрана, чтобы быстро показать ошибку.
• #2: Идеальное рабочее место администратора системы DIRECTUM #2. Запись экрана. - топ программ для записи видео с экрана, чтобы показать порядок действий.

В этот раз у нас будет не топ программ, а исключительно жизненный ответ на вопрос всех новых (а иногда и не очень) администраторов системы DIRECTUM - где лежат лог-файлы?

P.S. Администраторов других систем приглашаем почитать о методах сбора логов и, возможно, реализовать подобную практику в своей системе.

---

Содержание:

• Какие бывают логи?
• Где можно найти информацию по местонахождению логов?
• Можно ли хранить все логи в одном месте?
• Небольшие итоги

 

Какие бывают логи?

В системе DIRECTUM различается 3 основных вида логирования:

1. Обычные текстовые логи, настроенные вручную или записываемые автоматически (фиксируются различного уровня события);

2. Event-логи (стандартные логи Windows)

3. Расширенные трейсы системы (Профайлинг, настроенные вручную логи)

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

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

О логировании можно также почитать в новой статье О плохом и хорошем коде для чайников, часть 3. Загадка о невыполнившемся коде. А ещё в статье Решение по журналированию произвольных событий в Directum. 

Стандартные логи, обычно, настраиваются файлами конфигурации. В большинстве случаев имя файла конфигурации частично или полностью повторяет название компоненты или утилиты, с которой эти логи собираются. Кроме того, обычно бывает несколько уровней логирования, например: DEBUG, INFO, WARN, ERROR и FATAL. В зависимости от детализации, выставленной в конфигурационном файле, можно варьировать вес и полезность логов.

И пара слов про Event-логи - в системе DIRECTUM используется стандартное логирование через Журнал событий. Подробнее о нём можно почитать в интернете, дублировать эту информацию не буду. Только  дам одну из наиболее распространённых ссылок - https://ru.wikipedia.org/wiki/Журнал_событий.

А вот трассировке и профайлингу системы посвящён целый раздел нашей справки: Мониторинг и профайлинг системы. Будет, что почитать на досуге в поисках точек улучшения производительности системы. 

Где хранятся логи?

Итак, мы знаем, какие логи бывают. Но где же их достать? Ответ покажется до невозможности банальным, но наиболее актуальную информацию о том, где хранятся логи, вы можете смотреть в справке системы. А именно вот тут: https://club.directum.ru/webhelp/directum/5.5/index.html?ra_log_faily.htm

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

Как хранить все логи в одном месте?

В нашей системе очень много разных логов, как мы убедились из страницы справки выше (вы ведь её посмотрели, не правда ли?). И каждый запрос логов для администратора превращается в квест какой-нибудь популярной RPG - "Пойди и собери логи отовсюду". Чтобы избежать этого, можно настроить запись логов в единую папку (и, более того, сетевую папку!).

Выполняется это в файле конфигурации, который обычно либо отдельный для нескольких логов (пример: LogSettings.xml для логов клиентской части), либо привязан к определённой компоненте (пример: LogSettings.config для служб ввода и преобразования документов).

Для наглядности сделал табличку с основными, по моему скромному мнению, логами и "конфигами" (файлами конфигурации), которые могут пригодится в повседневной работе:

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

Небольшие итоги

То, что мы рассмотрели в этой статье - лишь вершинка айсберга под названием "Логирование". Много тем осталось, которые тут были затронуты, но остались нераскрытыми. Правильные методы встраивания логирования в код, безопасное хранение логов без вероятности потери, настройка логирования отдельных служб и многое-многое другое. Все они могут быть рассмотрены в отдельных статьях, не важно, в этом цикле или любом другом. И, конечно же, мы ждём таланты для написания таких статей!

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

P.S. Чит-коды в виде фич для быстрого сбора логов очень приветствуются!

---

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

Антон Гончаров:

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

Роман Деменков:

Тут должна быть ссылка на ELK - Проактивное сопровождение СЭД DIRECTUM при помощи ELK Stack от компании ООО МайТэк.