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С
Новосибирск
зарплата от 60 000 руб. до 160 000 руб.
Полный день

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

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

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

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