Безумные логи

[citius]

Логи обычно не на локалхосте, а где-то в облаках лежат.

[mjr27]

Логами не только микросервисы гадяд. Десктопный софт живее всех живых

[savostin]

The application requires macOS 10.15 or later.

Why?

[AlexWriter]

Спасибо за ваш вопрос. Там были изменения в порядке подписания приложения. Мы «покрыли» тот порядок, который установлен на 10.15 и младше, и, честно, не стали заморачиваться над поддержкой процедуры подписания для более поздних версий. Дело только в подписи. Решили, что если появится issue на этот счёт, то обязательно добавим поддержку более ранних версий ОС, но пока запросов не поступало.

[savostin]

Имхо далеко не все как и я торопятся обновляться до 10.15 из-за кучи 32-битного софта, который перестает работать… Т.е., если самому собрать из исходников, есть вероятность, что заведётся?

[AlexWriter]

думаю, что да.

git clone https://github.com/esrlabs/chipmunk.git
cd chipmunk
rake full_pipeline

Релиз увидите в

chipmunk/application/electron/dist/release

На борту надо иметь:

• node 10 и младше
• ruby 2.6 и младше
• rust

[vvzvlad]

Не получилось

Downloading "chipmunk-asciicolors-plugin" from "https://github.com/esrlabs/chipmunk-plugins-store/releases/download/0.0.14/[e-mail]"
rake aborted!
NoMethodError: private method `open' called for URI:Module
/Users/vvzvlad/Downloads/chipmunk/rake-plugins.rb:87:in `block (2 levels) in delivery'
/Users/vvzvlad/Downloads/chipmunk/rake-plugins.rb:86:in `open'
/Users/vvzvlad/Downloads/chipmunk/rake-plugins.rb:86:in `block in delivery'
/Users/vvzvlad/Downloads/chipmunk/rake-plugins.rb:84:in `each'
/Users/vvzvlad/Downloads/chipmunk/rake-plugins.rb:84:in `delivery'
/Users/vvzvlad/Downloads/chipmunk/rakefile.rb:613:in `block in <top (required)>'
/Users/vvzvlad/Downloads/chipmunk/rake_extensions.rb:37:in `block in execute_with_benchmark'
/Users/vvzvlad/Downloads/chipmunk/rake_extensions.rb:37:in `execute_with_benchmark'
Tasks: TOP => full_pipeline => deliver_defaults_plugins
(See full trace by running task with --trace)
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| (75.2 %) application/electron/dist/compiled/client/main.js ==> 228.2s
||||||||||||||| (15.2 %) application/client.core/node_modules/chipmunk.client.toolkit ==> 46.2s
|||| (3.6 %) electron_build_ts ==> 10.9s
||| (2.7 %) compile_neon_ts ==> 8.1s
|| (1.8 %) application/electron/dist/compiled/apps/rg ==> 5.4s
| (0.7 %) build_embedded_indexer ==> 2.1s
total time was: 303.3


[AlexWriter]

просто обновите ruby. Там были обновления URI библиотеки.

[vvzvlad]

brew upgrade ruby
==> Summary
/usr/local/Cellar/ruby/2.7.1: 20,372 files, 32.9MB

rake aborted!
NoMethodError: private method `open' called for URI:Module

Тоже самое

[vvzvlad]

+1 к «не все как и я торопятся обновляться до 10.15 из-за кучи 32-битного софта».
Пойду соберу.

[Slader]

grep, awk, head + tail
Ну вы чего, какой notepad?!

[AlexWriter]

Спасибо за ваш комментарий. Я отвечу сравнением, если позволите.

В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.

Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.

На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.

ЗЫ. Кстати ripgrep шустрее )

[chapuza]

IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно.

А в виме всего этого, конечно же, нет? Вим из коробки умеет три четверти того, о чем вы пишете, включая файлы в 100500G и tail о котором вот только что попросили; если бы вместо электрона и npm вы бы сначала посмотрели на существующие решения, а потом допилили бы плагин к виму, который добавляет все эти плюшки, типа графиков и красот — вам бы миллионы людей со всего мира сказали спасибо.

