0. lazarenko 196 24.10.18 14:23 Сейчас в теме

Go. Разбор лога технологического журнала. Достойная альтернатива perl'у

Началось все с того, что я познакомился с перловыми скриптами для парса ТЖ которые размещены на kb.1c.ru (например в этой статье https://kb.1c.ru/articleView.jsp?id=113). По началу мне дико понравилось то, что перл разбирал гигабайты логов за считанные минуты, но позитив мой угасал обратно пропорционально с тем, насколько глубже я погружался в "кроличью нору" ....

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 35 24.10.18 16:31 Сейчас в теме
Вероятно следующим шагом будет использование мощностей CUDA и обработка блоков журнала ядрами GPU.

https://madhumithasridhara.github.io/QuickMatch/
http://bkase.github.io/CUDA-grep/finalreport.html
AlexGroovy; +1 Ответить
2. lazarenko 196 24.10.18 16:36 Сейчас в теме
(1) Кстати, отличная тема, только там что-то все ссылки битые
3. PerlAmutor 35 24.10.18 16:39 Сейчас в теме
(2) Тем ценнее будет, если напишешь собственную реализацию. Ссылку поправил.
5. lazarenko 196 24.10.18 17:18 Сейчас в теме
Ссылку поправил.

(3) ресурс твой?
6. PerlAmutor 35 24.10.18 17:20 Сейчас в теме
(5) Нет. Просто там явно шел "перепост" с другого сайта.
4. PerlAmutor 35 24.10.18 17:11 Сейчас в теме
(2) Вот еще интересно было бы протестировать с https://www.hyperscan.io/

https://www.youtube.com/watch?v=-FWuzzHBG5A
AlexGroovy; +1 Ответить
9. lazarenko 196 24.10.18 17:52 Сейчас в теме
(1) по CUDA-grep вообще нет внятной документации, какой-нибудь how-to сделали б
7. tsukanov 69 24.10.18 17:44 Сейчас в теме
Гошан прекрасен.
Особенно кайфую от профайлера.

Тоже была мысль парсить на нем логи, но я хотел обойтись без регулярок.
8. lazarenko 196 24.10.18 17:46 Сейчас в теме
(7) вполне вероятно, что такой вариант будет более быстрый, но явно менее поддерживаемый, так что нужно найти золотую середину
10. tsukanov 69 24.10.18 17:54 Сейчас в теме
(8) Я бы не был так уверен насчет "явно" )
Простые процедуры сканирования идентификаторов, чисел и прочих лексем не должны быть в общем случае сложнее для понимания/поддержки чем регулярки.

