1с 8 настройки пользователя xml
Важным элементов в расследовании проблем с системой 1С (падение с ошибками, зависание 1С Предприятия, проблемы с производительностью и т.д.) является настройка Технологического журнала.
Технологический журнал предназначен для поиска ошибок, возникающих при эксплуатации информационной системы, и диагностики работы системы службой технической поддержки фирмы «1С», а также для анализа технологических характеристик работы системы.
Технологический журнал является набором текстовых файлов, хранящихся в различных каталогах. За настройку и ведения ТЖ отвечает конфигурационный файл logcfg.xml, в котором описываются:
- каталог, в котором будут сохраняться файлы технологического журнала;
- состав информации, которая будет сохраняться в ТЖ;
- время, в течение которого будут храниться технологического журнала;
- параметры дампа, создаваемого при аварийном завершении приложения.
По умолчанию конфигурационный файл отсутствует. Это означает, что технологический журнал включен и настроен на сохранение минимальных дампов при аварийном завершении приложения в каталог: %USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps
Настройка конфигурационного файла logcfg.xml технологического журнала
Для того, чтобы настроить сохранение логов технологического журнала требуется создать файл logcfg.xml и сохранить его в каталог конфигурационных файлов на сервере 1С, т.е. в тот каталог, в котором у вас установлена система 1С Предприятие, например: C:\Program Files\1cv8\conf
Следует сказать, что наличие конфигурационного файла не является обязательным. Если он отсутствует, то ТЖ считается включенным и имеет следующие настройки по умолчанию:
- Технологический журнал (элемент ) ‑ выключен .
- Технологический журнал по умолчанию (элемент ):
- Формирование ‑ включено .
- Время жизни ‑ 24 часа .
- Уровень формирования событий для всех компонентов системы определен как Error .
- Сохраняется в каталоги:ОС Windows: %USERPROFILE%\Local Settings\1C\1cv8\logs ( %LOCALAPPDATA%\1C\1cv8\logs для ОС Windows Vista и выше).
- Сохраняются минимальные дампы аварийного завершения работы системы ( type="1" ).
- Дампы сохраняются в каталог %USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps ( %LOCALAPPDATA%\1C\1cv8\dumps для ОС Windows Vista и выше).
Структура конфигурационного файла
Корневым элементом конфигурационного файла является элемент , который определяет настройки технологического журнала. Он может содержать несколько элементов , один элемент , один элемент , один элемент , один элемент , один или несколько элементов
- Элемент определяет каталог технологического журнала и его состав
- Элемент определяет каталог для записи дампов аварийного завершения
- Элемент устанавливает отслеживание утечек памяти, которые могут быть вызваны ошибками в коде конфигурации. Отслеживание утечек памяти несколько снижает производительность.
- Элемент предназначен для учета используемой памяти
- Элемент plansql> предназначен для управления сбором планов запроса, формируемых при работе различных СУБД. Собственно планы запросов содержатся в свойстве событий, связанных с СУБД.
- Элемент dbmslocks> предназначен для управления сбором информации о блокировках СУБД
- Элемент предназначен для управления сбором информации о процессах обновления индекса полнотекстового поиска
- Элемент query> управляет помещением в технологический журнал информации о полях, содержащих NULL при исполнении запроса к внешнему источнику данных, но для которых такое значение не допускается
- Элемент предназначен для управления сбором информации об использовании механизма ввода по строке.
- Элемент управляет работой механизма отслеживания информации о циклических ссылках во время выполнения встроенного языка
- Элемент определяет каталог и время жизни технологического журнала по умолчанию
- Элемент определяет настройки формирования системных событий
Остановимся на ключевых элементах конфигурационного файла.
ЭлементЭлемент определяет каталог технологического журнала и условия отбора, по которым в технологический журнал помещаются ранее сформированные события.
Важно! Крайне не рекомендуется использовать более 20 элементов - это может привести к значительному замедление работы системы 1С Предприятие.
- Атрибут location - Имя каталога, в котором будет размещаться технологический журнал.
- Атрибут history - Количество часов, через которое информация будет удаляться из технологического журнала.
Набор элементов определяет условие, при выполнении которых события будут записываться в журнал. В ТЖ помещаются только события, которые удовлетворяют условию.
Доступны следующие имена событий:
Условия задаются элементами:
- eq‑ равно;
- ne‑ не равно;
- gt‑ больше;
- ge‑ больше или равно;
- lt‑ меньше;
- le‑ меньше или равно;
- like‑ соответствие маске.
Примеры настройки технологического журнала
Может показаться, что настройка технологического журнала достаточно трудная операция, но на самом деле в большинстве случаев достаточно использовать выполнить следующие простые шаги:
- Создать каталог на сервере для хранения логов технологического журнала
- Создать файл logcfg.xml или скачать готовый. Примеры содержания данного файла вы найдете ниже. Указав в данном файле каталог, созданный на шаге 1
- Сохранить этот файл на сервере в конфигурационный каталог, куда установлена система 1С. Например: C:\Program Files\1cv8\conf
Полный технологический журнал
После сохранения журнала не забудьте указать свой каталог в атрибуте location. Т.е., следует заранее создать каталог и заменить в строке
Настройки, приведенные выше позволят сохранить все события со всеми свойствами, при этом журнал будет сохраняться 168 часов (одна неделя). Важно понимать, что объем выводимой информации будет очень большим, поэтому не рекомендуется использовать данные настройки в рабочих системах на постоянной основе, однако это может быть весьма полезно на этапе внедрения или при расследовании ошибок. Для рабочих систем следует остановиться на приведенных ниже вариантах.
Ошибки системы и действия администратора
Данный конфигурационный файл создает технологический журнал относительно небольшого объема, в котором содержится информация о запуске и завершении приложений, установке и разрыве соединений с кластером серверов «1С:Предприятия», действиях администратора кластера и об ошибочных ситуациях в работе 1С:Предприятия. Такой журнал в большинстве случаев достаточен для расследования ошибочных ситуаций как в конфигурации, так и в технологической платформе 1С.
Для удобства вы можете скачать данный файл по ссылке.
Ограничение по времени выполнения
Приведенный выше файл аналогичен предыдущему пункту, но добавляет все операции, длительность которых превышает 10 секунд. Это может оказаться полезным для обнаружения действий пользователей, которые выполнялись длительное время, с целью, например, их последующей оптимизации. Длительность событий выражается в сотнях микросекунд.
Если программа ведет себя неправильно, то первым делом следует смотреть логи. 1С:Предприятие не исключение, однако, в отличие от большинства иных программ, использующих для этого системные инструменты, 1С реализовали собственный механизм, названный технологическим журналом. Он позволяет достаточно гибко настраивать собираемую информацию и способен удовлетворить различные категории пользователей: от администраторов до разработчиков.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.
Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:
В дампах могут разобраться только разработчики платформы! (только у них исходники :) )
Поэтому сразу забываем о дампах и сосредотачиваемся на гораздо более простых и понятных вещах - логах. Для чтения логов не нужно иметь специфических знаний, достаточно просто инженерного опыта и общих представлений о работе операционной системы и непосредственно 1С:Предприятия.
Платформа Windows
Для включения и настройки технологического журнала в среде Windows необходимо в папке C:\Program Files (x86)\1cv8\conf создать специальный файл настроек logcfg.xml. В самом простейшем случае он может выглядеть так:
Разберем структуру файла подробнее:
- log location - расположение файлов лога, указанная директория должна существовать, и пользователь от имени которого запускается 1С должен иметь право записи в нее.
- history - время хранения логов в часах, в нашем примере 168 часов равно 7 суткам или неделе.
- event - таких секций может быть много, соответствуют фиксируемым событиям. В данном случае фиксируются все события.
- property - определяет попадание в журнал свойств событий. Конструкция property name="all" включает записи в журнал всех свойств событий.
Данная настройка может подойти для клиентского приложения, однако попытка использовать ее на сервере приведет к резкому раздуванию логов и падению производительности системы.
Внимание! 1С категорически не рекомендует включать подобный тип журнала на рабочих серверах!
Поэтому настроим журнал на получение только нужной нам информации. Существуют разные варианты настройки технологического журнала, в зависимости от того, какие именно события нас интересуют. В первую очередь это нештатное поведение платформы, которое может быть связано с ошибками конфигурации или неправильной настройкой платформы. Фирма 1С рекомендует такую настройку журнала:
В данном примере фиксируются следующие события:
- PROC - события, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например, старт, завершение, аварийное завершение и т.п.
- SCOM - события создания или удаления серверного контекста, обычно связанного с информационной базой.
- CONN - установка или разрыв клиентского соединения с сервером.
- EXCP - исключительные ситуации приложений системы 1С:Предприятие, которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса.
- ADMIN - управляющие воздействия администратора кластера серверов системы 1С:Предприятие.
- QERR - события, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных.
Этого набора вполне хватает, для разбора ошибок в повседневной деятельности администратора. С полным перечнем настроек технологического журнала с пояснениями и примерами можно ознакомиться в разделе 3.17 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).
Для диагностики отдельных ситуаций можно применять и специфические настройки журнала. Если вы используете аппаратные ключи, то в случае возникновения проблем с ними примените следующую настройку журнала:
Итак, файл создан. Чтобы события начали фиксироваться в журнале необходимо запустить клиентское приложение или перезапустить службу сервера. После чего директория с логами примет примерно следующий вид:
Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.
Для примера приведем участок лога:
Платформа Linux
Несмотря на то, что никаких отличий в настройке технологического журнала для разных платформ нет, в Linux имеются некоторые особенности, связанные с архитектурой системы и не всегда очевидные начинающим.
Прежде всего расположение файла настроек. Он должен находиться в /home/usr1cv8/.1cv8/1C/1cv8/conf, по умолчанию данная директория не существует и ее нужно будет создать. Также, если вы предпочитаете графические инструменты настройки, учтите, что директория .1cv8 скрытая (на это указывает точка в начале имени) и просто так в файловом менеджере вы ее не увидите.
Мы предпочитаем работу в консоли, как более привычную и удобную для данной платформы. Поэтому создадим данную директорию:
а в ней файл настроек:
После чего можно приступать к его редактированию, содержимое должно быть полностью идентичным Windows-версии, за исключением пути хранения логов. В файловой системе Linux они традиционно располагаются в /var/log и мы не рекомендуем отступать от традиций, потому, что если с данным сервером придется работать другому специалисту, то он будет искать логи именно там.
Изменим строку конфигурационного файла logcfg.xml следующим образом:
Затем создадим папку для логов 1С
А чтобы 1С могла писать туда, установим пользователя и группу 1С владельцем этого каталога:
Теперь перезапускаем процесс сервера 1С
и отмечаем создание в директории папок и файлов с логами.
Данная настройка будет вести технологический журнал сервера 1С, если вам нужно фиксировать события клиентского приложения, то следует выполнить ряд дополнительных действий.
Так как клиентская платформа работает от имени запустившего его пользователя, то файлы настройки платформы хранятся в домашнем каталоге этого пользователя. Если таких пользователей несколько, то у каждого из них будет свой вариант настроек. Структура каталогов при этом полностью повторяет серверную, что не удивительно, в случае с сервером настройки хранятся в каталоге служебного пользователя от имени которого работает сервер 1С.
Если посмотреть этот каталог, то увидим, что там кроме папки conf, присутствует также папка logs, в которой создаются папки для запущенных процессов, однако самих логов там нет.
Попытка использовать для записи логов эту папку не приведет к успеху, папки процессов будут создаваться, но логи появляться не будут. Можно, конечно, перенастроить место хранения логов на любую папку в домашней директории, но лучше продолжить использовать для этого /var/log/1C.
Чтобы запущенное от имени пользователя приложение могло писать в данную папку надо предоставить ему соответствующие права. Если вы единственный пользователь компьютера и серверной версии 1С у вас не установлено, то можно просто сделать текущего пользователя владельцем данной папки, если пользователей несколько, либо на этом же ПК стоит серверная часть и вы хотите включить журнал и для нее, то нужно настроить совместный доступ.
Прежде всего добавим нужных пользователей в группу 1С:
Затем изменим права на папку логов, чтобы писать в нее мог не только владелец, но и группа:
Для применения прав нужно завершить сеанс пользователя и войти заново, после этого можно запустить клиентское приложение и убедиться, что в каталоге /var/log/1C создаются нужные папки логов.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Технологический журнал представляет собой совокупность каталогов и текстовых файлов, в которые различные приложения 1С:Предприятия могут записывать информацию о работе некоторых внутренних механизмов платформы. Состав выводимой информации определяется конфигурационным файлом технологического журнала, который имеет название logcfg.xml и должен быть помещен в подкаталог conf каталога загрузочных модулей 1С:Предприятия. В этом файле средствами XML определяются условия вывода в технологический журнал событий и их свойств. Если файл logcfg.xml отсутствует, не содержит ни одного элемента log, или содержит ошибки, то технологический журнал считается выключенным и не создается. При выключенном технологическом журнале производительность 1С:Предприятия несколько выше, чем при включенном.
В приведенных ниже примерах предполагается, что 1С:Предприятие установлено стандартным способом и его загрузочные модули расположены в каталоге C:\Program Files\1cv82\bin.
Важно иметь в виду, что в каталог технологического журнала при некоторых его настройках могут выводится данные очень большого объема. Поэтому на диске, где будут храниться данные журнала регистрации, должно быть достаточно места. Для работы технологического журнала необходимо, чтобы пользователи, от имени которых запускаются приложения 1С:Предприятия (как клиентские, так и серверные), имели полные права на каталог технологического журнала (D:\1cv82\logs), и право на чтение выше лежащего каталога (D:\1cv82).
ВНИМАНИЕ ! Необходимо иметь в виду, что каталог технологического журнала не предназначен для хранения в нем файлов, которые не относятся к технологическому журналу. Поэтому не следует размещать в нем дампы или использовать каталог, который может содержать файлы, не относящиеся к технологическому журналу «1С:Предприятия». Если в каталоге, который указан в качестве каталога
технологического журнала, имеются посторонние файлы, то указание каталога считается неверным, и технологический журнал не создается.Система «1С:Предприятие» автоматически, с периодичностью 60 секунд, опрашивает каталоги конфигурационных файлов на предмет наличия файла logcfg.xml и анализирует его состав. Таким образом, изменение параметров технологического журнала может быть выполнено на ходу, без перезапуска работающих приложений системы «1С:Предприятие».
Далее приведены несколько примеров файлов logcfg.xml, содержащих наиболее часто используемые конфигурации технологического журнала.
Технологический журнал выключен
Если файл logcfg.xml отсутствует или имя файла не равно «logcfg.xml» (например logcfg_1.xml)в каталоге C:\Program Files\1cv82\bin\conf, то технологический журнал не создается. Если файл logcfg.xml необходим для правильной настойки дампов, то он не должен содержать ни одного элемента log.
Следующий пример определяет необходимость построения полного дампа приложения при его аварийном завершении. Дампы помещаются в каталог: D:\1cv82\dumps.
Полный технологический журнал
Приведенный ниже конфигурационный файл определяет вывод в технологический журнал всех событий вместе со всеми свойствами. Журнал будет сохраняться в течении 2 суток (48 часов). Объем выводимой информации при этом будет очень большим, однако, она может быть полезна при анализе сложных нештатных ситуаций. Данную конфигурацию рекомендуется использовать на этапе тестирования и при расследовании ошибок.
Обращения к СУБД
Следующий конфигурационный файл определяет, что технологический журнал будет содержать только обращения 1С:Предприятия к СУБД, а так же информацию об ошибочных ситуациях. Объем выводимой информации меньше, чем при полном технологическом журнале, но тоже может быть очень большим.
В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.
- Простая установка и настройка - за 15 минут рабочее решение для "неограниченного" количества баз
- Ничего лишнего и никакой "магии" - используются возможности платформы
- Дружественный интерфейс - только то что нужно
- Информация в реальном времени - ошибки конфигурации, блокировки, длительные запросы и др.
- Бесплатно - проект с открытым исходным кодом на GitHub
В первой части статьи мы приводим список и описание из 5 шагов для самостоятельного выполнения процедуры. Если же Вам лень читать и Вы любите смотреть и слушать, то можно перейти к видео-уроку и посмотреть небольшой 5 минутный ролик по выполнению необходимой последовательности действий и повторить при необходимости.
Совет. Боевую базу мониторинга лучше всего развернуть на отдельном сервере, по крайней мере на отдельном кластере.
2. Определим цели и задачи
Что мы будем мониторить? Проблемные ситуации влияющие в целом на производительность и работоспособность базы:
Вы можете использовать эти или добавить/выработать другие критерии. Ситуации, которые описаны говорят сами за себя и расшифровывать их не будем.
Зачем будем мониторить? Для возможности проведения анализа проблемных ситуаций возникающих при работе базы и последующему их исправлению. Ознакомлен - значит вооружен.
3. Настроим технологический журнал (ТЖ) для 1С
Давайте настроим конфигурационный файл для технологического журнала всех указанных случаев. Эту операцию настроим вручную с использованием Notepad++. Однако вы всегда можете воспользоваться специальной обработкой с ИТС для настройки этого файла.
Каждую проблемную ситуацию будем выгружать в отдельный каталог и обрамляется она тегом "log" (примерный исходный код файла приведен ниже). Эти каталоги должны быть видны с сервера где развернута наша конфигурация - можно сделать общий каталог.
Созданный файл "logcfg.xml" копируем в папку с установленным предприятием 1С боевого сервера (обычно куда-то по похожему пути: "c:\Program Files\1cv8\8.3.12.1855\bin\conf\").
Пример файла "logcfg.xml":
Совет. Обязательно ставьте фильтры для настроек технологического журнала. Никогда не сохраняйте всё подряд. Для рассматриваемого примера нам важны только проблемные ситуации, а не весь стек всех возможных событий.4. Настроим базу мониторинга
Теперь перейдем к настройке самой базы мониторинга. Наши логи уже начали формироваться, т.ч. продолжим.
- Создаем в справочнике "Замеры" три замера с наименованиями по ситуациям: блокировки, долгие запросы и ошибки;
- Указываем путь к соответствующим каталогам;
- Ставим флаг "загружать в реальном времени" - означает, что данные будут подгружаться автоматически регламентным заданием;
- Ставим флаг "загружать автоматически" и указываем интервал загрузки 5-10 минут - будет загружаться по регламентному заданию;
- Детализируем расписание загрузки лога.
После создания замеров с указанными параметрами загрузка логов технологического журнала будет выполняться автоматически (по регламентному заданию для каждого замера).
Совет. Вы можете для каждого замера указать фильтры загрузки данных из логов, чтобы ограничить количество и качество поступаемой информации (дополнительно к настройкам logcfg.xml). К примеру, игнорировать события не подлежащие анализу - обрывы соединений и т.п.
5. Запустим и проверим
Фактически все необходимые операции мы выполнили и теперь можно проверить что получилось.
Для анализа ситуации у нас имеются следующие обработки:
1. Журнал событий замеров. Позволяет просматривать список событий в временной последовательности с отборами и сортировками.
2. Рабочее место по изменению количества событий. Позволяет сравнить изменение количества событий на временной относительной оси по двум временным окнам, к примеру, сравнить среду и вторник текущей недели или разных.
Совет. Для изменения состава отображаемых колонок (добавить новые поля через ссылку, которых нет изначально) в динамическом списке пользуйтесь возможностью "изменить форму" через "еще".
Видео-урок.
В этом видео-уроке мы с вами установим конфигурацию "Анализ ТЖ", проведем необходимые настройки и посмотрим результаты на примере искусственных ситуаций.
Дополнительно.
Подключиться к проекту или его скачать вы можете с git-hub репозитория polyplastic Решение проблемы быстродействия в ERP на рабочем примере. Также в этой статье приводится методика пример выполнения задачи оптимизации проблемного участка для базы 1С.
Есть ли аналоги? К аналогам в какой-то мере можно отнести: Notepad++ и другие механизмы полу-ручного анализа; ЦУП от 1С из Корпоративного инструментального пакета.
Исправления и анализ проблемных ситуаций.
Проблемы исправляются в зависимости от проведения анализа и дальнейшей классификации. К примеру, выявленные ошибки можно классифицировать по следующим уровням:
- ошибки разработчика - ошибки вызванные результатом деятельности разработчиков. Локализуются, формируются задачи на исправления через систему баг трекинга и исправляются последующими релизами;
- ошибки системные - ошибки вызванные проблемами окружения: доступ, отсутствие сети, проблемы внешних ресурсов, недостаток места на диске или выделенной памяти и др. Локализуются и в зависимости от возможности исправления формируются задачи на их устранение.
Наличие "долгих" запросов сообщает о проблемах в производительности базы данных. Для их анализа и наличия можно воспользоваться журналом "свойства замеров" с сортировкой по длительности и фильтром за сегодня. Их можно классифицировать
- проблемы rls - вызваны сложными ограничениями и/или не верным назначением прав доступа;
- проблемы запроса - не правильный запрос, который стоит оптимизировать;
- проблемы производительности - проседание мощности в часы пик или по другим подобными причинам.
Наличие конфликта блокировок говорит об наличии определенных ситуациях в базе приводящих к отказам в действиях пользователей. Их рост во временном интервале может свидетельствовать о грядущих проблемах, который может быть связан с ростом пользователей, проблемами архитектуры и требует незамедлительных мероприятий по устранению. Провести анализ ситуации во времени можно с помощью рабочего места "анализ".
Специальные предложения
(7) эти команды можно и на винде выполнить. И не всегда красивые графические кнопочки и таблички - значит гибко, быстро и эфективно
(1) анализ от Группы Гилева - анализ Тех.Журнала,
а так же Анализы: Длительных запросов, Блокировок, Взаимо-блокировок
всё там есть. и давно(0) используется только технологический журнал?
Просто ведь без магии иногда не обойтись, потому что ни план запроса через ТЖ без последствий нормально не получить, ни причины замедления запроса и др.
За труды спасибо, плюс поставил.
(2)
1. Проект развивается. На текущий момент доступен такой функционал.
2. В вашем случае мы используем дополнительно другие инструменты и методики для поиска сопоставления запроса с точкой в конфигурации (когда не понятно).(3) спасибо за инструмент еще раз.
Попробую на досуге.
А есть ли возможность сделать внутри аналитической базы фильтра(отбора/группировки) по Иинформационной базе/Серверу1С/СерверуSQL/Пользователю т.е. архитектура конфигурации подразумевает что под каждую ИБ/Сервер нужно заводить отдельную ИБ анализа ТехЖурнала и уже в каждой настраивать общий доп фильтр по ИБ/Серверу или я что-то не так понял?
Жалко нет скриншота с возможными настройками, непосредственно связанными с анализом разобранного тех журнала
И ещё резонный вопрос - как это всё хранится - скажем, если тех журнал весить в тексте 1Gb то сколько он будет весить в такой аналитической базе (с учётом того, что всё что есть в тех журнале - загружается в базу).
Понятно, что объёмами тех журнала в 1Gb даже в день никого не удивишь и не шокируешь - но в больших базах, в час, тех журналы, ежедневно, бывают и по 10Gb на сервер/ИБ, а уж в периоды сдачи отчётности или под НГ могут быть и по 100Gb в час - даже если в них писать только самое важное - итого - у крупных организаций с кучей баз это будут, в пике, уже десятки терабайт в сутки! Даже если хранить это всё не более суток, как с этим объёмом справится данная аналитическая база? Компактность хранения, фильтрации, и насколько эффективно идёт разбор таких больших логов?Да и, смотрю, нет никакой защиты от чрезмерного роста объёма данных - а желательно бы - на кризисный случай: т.е. хотя бы ограничить не только сроком хранения, а, скажем, числом записей тоже (причём, хорошо иметь не только общий максимум, но и отдельно - по каждой ИБ).
(8)
1. Удаление старых событий или "нет никакой защиты от чрезмерного роста":
- Есть константа "УдалятьУстаревшиеСобытия" и регламентное задание "УдалениеУстаревшихСобытий".
- Для замеров есть параметр Глубина Хранения - при условии не равном "0" данные будут очищаться.2. "..журнал весить в тексте 1Gb.." - ставьте фильтры на собираемые данные. Для действительно полезных данных объемы значительно меньше!
Замер для каждого сервера отдельно, у вас не получится писать в одну папку на диске разным серверами 1С.
Базу для каждого сервера не обязательно создавать - вы создаете замер под каждый каталог, к примеру, "замер для сервера1 по ошибкам", "замер для сервера 2 по блокировкам", "замер для сервера 3 только для базы ERP по длительным запросам" и т.п.4. Если у вас возникнут идеи по "фитчам", то пишите в issues, а еще лучше подключайтесь)
К примеру, можно добавить справочник сервер и сделать его реквизитом замера.5. Анализ разобранного журнала это отдельная сложная задача и не входит в рамки этой промо-статьи. Для разных ситуаций оптимальны разные наборы колонок и отборов. В дальнейшем приведем еще некоторые примеры использования - все зависит от востребованности данного инструмента коллегами.
Технологический журнал — это средство логирования действий платформы происходящих на самом низком уровне. Данные предоставляемые технологическим журналом позволяют выявить причины «тормозов», зависаний, утечек памяти и «падений» рабочих процессов.
Общая информация
Технологический журнал является основным источником информации для всех инструментов анализа производительности платформы.
Ведение технологического журнала возможно как для сервера, так и для клиентских приложений. Так как клиентские логи и дампы, за редким исключением, не представляют практического интереса, вопрос мы будем рассматривать только со стороны сервера. Тем не менее, все сказанное ниже, будет верно и для клиента.
Технологический журнал может продуцировать два вида информации:
Включение технологического журнала
По умолчанию технический журнал включен и работает, дампы хранятся здесь:
%LOCALAPPDATA%\1C\1cv8\dumps (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\dumps )
%LOCALAPPDATA%\1C\1cv8\logs (пример: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs )
USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.
Собираемая таким образом информация минимальна — формируются дампы минимального размера при аварийном завершении работы рабочих процессов, а в логи попадают только события SYSTEM с уровнем Error.
В большинстве случаев этой информации недостаточно, следовательно нам необходимо самостоятельно указать какую информацию мы хотим видеть в логах. Для этого необходимо создать файл настроек тех. журнала (об этом ниже) с названием logcfg.xml и разместить его в одной из подходящих директорий.
Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:
Если настроить нужно конкретную версию, то здесь (зависит от версии):
Иногда может потребовать включить тех. журнал для конкретного пользователя, из под которого запущен сервер 1С, в этом случае файл настроек следует разместить тут:
Перезагружать сервер не требуется, настройки считаются и будут применены не более чем через 60 секунд. Выключить тех. журнал еще проще — нужно переместить или переименовать файл настроек.
Создание файла настроек
Теперь перейдем к содержимому файла настроек logcfg.xml.
Читайте также: