Анализ технологического журнала (ТЖ) — это один из наиболее эффективных способов диагностики проблем производительности в системе 1С:Предприятие. Когда мы сталкиваемся с необходимостью быстро проанализировать огромные массивы данных, на помощь приходят классические инструменты командной строки Linux. В этой статье мы подробно разберем, как извлечь информацию о длительных блокировках TLOCK, отсортировать их по времени выполнения и, что самое важное, определить, в каком конкретно файле лога зафиксировано то или иное событие.
Рассмотрим ситуацию, с которой часто сталкиваются начинающие разработчики. При попытке собрать все данные в один поток через команду cat, мы теряем метаданные о файлах. Разберем типичный пример неудачного скрипта:
cat rphost*/*.log | grep -P 'TLOCK' | perl -pe 's/[0-9][0-9]:[0-9][0-9]\.[0-9]+-//' | sort -rnb | head -n 10
В данном случае команда cat объединяет содержимое всех файлов в единый поток (standard input). Когда этот поток попадает в grep, утилита уже не знает, из какого файла пришла та или иная строка. В итоге мы получаем список самых длинных блокировок, но не можем понять, в какой момент времени и в какой папке rphost (а значит, в каком рабочем процессе) это произошло.
Для того чтобы grep выводил имя файла, нам нужно отказаться от предварительного объединения через cat. Если передать маску файлов непосредственно в grep, он автоматически добавит имя файла в начало каждой найденной строки. Проанализируем исправленный вариант:
grep -P 'TLOCK' rphost*/*.log | perl -pe 's/[0-9]+:[0-9]+\.[0-9]+-/~/' | gawk -F'~' '{print $2 $1}' | sort -rnb | head -n 10
Разберем по шагам, что здесь происходит:
grep -P 'TLOCK' rphost*/*.log — ищем вхождение строки TLOCK во всех файлах всех папок процессов. Поскольку файлов несколько, grep по умолчанию добавит префикс вида имя_файла:строка_лога.perl -pe 's/[0-9]+:[0-9]+\.[0-9]+-/~/' — с помощью регулярного выражения мы заменяем временную метку в начале события на символ-разделитель (тильду). Это нужно для того, чтобы отделить имя файла и время от самой длительности события.gawk -F'~' '{print $2 $1}' — используем утилиту awk (или gawk), чтобы поменять местами блоки данных. Мы выводим сначала длительность, а затем имя файла и контекст. Это критически важно для последующей сортировки.sort -rnb — выполняем обратную (reverse) числовую (numeric) сортировку, игнорируя начальные пробелы (blank).head -n 10 — оставляем только топ-10 самых длительных блокировок.Если вы по каким-то причинам все же используете сложные цепочки команд, где grep получает данные не напрямую, можно воспользоваться флагом -H (или --with-filename). Однако помните, что если данные приходят из stdin, grep выведет надпись (standard input). Поэтому правильный подход — всегда указывать пути к файлам в качестве аргументов grep.
Как отметили опытные участники сообщества, команда grep -H принудительно заставляет утилиту печатать имя файла, даже если поиск идет только по одному файлу. Это полезно для автоматизации скриптов обработки.
Важно понимать, что логи 1С часто содержат многострочные записи (особенно в части Context). Обычный grep обрабатывает файл построчно, что может привести к потере важной информации о том, какой именно код на языке 1С вызвал блокировку. Выясним, как с этим бороться.
Для полноценного анализа рекомендуется использовать pcregrep с флагом -M (multiline). Это позволит захватывать событие целиком, включая все строки до начала следующей временной метки. Пример структуры регулярного выражения для поиска начала строки события: \d{2}:\d{2}\.\d{6}.
Хотя однострочники на Bash работают очень быстро, при объемах логов в сотни гигабайт ручной поиск становится трудоемким. Проанализируем современные альтернативы:
ripgrep. Он написан на Rust и работает значительно быстрее классического grep, эффективно используя многопоточность.TTIMEOUT через сопоставление WaitConnections, выполняется простыми SQL-запросами за доли секунды.TLOCK в реальном времени, что удобно для мониторинга после выпуска критических обновлений конфигурации.При поиске блокировок всегда обращайте внимание на следующие нюансы:
1. Единицы измерения: В разных версиях платформы 1С длительность может указываться в микросекундах или в десятитысячных долях секунды. Обязательно проверьте это перед тем, как настраивать фильтры по числу (например, блокировка в 20 секунд может выглядеть как 20 000 000 или как 200 000).
2. Корреляция с TTIMEOUT: Само по себе событие TLOCK — это лишь факт установки или ожидания блокировки. Если вы ищете «вылеты» по таймауту, вам нужно искать событие TTIMEOUT. В нем будет указано свойство WaitConnections, содержащее номер соединения, которое удерживало ресурс и не дало вашему процессу завершить операцию.
3. Кодировка файлов: Помните, что логи ТЖ могут быть в кодировке UTF-8 или UTF-16. Если ваш grep ничего не находит, хотя вы видите строки глазами в текстовом редакторе, попробуйте предварительно преобразовать файл через iconv или используйте инструменты, понимающие разные кодировки (например, современные версии awk и grep в стабильных дистрибутивах Linux).
Используя предложенные методы, мы можем не только быстро находить самые тяжелые события в технологическом журнале, но и точно определять их источник, что значительно сокращает время на расследование инцидентов в высоконагруженных системах 1С.