А свой электронный велосипед на macOS 10.15 or later — это хорошо на непрофильной конференции людям в кроссовках с мате в руках разок показать, простите уж за прямоту.

[AlexWriter]

Спасибо за ваш совет. Как ответить — не знаю. Задумался. Ведь так то вилка умеет три четверти того, что делает ложка, но меж тем она существует :/

[chapuza]

Угу. Только когда вы хотите есть, вы приходите в столовую, в не в магазин столовых приборов. И если в наличии есть только вилки — то да, придется есть суп вилкой. Хотя всегда есть вариант сесть в машину, съездить за город в торговый центр, купить там ложку, и вернуться.

Тут так же. Логи живут там, где всегда есть вим и где никогда ни у одного здравомыслящего человека не будет X-клиента, чтобы пробросить GUI. sshfs тоже так себе вариант, учитывая, что оно сожрет все преимущества, оборачивая каждый tcp-пакетик в защищенный.

[Slader]

Понятно, что у каждого свой юзскейс.
Но мне в моей ситуации (highload сервисы) удобно либо стандартную смотрелку из mc поюзать (это когда логи маленькие), либо уже греп и tail (когда логи в десятки гигабайт).
Когда что то совсем большое — проще написать на C многопоточный парсер (по давно готовому шаблону) и получить выгрузку/агрегацию очень быстро.
С другой стороны — мои логи в ДЦ и часто очень большие. Это накладывает свои ограничения, да.

[AlexWriter]

Полностью с вами согласен, юзкейсов очень много. И далеко не всегда логи хранятся удалённо. У нас, например, довольно большая группа пользователей, работающих с embedded software. И там можно получать десятки гигобайт логов лишь за ночь или за одну сессию тестирования. При этом логи часто бывают от нескольких источников, что вовсе не облегчает жизнь. Ну и конечно, такие логи живут более ли менее локально.

[gecube]

Я уж не говорю о том, что если требуется что-то сложное — ну, ок — либо страшный пайп из grep/sed/awk и чего-то там, либо если нужна визуализация — ок, грузим все в эластиксерч и крутим данные как хотим. 10ГиБ — это попросту чих. И если уж Вы разработчик и все прям по науке — наверняка у вас в команде уже какой-то кубернетис и сбоку-припеку есть сборка логов в какую-нибудь систему вроде Loki

[tqgwint]

Обычно мне приходится заглядывать в логи находятся где-то там, на серверах. Инструмент размером в 175М быстренько доставить на удаленный сервер чтоб посмотреть с его помощью логи — для меня очень нежизненый сценарий. Разнести заранее на все сервера где возможно придется посмотреть логи? Хм.
Если ваш usecase похож на мои — зайти и найти то вдруг кто-то еще не знает про less?
Размер 188К. Но скорее всего он уже там, на сервере есть.

[AlexWriter]

Спасибо за ваш комментарий.
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.

[gavk]

sshfs не вариант? Не проще ли удалёную фс смонтировать себе?

[tqgwint]

даже если и проще, просмотра больших логов логов через sshfs будет хорошей тренировкой терпения.

[chapuza]

Угу. И правильный сценарий — это сделать выборку там, а результат смотреть здесь, а не наоборот.

А то будет напоминать работу с базой по принципу (select all) -> reduce.

[Andrey_Rogovsky]

split+grep+ловим льва в пустыне

[teakettle]

user@debian:~$ apt search chipmunk
Сортировка… Готово
Полнотекстовый поиск… Готово
chipmunk-dev/testing,unstable,stable 6.1.5-1+b1 amd64
  Fast and lightweight 2D rigid body physics library - devel

libchipmunk0d3/testing,unstable,stable 6.1.5-1+b1 amd64
  fast and lightweight 2D rigid body physics library in C

libchipmunk0d3-dbg/testing,unstable,stable 6.1.5-1+b1 amd64
  Fast and lightweight 2D rigid body physics library - debug