Еще кстати повсеместное использование map тоже может быть не оптимально. В определенных случаях линейный поиск будет теоретически быстрее, просто потому что map вынужден просматривать всю строку для вычисления хэша (хотя я на самом деле не знаю какая реализация map в Go, может и норм).
25. Darklight 17 25.10.18 09:54 Сейчас в теме
(10)Даёшь конечный автомат, специально заточенный под тех логи!
Яндекс библиотека PIRE как раз и переводит регулярки в конечный автомат :-)
11. ALex_1C_8 24.10.18 18:15 Сейчас в теме
Не могу не заступиться за perl))
По поводу паралельности - он отлично паралелится на Windows (я про fork), а если еще между ними pipe прокинуть так процессы и общаться могут.
По поводу долго чтения файла. У перла при открытии файла можно указать "слои" которые нужно использовать. Рекомеедуется, если используешь функцию open, обязательно использовать слой io так как он буферезирует данные и читает норм.
Мои замеры таковы, что один процесс вычитывает файл, размером 2.5 гб, на локальной машине, примерно за минуту +- секунд 10, сюда также входит разбивка данных на события и определение его длительности, названия и т д, но без разбора самого события , а именно свойств и их значений.
12. lazarenko 196 24.10.18 18:35 Сейчас в теме
(11) не знаю, я не наблюдал порождения нового процесса при fork'e, а если сделать sey pid после fork то выводил какой-то минусовой пид. Хотя не буду вступать в полемику, я допускаю, что мой скрипт на перл можно было бы сделать более производительным.
13. lazarenko 196 24.10.18 18:39 Сейчас в теме
(11) если знаком с перлом, присоединяйся к разработке, в статье есть ссылка на репозиторий где тот скрипт лежит
14. Rustig 1152 24.10.18 21:11 Сейчас в теме
(0) какое практическое применение?
15. palsergeich 24.10.18 23:43 Сейчас в теме
(14) Ускорение работы регулярок. Я баловался писал парсер на питоне, там 95% затрат времени - работа с регулярками.
16. Rustig 1152 24.10.18 23:44 Сейчас в теме
(15) а что за задачи , которые связаны с регулярными выражениями?
18. palsergeich 24.10.18 23:45 Сейчас в теме
17. Rustig 1152 24.10.18 23:45 Сейчас в теме
(15) в каких ситуациях требуется анализировать тех. журнал? тем более парсить его?
19. palsergeich 24.10.18 23:46 Сейчас в теме
(17) Основная задача - расследование проблем с производительностью.
Еще есть задача - мониторинг
20. Rustig 1152 24.10.18 23:48 Сейчас в теме
21. palsergeich 24.10.18 23:53 Сейчас в теме
(17) Например:
1) у всех пользователей полезли ошибки - максимальное время ожидание транзакции - никак виновника, кроме как по ТЖ не найдете, потому что это Управляемые блокировки и они нигде более не фигурируют.
2) Просто тормозит база. На часик запись полного ТЖ, и смотрим какой запрос суммарно дольше всего выполнялся. Это может быть как и многомиллионный спам микрозапросов, которые например ЦУП пропустит(+ цуп именно эти вещи ну очень медленно вычисляет, да еще не всегда у него удается, на обучении при анализе ТЖ из 5ти попыток успешно прочиталось 1 раз только), из коробки там замер, дай бог памяти 1сек и более, так и какой нибудь чудовищный запрос. Или кто то накосячил в фоновом задании и оно бесконечно выполняется. Или 90% нагрузки создает ДС. Как правило после решения топ 3 строчек база порхать начинает.
3) Можно попытаться найти причиину утечек памяти, но тж не дает точной проблемы из-за особенностей записи этих событий, но направление дать может.
4) Мониторинг это не через час позвонили и сообщили о проблеме
1) а в течение 5 минут вам пришло уведомление, что число таймаутов за сутки стало больше порога.
2) Какой то ключевой запрос неделю назад выполнялся в среднем 5 секунд, а сегодня стал выполняться в среднем 10 секунд, хорошо бы понять причину
3) Число аварийных завершений процессов вместо допустимых ну скажем 3х в сутки, за час стало 5, надо разобраться
Ну это основное
Krio2; SirYozha; qus-qus; CSiER; Tutr; Rustig; +6 Ответить
23. Infactum 275 25.10.18 08:33 Сейчас в теме
(21) И для всего этого прекрасно подходит ELK стек. Сборщик логов там тоже на Go доступен.
26. palsergeich 25.10.18 09:54 Сейчас в теме
(23)
Условия в которых работать приходилось мне.
Вот тебе удаленный рабочий стол.
Вот тебе канал только для него.
Вот тебе ярлык на папку conf и на папку logs ну и права на них.
Вот тебе консоль.
Мы ничего ставить не будем - развлекайся.
Опыт у меня небольшой в этом, но пока удавалось.
Пункты 1 и 2 на практике применял, 3 и 4 в теории представляю как, но пока это никому не надо было.
27. Infactum 275 25.10.18 10:05 Сейчас в теме
(26) Ага, это стандартная ситуация когда обращаются к эксперту для решения проблемы. Именно из-за этого не сертификации требуют умение анализировать логи через awk/sed итд.
Но имхо лучше в такой ситуации повысить компетенцию клиентов и внедрить нормальную систему анализа логов (можно и не только 1Совских).
28. palsergeich 25.10.18 10:07 Сейчас в теме
(27)
(26) Ага, это стандартная ситуация когда обращаются к эксперту для решения проблемы. Именно из-за этого не сертификации требуют умение анализировать логи через awk/sed итд.
Но имхо лучше в такой ситуации повысить компетенцию клиентов и внедрить нормальную систему анализа логов (можно и не только 1Совских).

