Завершение проекта 🙁
С 01 мая 2024 г. программа развиваться больше не будет ввиду отсутствия свободного времени у автора. Скачать отныне можно будет только актуальную версию программы (0.3.5), но только на условии "as is" ("как есть"), со всеми вытекающими последствиями.
Добавлена новая версия — v0.3.4!
Исправлена ошибка чтения из технологического журнала событий в усеченной форме (вида "00:00.119005-1,CALL,1"). Добавлен счетчик затраченного времени на считывание событий из технологического журнала. Успешно протестирована работа программы на достаточно больших логах (до 2-3 Гб), при этом время считывания составило менее 1-ой минуты (логи хранились на SSD). В случаях, когда оперативной памяти все же не хватает, достаточно разделить файлы внутри ТЖ на группы, и выполнить анализ по каждой в отдельности.
Добавлена новая версия — v0.3.2!
Программа теперь умеет работать и со старым форматом технологического журнала 1С, в котором для определения временного смещения использовалось 4 символа вместо 6. Формат определяется автоматически при открытии файла.
Добавлена новая версия — v0.3.1!
Исправлена ошибка считывания строк лога ТЖ, если в файле встречаются пустые строки (found by Armando).
Способ обхода указанной ошибки в предыдущих версиях программы – перед анализом журнала удалить пустые строки из файла лога ТЖ.
Парсер технологического журнала 1С
Выполняет разбор логов (файлов *.txt) каталога технологического журнала, включая разбивку по именам ключевых свойств событий и их значений.
Написан на С# (.NET).
Новое в версии v0.3:
- Расширена статистика у фильтров (% и максимальная длительность);
- Добавлен фильтр на минимальную длительность событий;
- Исправлена ошибка скрытия/отображения некоторых колонок таблицы событий;
- Повышено usability программы.
Новое в версии v0.2:
- Стало возможно накладывать множественный фильтр на имя процесса, PID и имя события, а также осталась возможность дополнительно фильтровать записи, включив контекстный поиск по именам ключевых свойств событий и их значений;
- Поле "Дата события" разнесено на 2-е отдельные колонки (дата и время);
- Добавлена возможность изменения внешнего вида таблицы событий и таблицы свойств (меню "Вид");
- Приложение протестировано на больших объемах технологического журнала (> 2 000 000 событий), полет нормальный;
- Улучшено визуальное отображение элементов формы;
- Исправлены замеченные ошибки в коде, повышена стабильность работы.
Все события и свойства поддерживаются? Если новые появляются их распознает?
Как работает с большими файлами > 500 Мб, хватает ли памяти на обработку большого количества таких файлов?
Есть ли ограничение на размер значения свойства?
Цена 10см не маленькая. При исправлении ошибок каждый раз 10см тратить на скачивание?
Соглашусь. В чем конкурентное предшествуемо аналогичных разработок-обработок
(1) Armando, события и свойства жестко в коде не прописаны. Фильтр на вид события (как и на тип процесса) заполняется динамически на основе анализа соответствующего поля. Поэтому с новыми событиями и свойствами работать будет.
С чем НЕ будет работать: со старым форматом технологического журнала, в котором на смещение и длительность событий отводилось всего 4 разряда (возможно, мне следовало указать это в описании).
Для тестирования я использовал логи ~450МБ, при этом полная загрузка выполнялась < 5 сек. — это около полумиллиона событий. Анализировать логи большего размера не вижу смысла, эффективнее включить фильтрацию в файле-семафоре (logcfg.xml). Для справки: в С# максимальный размер объекта типа String может составлять в памяти до 2 ГБ, или около 1 миллиарда символов. Мало? )
Если цена кажется большой — напишите свой парсер и представьте его публике. Не исключено, что он превзойдет по функциональности и удобству мой, и при этом обойдется дешевле. Но пока ощущается недостаток в таком инструментарии, раздаривать его налево и направо я не хочу. Пусть это станет побуждением к активным действиям.
(3) sarycheff
все верно, но часто надо разгребать уже имеющиеся файлы.
Мне 10 не жалко, у меня фантиков много. Просто к дорогим разработкам отношусь с осторожностью. Готов скачивать несколько раз, если каждый раз будут новые версии с новым функционалом. Но не готов тратить 10, если в новой версии только исправлены ошибки.
Еще вопрос: можно ли наложить фильтр, например, «Процесс любой и Событие = CALL и Свойство = Memory и Значение >= 10000»
или такой: «Событие CALL или SCALL и Свойство = CallID и Значение=212121212»
думаю смысл понятен — нужны гибкие фильтры.
И если еще не видели, то обязательно посмотрите «Инструменты разработчика»http://infostart.ru/public/15126/ там есть шикарный парсер-анализатор журнала, но на больших размерах начинает тормозить, или вообще может улететь по нехватке памяти((
Будет круто, если сделаете что-то подобное, но без озвученных проблем производительности.
(4) Armando, касаемо развития функционала: собственно, для этого и выкладываю — чтобы понять, насколько востребовано. Будет спрос, будет и желание дальше развивать проект.
Что же до гибких фильтров — в перспективе возможно будет все. В текущей же версии можно наложить фильтр вида:
Процесс — любой и Событие = CALL и в строке ключевых свойств и значений присутствует «212121» (поле «Найти» выполняет поиск по вхождению).
Для фильтров типа «Значение >= 10000» придется дополнительно анализировать тип значения каждого свойства, а это, согласитесь, дополнительные ресурсы и задержки по времени. В моей разработке разбивка по свойствам происходит динамически в момент активизации строки списка.
Вообще изначально весь код был написан как внешний отчет на СКД, но файловые функции 1С:Предприятия тормозят жутко, поэтому рассматривалось 2 варианта дальнейшего развития проекта:
1. Парсер на C++, C# или Java с собственным интерфейсом. Недостаток очевиден — фильтрацию, группировку и поиск программировать ручками, либо искать подходящий визуальный компонент, при этом несомненный плюс — это скорость работы;
2. Внешняя компонента 1С для подключения (исполнения) при компоновке результата отчета и вывода в СКД. Тогда можно было бы накладывать действительно сложные фильтры. Вот только боюсь, сама СКД может оказаться чересчур прожорливой…
(4) В анализе техножурнала ИР нехватка памяти и жутко тормозит обычно в том случае, если выполняются оба условия:
1) первичный фильтр (в конфигурационном файле) настроен на регистрацию большого потока информации
2) при чтении журнала не задается интервал времени, который на текущий момент является единственным фильтром чтения/загрузки
Делать фильтры чтения аналогичные первичным кажется не имеет большого смысла, т.к. фильтровать по возможности нужно именно в первичном фильтре.
(4) В ИР версии 3.45 добавлено поле лимита количества загружаемых событий для предотвращения аварийного завершения из-за нехватки памяти, по умолчанию 100 000.
Это на чём написано ? Исходник не выкладываете ?
(8) alex_4x, написано на C#. Выкладывать исходник в планах пока не было.
Скачал версию 0.3. Нормально, что показывает только 30 событий? Файл 157 мегабайт и там точно не 30 событий. Вложил файл.
(10) Armando, отписался в ЛС.
Задумка очень хорошая и внешний вид нравится. Но не хватает, конечно, некоторых базовых функций.
Сам пару раз уже начинал делать подобное (на C# и на Python), но доходило только до отображения просто таблицы записей, на бОльшее меня не хватало 🙂
(12) sashocq, спасибо за замечания, обязательно учту в следующих версиях разработки (похожие идеи посещали и меня). Пока что же катастрофически не хватает времени на проект.
Если в папке лежат журналы нескольких процессов, то нет возможности сортировать записи в хронологическом порядке, сортируются только по секундам.
Не смог загрузить ни один журнал — программа вылетает
Добрый день!
Не смог загрузить ни разу.
Запускал на win10 и Microsoft Windows Server 2012 R2 Standard
Сигнатура проблемы:
Имя события проблемы: CLR20r3
Сигнатура проблемы 01: TechLog1C.exe
Сигнатура проблемы 02: 0.3.1.0
Сигнатура проблемы 03: 56b107e4
Сигнатура проблемы 04: mscorlib
Сигнатура проблемы 05: 4.7.2117.0
Сигнатура проблемы 06: 59cf500c
Сигнатура проблемы 07: 107a
Сигнатура проблемы 08: 5c
Сигнатура проблемы 09: System.FormatException
Версия ОС: 6.3.9600.2.0.0.272.7
Код языка: 1049
Дополнительные сведения 1: 5861
Дополнительные сведения 2: 5861822e1919d7c014bbb064c64908b2
Дополнительные сведения 3: 5f25
Дополнительные сведения 4: 5f2531ae070278f893fa99352dadd49e
логи для теста во вложении
(15), какой релиз платформы 1С, которым снимался ТЖ? В ранних версиях формата ТЖ для временного смещения внутри секунды отводилось 4 знака, в последних — 6 («mm:ss.tttttt-d»). Программа рассчитана на новый формат ТЖ. Проверьте на актуальной версии платформы.
Платформа 8.2 и обновить её нет возможности. Исследовать приходится именно её.
Можно добавить в программу выбор формата? В противном случае зря потраченные смартмани
Быстрый но в плане работы крайне не удобно. Самые проблемные моменты:
1. при изменении параметра, к примеру, фильтр длительность. не понятно применилось или нет. на нажатие ‘enter’ не срабатывает. сообщение что-ли бы повесили, применить изменения (как в интернет магазинах)
2. при выделении строки отображается под ней дополнительный текст. вот когда этот текст занимает пару листов, то это совсем ужасно. сделали бы хоть ограничение на размер в 2-3 строки и кнопку подробнее, а лучше еще в отдельную вкладку. еще хорошо бы дать скопировать текст.
особенно раздражает, что нормально прокрутить нельзя в этом случае.
3. выгрузки в эксель не хватает, т.к. куртить там возможности шире.
4. хотя бы ссылки на файл и номер строки, где данная информация по логам расположена.
Итого общее впечатление следующее: что-то показывает и даже фильтрует, но как практически применять не понятно.
Увы, лог в 4,5Гб не читает, хотя ресурсов более, чем достаточно.ТЖ версии 8.2, версия обработки 0.3.4
(19), проблема скорее не в нехватке ресурсов, а в содержании журнала. Можете предоставить файлы ТЖ для анализа?
К сожалению читает файлы размером до 2,5 Гб. В наше случае, когда лог достигает 13Гб, обработка бесполезна. Прошу вернуть См.
(21), я не давал гарантий в описании, что программа сумеет обработать файл такого размера. Подсуньте такой объем мелкомягкому офису и скорее всего получите аналогичный результат. И вообще вызывают искреннее удивление необходимость постобработки логов такого объема. Вы не в курсе, что события в ТЖ можно отфильтровать на стадии формирования логов?
Уважаемый, ситуации бывают разные и объем журнала в 13 Гб — это объем журнала с установленными фильтрами, без фильтров он просто несоразмерен. Мелкомягкий офис прекрасно справляется с объемом в 13-14 Гб, Ваша обработка привлекла фразой «Успешно протестирована работа программы на достаточно больших логах (до 2-3 Гб)» и возможностью установки фильтров, но даже с указанным объемом она не справляется.
ТЖ несколько mb логи запросов postgreesql скачал версию 0.3.2. Зависает на мертво при фильтрации по времени + нет возможности сворачивать события, только если на другое кликнуть. Запросы огромного размера, поэтому не получается посмотреть сколько их вообще есть.
Проблема с фильтрацией решилась, если отключить вывод содержания в таблицу. Видимо не поддерживает огромные текстовые поля не помещающиеся на экран.
В целом понравилось, удобно.
UPD.
Скачал 0.3.4 проблема не в версии.
Зависает при клике на конкретную строку. Скрин и файл с логами прикладываю.
Прошу вернуть деньги или предоставить работающую версию, как анонсировано в статье.
(24), в прикрепленном логе ProcessID = 3164, на нем ошибок не наблюдается. А на скрине ProcessID = 3820.
(25) добавил всю папку + гиф как делаю. Прошу разобраться.
Крутая софтина и цена доступная.
Для Админа, который ТЖ в первый раз видит и нужно разобраться, самое то!
Минус: работает на windows 10 и не работает на windows server 2012
Скорее всего имеет в зависимости новую библиотеку .NET
Показать
(28), работало без проблем на «голом» Windows Server 2012 R2 Standard Build 9600. Из установленного — только пакеты Microsoft Visual C++ 2015 Redistributable 2015 (x86 и x64).