Технологический журнал 1с запросы

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

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

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

У этой статьи нет цели дать полное описание всех свойств инструментов.

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

Существует много способов анализа технологических журналов, нет цели рассказать о них всех.

Хочется показать один способ, который добавит мотивации в изучении инструментов.

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

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

Как мне настроить технологические журналы и проделать то, что написано в статье

Технологические журналы настраиваются в файле logcfg.xml

Для отработки материала в данной статье вам понадобится

– клиент-серверный вариант технологической Платформы 1С:Предприятие (примеры готовились на примере 8.3.10)

– СУБД (примеры готовились для MS SQL Server)

– информационная база, как вариант, СНТ, входящий в Корпоративный Инструментальный Пакет

На рабочем сервере настраиваем технологический журнал в файле (logcfg.xml)

Это полный журнал, который будет собираться в директорию "C:LOGSFULL".

Если вы это делаете на рабочих серверах, то следите за местом. (Лучше, конечно, не настраивать полный журнал, а указывать только те события, которые нужны для анализа вам сейчас.)

Для целей этой статьи нам нужен полный журнал.

Подробнее об инструментах

Речь пойдет сначала об "утилитах" bash/sh.

Для пользователей linux не нужно практически ничего, они уже имеют "утилиты".

Для пользователей windows существуют варианты:

