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

Опубликовано:
31 мая 2018 в 16:39
  • 6

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

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

В этот раз у нас будет не топ программ, а исключительно жизненный ответ на вопрос всех новых (а иногда и не очень) администраторов системы 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 от компании ООО МайТэк.

6
Подписаться

Комментарии

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

Антон, спасибо большое за комментарий! И вправду, очень удобная функция Event Viewer, о которой не было информации в статье. Внёс информацию в саму статью, теперь-то уж точно не потеряется. 

Кстати, по настройке ещё вот есть такая интересная статья на хабре: https://habr.com/sandbox/19414/. Тоже будет полезной для ознакомления.

Статьи на клабе по теме:

Полезный сценарий, чтобы лог-файлы не переполнялись

Парсим логи DIRECTUM

Все о лог-файлах DIRECTUM

Елена Питомцева: обновлено 04.06.2018 в 07:56

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

Как вы можете заметить - все эти статьи были написаны в далёких 2010-2012 годах. А это уж 6 и более лет прошло. Пора было вспомнить, что у нас есть и как этим удобно пользоваться, где-то просто актуализировать информацию. 

Тут должна быть ссылка на ELK.

Роман, спасибо большое за информацию и ссылку! Да, и вправду, Проактивное сопровождение СЭД DIRECTUM при помощи ELK Stack - это одно из очень интересных решений от наших партнёров, которое тоже позволяет держать логи в чистоте и порядке. Добавил эту информацию в основной текст статьи, чтобы она всегда была на виду.

Авторизуйтесь, чтобы написать комментарий