Спасибо за Ваш вопрос. Из структурированных форматов, сейчас есть поддержка только для DLT формата. Иные форматы воспринимаются как plain text. Между тем, Вы можете создать feature requestздесь и описать своё видение, что очень важно. Например мне сложно представить, что именно Вы хотели бы видеть в качестве поддержки логов в формате JSON. Как должна отображаться строка логов? Как текст или, например, поименованными столбцами (а если JSON имеет вложенную структуру?). Или может вы хотели бы видеть на sidebar представление выделенной строки логов как JSON pretty print? Как видите вопросов возникает масса, поэтому мы призываем создавать feature request, где Вы и мы могли бы обсудить как именно должна быть реализован тот или иной функционал.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Спасибо за Ваш отклик. Поддержка tail и возможность включения любых дополнительных кодировок появится в версии 3.x вместе с упомянутой мной оптимизацией производительности. Произойдёт это не раньше чем через 1-1.5 месяца.
К сожалению, такого рода временные метки не могут быть идентифицированы прямым путём. Я имею ввиду, что это не соответствует формату YYYY, MM, DD, hh, mm, ss etc. Как отличить «20200825223600050161» от простого числа логах? Полагаю, что никак.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
Какого рода интеграцию вы имеете ввиду? Например, интеграция с DLT понятна — декодирование и разбиение на столбцы для удобства чтнения. С opentracing немного не ясно, что именно нужно интегрировать. Поясните пожалуйста.
Спасибо за разъяснения.
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Спасибо за ваш комментарий.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Полностью с вами согласен, юзкейсов очень много. И далеко не всегда логи хранятся удалённо. У нас, например, довольно большая группа пользователей, работающих с embedded software. И там можно получать десятки гигобайт логов лишь за ночь или за одну сессию тестирования. При этом логи часто бывают от нескольких источников, что вовсе не облегчает жизнь. Ну и конечно, такие логи живут более ли менее локально.
Спасибо за ваш вопрос. Там были изменения в порядке подписания приложения. Мы «покрыли» тот порядок, который установлен на 10.15 и младше, и, честно, не стали заморачиваться над поддержкой процедуры подписания для более поздних версий. Дело только в подписи. Решили, что если появится issue на этот счёт, то обязательно добавим поддержку более ранних версий ОС, но пока запросов не поступало.
Спасибо за ваш комментарий.
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
Спасибо за ваш комментарий. Я отвечу сравнением, если позволите.
В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.
Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.
На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.
Не бывает «некуда уходить». Бывает только «страшно». Просто начинайте смело работать над своим желанием лучшего. Заставьте себя хотеть перемен. Убедите себя в том, что иного выхода, кроме как двигаться вперед у вас тупо нет. Прямо так – или я тут в конце концов сопьюсь (утрированно), или я стану крутым парнем из столицы. Никто, вообще никто не держит вас на месте, кроме вас самих. Поймите это, и все потихонечку начнет двигаться.
Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Что касается горячих клавиш, создал issue.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
(?<YYYY>\d{4})\s(?<MM>\d{2})(?<DD>\d{2})\s(?<hh>\d{2})(?<mm>\d{2})(?<ss>\d{2})Это должно будет работать и для вашего случая
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Релиз увидите в
На борту надо иметь:
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.
Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.
На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.
ЗЫ. Кстати ripgrep шустрее )
Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.