– c windows 10 есть встроенный bash (пока в beta-версии) (https://msdn.microsoft.com/en-us/commandline/wsl/about)

– есть инструмент cygwin (https://www.cygwin.com/)

– есть git bash (который в своей поставки содержит всё нужное) (https://git-scm.com/)

Авторы в os windows предпочитают использовать git bash, т.к. по сути его запуск и подготовка к использованию сводятся к клику правой кнопкой мыши в директории с журналами и выбором кнопки git bash here.

Все примеры в этой статье приводятся из расчета, что автор

– либо выполнил cd C:LOGSFULL (или аналогичный путь у вас)

– либо запустил в windows git bash here в директории "C:LOGSFULL"

Т.е., если выполните pwd, вы увидите директорию "C:LOGSFULL"

Для знакомства также рекомендуется книга Скотт Граннеман «Linux Необходимый код и команды Карманный справочник»

Также рекомендуем книгу Джеффри Фридл «Регулярные выражения»

Первые шаги

Хочется очень коротко озвучить приемы, которые применяются периодически для решения простейших микро-задач (посмотреть какие файлы в директории и т.п.).

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

(В целом, последнее замечание касается всей статьи).

Команды и утилиты

Копирование с удаленной машины server

Удалить всё, включая поддиректории, без подтверждения

Список файлов в порядке «последние использованные – снизу» с информацией о правах и времени их модификации

Только список в одну колонку

Только список в строку

Найти файлы по имени в текущей директории

Найти файлы по размеру больше 10 Мб от корня файловой системы

Найти файлы, старше 21:40 04.05.2017 (текущего года)

Просто вывести file

Вывести и пролистать file

Вывести первые 10 строк файла file

Вывести первые N

Вывести последние 10

Вывести последние N

Следить за изменениями в файлах и выводить каждую секунду обновления:

Вывод строк, включающих соответствия выражению, из входного потока

Поиск во всех подкаталогах

Вывод только совпадающего фрагмента

Вывод только совпадающего фрагмента с использованием perl конструкций

Вывести 5 строк до и после найденного выражения

Вывести совпадения, но не выводить имена файлов и пути

Вывести только определенное поле, например, Client > от строк, совпадающих с (не выводя всю строку).

Например, выражение – ",EXCP,"

Поиск по журналам rphost за определенный час (12 часов)

sed и perl

Вывести содержимое файла и заменить GUID-ы, адреса и номера портов на короткие имена:

Убрать всё с начала строки до выражения:

Убрать всё с выражения до конца строки:

Автор считает более удобным применять конструкцию

в качестве альтернативы sed. Это вопрос предпочтений и незначительного выигрыша в производительности и удобстве.

Применить более одного раза (для всех вхождений):

Например, получить сумму по 2-ой колонке, если разделитель ;

Разделителем может быть даже слово

Группировка по входным данным (группируемое поле – $1, суммируется – $2)

Простые реальные примеры

Вывести top 10 совпадений с именами файлов, содержащий текст «Lock request timeout»

Выводить все события "исключения", возникающие сейчас в работающих процессах rphost

Вывести последние 10 событий фиксации или отката транзакции в журналах всех процессов rphost, длительностью более 20 секунд

Для удобства чтения

В статье будет применяться прием, используемый для удобства чтения.

В bash перенос строки обозначается символом

Т.е. по сути однострочная программа

может выглядеть и выполняться в таком виде

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

однако вряд ли вы его будете применять на практике (автор не применяет).

Оптимизация

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

Читайте также:  Чем очистить известковый налет в стиральной машине

Для того, чтобы программы выполнялись быстро, следует пользоваться правилами:

– Постараться как можно ближе к началу отобрать необходимый объем строк;

– Не оперировать миллионами строк;

– Помнить, что сортировки на сотнях тысяч строк могут быть дорогими.

Вы можете воспользоваться утилитой time для получения реального времени выполнения программы.

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

Поэтому в этом случае можно сразу после первого pipe | добавить head, тем самым отобрав только 10 строк.

Если программа на 10 строках работает ожидаемо, то возможно, ожидаемое вами поведение сохранится и на большем числе строк (все зависит от вас).

Фильтрация событий технологического журнала Платформы

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

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

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

Таким образом, ключевыми стали:

– преобразование события к одной строке

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

– фильрация "утилитами" в привычном построчном режиме

– преобразование "обратно" к многострочному варианту после необходимых фильтраций

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

Альтернативным способом преобразования события к однострочному и обратно к многострочному выводу является способ с помощью awk

Естественно, есть и другие способы.

Применение теории

Приведенные примеры позволяют решить поставленные задачи в течение буквально "пары минут", имея "в руках" только технологический журнал и "инструменты bash".

Найдем 5 наиболее длительных транзакций.

Шаг 1. Получим только фиксации и откаты транзакций

Шаг 2. Получим все свойства события полностью

Шаг 3. Оставляем события в одну строку (убираем "обратное" преобразование к многострочному варианту)

Шаг 4. Оставим только нужные поля.

– Например, длительность и первую строку контекста.

– Например, длительность и последнюю строку контекста.

В конструкции ‘s/^d+:d+.d+-//g’ мы избавились от полей до длительности события, чтобы в дальшейшем можно было удобно группировать.

Шаг 5. Пробуем применить группировку с помощью awk

Найдем 5 наиболее длительных запросов к СУБД MS SQL Server.

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

Но проблема в том, что не все события DBMSSQL имеют контексты.

Поэтому группировка по первой или последней строке контекста не подойдет.

Нужно научиться группировать тексты запросов.

Однако в них могут быть числовые параметры, различные имена временных таблиц (#tt17, #tt56), когда структура таких таблиц по сути одинаковая.

Таким образом, нам нужно научиться сворачивать тексты запросов так, чтобы "уникальные" имена пропали.

Для тренировки явно добавим опцию

исключения Context в нашу программу, хотя, понятно, что самые длительные запросы будут только среди запросов без контекста из-за использования grep -v ‘Context’ .

Но так проще для тренировки.

Шаг 1. Получаем запросы без контекстов.

Шаг 2. Можно убрать GUID и имена временных таблиц, номера строк и цифры.

Найдем 5 наиболее длительных вызовов.

В целом задача не отличается от предыдущих.

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

На самом деле он немного мешает. Решим задачу и изменим немного вывод awk:

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

Используем тот же прием.

Однако, теперь нас интересует поле Regions.

Также обращаем внимание, что нас интересует не все события TLOCK, а только те, в которых было зафиксировано ожидание при установке управляемой блокировки.

Помним, что в этом случае поле WaitConnections= не пустое.

Аналогичным способом разобранную конструкцию можно самостоятельно применять и для других задачи поиска top 5 .

Поиск по другим журналам

Если посмотреть, например, на access логи nginx, то мы видим пригодные для разбора журналы.

Например, (в зависимости от того, как выглядят журналы у вас) получение оценки, на какой единицы масштабирования запросы

выполняются дольше других, может быть таким:

Когда серверов много

Допустим, вы знаете, что в вашей сети серверы имеют имена вида server1, server2, . server100 .

Тогда мы можем вывести имена всех серверов примерно так:

Но тогда, например, поиск EXCP по множеству серверов будет выглядеть примерно так:

Т.к. журналы могут быть большого объема, такая конструкция может привести к тому, что на множестве серверов будет обрабатываться большой объем данных.

По этой причине лучше искать более точечно. Например, среди последних 1000 строк.

Естественно через pipe | вы можете применять уже знакомые вам конструкции.

zip архивы

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

Естественно хранить такие архивы лучше не рабочих серверах, а в отведенных для этого хранилищах.

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

Можно воспользоваться конструкцией вида

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

Технологический журнал — специальный механизм платформы 1С 8.2 и 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки. Рассмотрим инструкцию по настройке технологического журнала в 1С: Предприятии.

Инструкция по настройке технологического журнала

  1. Завести на локальных дисках серверов приложений 1С специальную папку для технологического журнала. Например, C:LOG . И для дампов, например, C:dumps.
  2. Настроить журнал на сбор сообщений об ошибках (см. файл logcfg.xml) в подкаталог этого каталога. Подкаталог будем называть по дате: C:LOG2014-04-22 и т.д.
  3. Сам файл logcfg.xml надо положить в каталог conf папки установки сервера (!) 1С: Предприятия (например, C:Program Files1cv828.2.17.153inconf).
  4. После этого примерно через минуту убедиться, что в каталоге создалась папка C:LOG2014-01-01, и в ней еще подпапки с именами rphost_XXXX, ragent_XXXX, rphost_XXXX, а в них файлики.
  5. Если создались, то все нормально, если не создались, то что-то не так.
  6. Если что-то не так: наиболее распространенные ошибки: большие/маленькие буквы в именах каталогов (регистр должен совпадать), в файле настройки написали слеш на конце имени каталога (не нужен), а еще иногда требуется донастроить права пользователей на папки C:LOG, C:dumps, C:Program Files1cv828.2.17.153inconf, если они чересчур «закручены».
Читайте также:  Средство запуска zenui что это

Файл logcfg.xml изнутри должен выглядеть примерно так:

Получите 267 видеоуроков по 1С бесплатно:

Атрибуты для настройки журнала

ALL Все события Абсолютно все события технологического журнала
ADMIN Административное действие Действия пользователя-администратора кластера серверов 1С Предприятия 8.2
CALL Входящий вызов Входящий удаленный вызов (удаленный вызов на стороне приемника вызова)
CONN Соединение с сервером Установка или разрыв TCP-соединения между процессами системы «1С 8.3»
CLSTR Активность кластера Выполнение операций, изменяющих работу кластера серверов
EDS Внешний источник данных Все события внешних источников данных
DB2 IBM DB2 Исполнение операторов SQL СУБД IBM DB2
DBMSSQL Microsoft SQL Server Исполнение операторов SQL СУБД Microsoft SQL Server
DBPOSTGRS PostgreSQL Исполнение операторов SQL СУБД PostgreSQL
DBORACLE Oracle Database Исполнение операторов SQL СУБД Oracle Database
DBV8DBEng SQL, Файловая СУБД Исполнение операторов SQL файловой СУБД
EXCP Исключение Исключительная ситуация приложения системы «1С: Предприятие», которое штатно не обрабатывается и может послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса
EXCPCNTX Контекст исключения Событие, которые началось, но не закончилось в момент возникновения нештатной ситуации
HASP Обращение к HASP Обращение к аппаратному ключу защиты (HASP)
LEAKS Утечка памяти Событие, связанное с утечкой памяти, которая может быть вызвана ошибками в коде конфигурации 1С 8.2
MEM Утечка памяти сервера Событие, связанные с увеличением объема памяти, занятой серверными процессами (ragent, rmngr, rphost).
PROC Процесс Событие, относящееся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например: старт, завершение, аварийное завершение и т. п.
QERR Ошибка запроса Событие, связанное с обнаружением ошибок компиляции запроса или ограничением на уровне записей и полей базы данных
SCALL Исходящий вызов Исходящий удаленный вызов (исходящий вызов на стороне источника вызова).
SCOM Серверный контекст Событие создания или удаления серверного контекста, обычно связанного с информационной базой.
SDBL Запрос к базе данных Исполнение запросов к модели базы данных 1С: Предприятия 8.3
SESN Сеанс Действие, относящиеся к сеансу работы. Например: начало сеанса, окончание сеанса и т. д.
SRVC Сервисы кластера События, связанные с запуском, остановкой и оповещениями сервисов кластера серверов
TLOCK Блокировка Управление транзакционными блокировками в Управляемом режиме
TDEADLOCK Взаимоблокировка Обнаружена взаимоблокировка в Управляемом режиме
TTIMEOUT Таймаут Превышено максимальное время ожидания транзакционной блокировки
VRSCACHE Кеш http Работа кеша серверных вызовов
VRSREQUEST Запрос к серверу Запрос к серверу за некоторым ресурсом
VRSRESPONSE Ответ сервера Ответ сервера
SYSTEM Системные события Системные события механизмов платформы, предназначенные для анализа сотрудниками фирмы «1С»

Видео — Рекомендации по настройке технологического журнала 1С:

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Технический блог специалистов ООО"Интерфейс"

  • Главная
  • Включаем технологический журнал для 1С:Предприятие

Включаем технологический журнал для 1С:Предприятие

  • Автор: Уваров А.С.
  • 12.01.2016

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

Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.

Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:

В дампах могут разобраться только разработчики платформы! (только у них исходники 🙂 )

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

Платформа Windows

Для включения и настройки технологического журнала в среде Windows необходимо в папке C:Program Files (x86)1cv8conf создать специальный файл настроек 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 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).

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

Это позволит фиксировать события обращения к ключам защиты в том виде, в котором они фиксируются системой защиты HASP, в то время как 1С подменяет их своими сообщениями, типа "ключ защиты не обнаружен", обладающими крайне низкой информативностью.

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

Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.

Для примера приведем участок лога:

Сразу видно, что система не может разрешить имя сервера W81-TEST, возможно из-за проблем в DNS. Как видим, логи вполне читабельны и понятны, что позволяет осмысленно подходить к разбору ошибок, особенно в тех случаях, когда явного сообщения об ошибке не выводится, скажем не стартует процесс сервера.

Платформа 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 создаются нужные папки логов.

Оцените статью
Добавить комментарий

Adblock
detector