Они имеют что-нибудь общее?

[AlexWriter]

нет, релизы пока публикуются только на github

[gecube]

Все нормальные имена уже заняты. Ну, вы знаете примеры )))

[orcy]

По моему довольно крутая штука. Когда я изучал вопрос я находил обычно платные инструменты под Windows (LogViewer, LogViewPlus). Так что такой инструмент я думаю обязательно найдет своего пользователя.

[AlexWriter]

Спасибо

[BubaVV]

Видел, как для логов на S3 используется запрос в Snowflake. Штука упоротая и вроде как недешевая, но результат впечатляет

[cv28]

Из той же оперы: cloudvyzor.com. Зип аплоадишь и ищешь. Или указываешь внешнее хранилище с зипами (шара, S3, Azure Blob). Можно облачную версию юзать, можно скачать поставить себе (Windows, 2.5MB).

[Valsha]

есть конечно еще LogTail под Mac, вполне удобный. правда платный, но он не дорогой (пара чашек кофе)

[ilardm]

Ещё есть lnav, который достаточно лёгкий и распространённый, что бы иметь на удалённых серверах и более удобный, чем grep/sed/less magic

[ogost]

О, а вот это дельная софтина. Даже в репах дебиана есть. Спасибо.
ТС-у пожелаю сбросить пару десятков метров. Потому как в комментах уже упомянули, что тянуть логи на локалхост, или софтину на сотню метров на сервер как-то не очень хочется. А так — почему бы и нет? На первый взгляд довольно удобная штука.

[gerbert_MX]

Не слушайте этих извращенцев с консольными полурешениями, где для работы с логом тебе надо кодить прямо в консоли на баше. Ваша ситуация классика, я бы даже сказал легко-средний уровень. Средний уровень это десятки и сотни гигов логов одним файлом. А кошмарный уровень выражается в терабайтах, что раскиданы по куче разным S3 по папкам и архивам.

Во-первых нужно нормально формировать логи. Прозвучит странно, но 80% работы с разбором логов начинается с формализации логера и встраивания нормального настроенного четко под вас логера с строгими правилами как и где логируется, с какими уровнями и метками.

Во вторых уровни логирования. Для рантайм вывода хватит и ERR-уровня или даже вообще выключить (но лучше что бы было, логов много не бывает). Для потокового пишущего логера достаточно INF-уровня. А если нужно и можно (ресурсы) то фоново пишутся в файлы по DBG-уровню причем сразу уже с архивацией, ротацией по размеру и очисткой по переполнению и дате.

Кажется что 2 и 3 это одно и тоже, но это не так. Существует огромное количество нормальных агрегаторов логов, которые созданы что бы с минимумом оверхеда хранить и индексировать логи. Лично я в работе использую Loki в связке с метриками, но никто не запрещает использовать что-то другое. Самое главное в таком подходе что логи будут лететь сразу на агрегатор в базу, а не в какой-то текстовый файл с которого потом парсить (хотя Loki может и так, причем в рантайме). Особенно такой подход оцените при множестве источников логов (микросервисы или распределенная архитектура) и/или когда нужно проанализировать данные за огромный период (месяцы и года) и/или огромный массив (миллиарды точек и терабайты логов)
Тонкость в том что на агрегатор летит именно по INF. Не прям все, особенно если логи нормально описаны, но все же достуточно что бы отслеживать и детектить проблемы. А если же реально возник форсмажор то всегда есть дебаг-логи которые хранятся на месте всего за месяц или неделю, но которые максимально полные. Одна консольная команда (или прямо в каком-то интерфейсе) и мы загружаем эти логи в наш агрегатор что бы с ними работать как привыкли.

Всегда когда возникает какая-то проблема, особенно если эта проблема частая, стоит погуглить как с ней воюют другие (и проблема ли это вообще - "верх запаян, дна нет"). Возможно уже давно есть решение этих проблем. Решение которое проверенно временем и уже предвосхищает не только данную проблему но и те что возникнут потом в будущем.