Вопрос в деньгах. Времена тяжелые все таки, если после исправления ошибок все устраивает, то убедить в том что надо что то еще невозможно, ну банально нет денег ни на инфраструктуру ни на работы. Ну по крайней мере у средних клиентов, с которыми мне приходилось работать.
29. palsergeich 25.10.18 10:10 Сейчас в теме
(28) Ну а крупных клиентов уже я не потяну, ибо практики в некоторых вопросах нет, а там платят за результат.
Но и то что есть меня пока устраивает.
30. lazarenko 196 25.10.18 10:28 Сейчас в теме
(23) инструменты входящие в ELK быстро (считай из коробки) устанавливаются на linux, на винде нужно поплясать с этим, к тому же нет какого-то коробочного решения (если есть, поделись, я не слышал о таком) для парса лога ТЖ. Нужно изучать правила фильтрации logstash, нужно изучать DSL эластиксеча, не сказал бы, что это просто. Да если твоя работа с этим связана и тебе приходится постоянно парсить логи или ты можешь себе позволить инвестировать время на изучения этого стека технологий, но я бы не назвал это простым решением.
31. Infactum 275 25.10.18 10:32 Сейчас в теме
(30) Сам стек ставится в докере одинаково просто на windows и linux.
Beats (сборщик) нативный. Logstash изучать не надо, т.к. хватит ingest node. В остальном самым сложным является нормальные регулярки для рабора написать, но в вашей разработке задача ровно та же.
32. lazarenko 196 25.10.18 10:35 Сейчас в теме
(31) дай образ докера под винду
33. Infactum 275 25.10.18 10:41 Сейчас в теме
(32) Нативный контейнер для Windows Server 2016 хотите? Такого нет официально. Да и имхо не нужно совершенно.
Остальные контейнеры тут: https://www.docker.elastic.co/
35. lazarenko 196 25.10.18 14:16 Сейчас в теме
(33) дело было я пробовал, потыкался, и забросил, я не могу сказать, что там все просто и понятно. Помню застрял на том, что в logstash не мог передать данные из stdin (а ранее мучался с кибаной, что бы на IIS поднять ее). Если есть опыт, пиши статью, как это делать, всем комьюнити спасибо скажем )
22. PerlAmutor 35 25.10.18 06:49 Сейчас в теме
Нашел статью Intel, где сравнивается производительность Perl и Hyperscan: https://software.intel.com/en-us/articles/why-and-how-to-replace-pcre-with-hyperscan

Вот еще статья на хабре: https://habr.com/post/275507/

Кстати, странно, что в интернете так мало информации об этой библиотеке.

Есть еще библиотека Яндекса, PIRE. Тоже было бы интересно поэкспериментировать: https://github.com/yandex/pire
eeeio; artbear; +2 Ответить
24. lazarenko 196 25.10.18 09:38 Сейчас в теме
(22) Hyperscan это ж сишная библиотека, а вот от яндекса можно попробовать
34. dablack 25.10.18 12:30 Сейчас в теме
Наконец то!. Это по моему первая статья здесь в которой есть golang.
36. ddens 126 05.12.18 15:30 Сейчас в теме
А когда сам вендор напишет нормальную утилиту для анализа ТЖ? у которой юзабилити была хоть сколько-нибудь приемлемая.
...Что? ЦУП и ЦКК говорите?
37. lazarenko 196 05.12.18 16:11 Сейчас в теме
(36) вендор нормального подробного описания формата ТЖ не может предоставить, а ты говоришь утилиту.
38. palsergeich 08.12.18 20:36 Сейчас в теме
(36)
А когда сам вендор напишет нормальную утилиту для анализа ТЖ? у которой юзабилити была хоть сколько-нибудь приемлемая.
...Что? ЦУП и ЦКК говорите?

Угу.
Атрибут Context может быть в записи, а может и не быть.
Мы так до сих пор и не поняли почему так случается (С)
Вообще символ перевода строки - это новая запись.
Но там где есть Context и тексты запроса это не работает. По этому достаем грепы и символом начала строки будет /d/d:/d/d/./d/d/d/d etc, а все остальные символы перевода строки заменяем <newline>
А да еще никто не догадался, что служебное имя временной таблицы никому не надо, по этому еще раз режем tt.+ на tt
И да, атрибуты в самом событии тоже просто так разбить нельзя, это не запятая+пробел.
Запятая + пробел - она может быть в текстах.
И да не Запятая + Пробел + .* + = Это тоже может быть в текстах
И для того что бы по человечески нарезать на столбцы надо 5 регулярок + около 10 СТРЗаменить.
Иначе никак.
А еще мы в каждый новый релиз платформы добавим пару атрибутов новых в ТЖ.
Но в описание релиза не поместим.
А Скажем Вам - ищите в руководстве администратора. Его издание было пол года назад - Вы просто неудачник, мы вот например знаем что это и зачем.
Вы так же можете воспользоватся ЦУП. Что он не работает и валится, а Вы за это отдали 100К? А если не валится то 5 минут парсит пару часов? Вы просто неудачник.
YPermitin; +1 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
зарплата от 115 000 руб. до 160 000 руб.
Полный день

Руководитель проектов 1С
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб. до 150 000 руб.
Полный день

Программист 1С
Новосибирск
зарплата от 80 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству