зашейдить в libraryDependencies?

т.е. пометить provided

через dependencyTree найти кто его тащит и сделать .exclude

мда. приется ловить как то в dep Tree :\ видимо каждому это рано или поздно приходится делать

у меня тут беда которую я не помню как решать) при сборке Fat Jar'a есть конфликт на "org.slf4j" deduplicate: different file contents found in the following [error] ~/.ivy2/cache/org.slf4j/slf4j-api/jars/slf4j-api-1.7.22.jar:org/slf4j/spi/MarkerFactoryBinder.class [error] ~/.ivy2/cache/com.typesafe.play/shaded-asynchttpclient/jars/shaded-asynchttpclient-1.0.0-M6.jar:org/slf4j/spi/MarkerFactoryBinder.class какую магию надо написать в assembly что вылечить? :\ assemblyMergeStrategy in assembly := { case PathList("org", "slf4j", _) => MergeStrategy.first } не спасает :\

матчер надо править. например xs @ _* вместо _. иначе он не всё ловит

матчер надо править. например xs @ _* вместо _. иначе он не всё ловит

вот она - истинная магия! спасибо )

помогло ?

Привет, Объясните пожалуйста, ну или в спеку ткните, в чем причина компиляции выражения скалы в следующий JVM байткод: Scala: val numNames = Array("zero", "one", "two") байткод: ... 51: aastore 52: checkcast #85 // class "[Ljava/lang/Object;" 55: checkcast #86 // class "[Ljava/lang/String;" 58: putfield #61 // Field numNames:[Ljava/lang/String; Если class открыть Java Decompiler то увидим это: this.numNames = ((String[])new String[] { "zero", "one", "two" }); Т.е. зачем вот эти касты? Я из .NET мирка, слышал что JVM имеет очень богатый набор оптимизаций и тут может одна из них и будет, но назначение мне так и не понятно.

так скаловский Array же дженерик, вот он и кастит, как и для любого другого дженерика

Скала создает массивы неэффективно. Это не равнозначные выражения. Если я ничего не путаю, сначала сдается массив который оборачивается во wrappedarray, потом поля из него переписываются в новый массив поэлементно. Касты из за тайп эрежа.

Скала создает массивы неэффективно. Это не равнозначные выражения. Если я ничего не путаю, сначала сдается массив который оборачивается во wrappedarray, потом поля из него переписываются в новый массив поэлементно. Касты из за тайп эрежа.

ага, а еще скала-компилятор думает что слишком умен, и когда ты пишешь обычный ArrayList, и потом делаешь в него add несколько раз, скала-компилятор это "оптимизирует" в Arrays.asList, думая что он самый хитрый

Я тут подумал еще, почему бы не отдавать сразу вроппедаррай? Наверно я все же что-то путаю.

Я тут подумал еще, почему бы не отдавать сразу вроппедаррай? Наверно я все же что-то путаю.

Это не как с JavaConverters, когда он создает невидимую обертку, которую из кода не видно, а в рантайме очень даже? Это мешает при всяких сериализациях-десериализациях

Спасибо большое, совсем забыл про type erasure в JVM, теперь понятно почему и зачем

Вот эти type erasure и обилие invokevirtual после CLR уж очень смущают

Я конечно понимаю, что последние будут заменены на invokespecial, но всё равно не по себе

Изучение Scala видимо будет очень увлекательным

Спасибо большое, совсем забыл про type erasure в JVM, теперь понятно почему и зачем

Тут ещё интересно, что как раз массив - это тот тип в jvm, который не совсем стирает типы

так скаловский Array же дженерик, вот он и кастит, как и для любого другого дженерика

Это же не совсем так. Массивы примитивов не дженерики. Они хранят значения и знают что именно они хранят. Скала с ними ничего не делает без необходимости. Это все также плейн жвм массивы. В случае не примитива они хранят ссылки, но при этом массивы в жвм также единственные кто знает componentType в рантайме

Почему-то создатели java посчитали, что здорово бы сделать массив ковариантным, а если после успешного апкаста ты попытаешься положить туда ссылку на супертайп, у тебя будет рантайм еррор

В скала массив вернули в инвариантную форму

Видимо, в связи с этим обвешали кучей проверок на каждое присвоение

создатели java осознали проблему давно, но как обычно ничего не могут с этим сделать из-за обратной совместимости

из этой серии был еще доклад Шипилева о String compaction грядущем, где тоже пришлось пойти на жертвы ради совместимости

ну , кстати, в дотнете скопировали и array covariance

Это же не совсем так. Массивы примитивов не дженерики. Они хранят значения и знают что именно они хранят. Скала с ними ничего не делает без необходимости. Это все также плейн жвм массивы. В случае не примитива они хранят ссылки, но при этом массивы в жвм также единственные кто знает componentType в рантайме

скала Array в компайлтайме дженерик, я вот о чем, у него и сигнатура Array [T], при компиляции он, понятное дело, переводится в обычный массив, который не дженерик

так что здесь не должно быть недопонимания

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

Так логатеш парсит твои логи в кибану и вытаскивает заданные параметра

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

Зависит от того, что ты используешь для хранения логов. Можно писать логи в json и потом отдавать логстэшу сразу в json

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

классный вопрос. Думаю, просто не было хорошей либы, чтобы всех убедить

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

потому, что кто-то держится за историю. а раньше часто было так, что из подручных инструментов были только текст вьюверы) я уже давно начал переходить на структурированное хранение)

Пока что у нас тут юникс головного мозга

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

в нагруженном приложении с достаточно подробным логированием тебе точно этого не захочется делать

Так логатеш парсит твои логи в кибану и вытаскивает заданные параметра

Это я и имею в виду под постобраболткой.

в нагруженном приложении с достаточно подробным логированием тебе точно этого не захочется делать

Мне кажется, ровно наоборот

классный вопрос. Думаю, просто не было хорошей либы, чтобы всех убедить

Это можно делать уже сейчас, у меня на старом проекте все логировалось кейс классами

логи часто являются узким местом и режут их количество

Ну ок, посмотрю как вы без грепа там будете по своим деревьям лазать

Мне кажется, ровно наоборот

именно! Структурированное хранение - не означает жесткую структуру хранения. Но некоторые не понимают этого)

И в кибане можно было делать волшебные выборки

И в кибане можно было делать волшебные выборки

Я в скале могу любые выборки делать какие захочется)

Ну ок, посмотрю как вы без грепа там будете по своим деревьям лазать

Дерево всегда легко превращается в список. Обратно сложнее

а еще можно сразу отправлять логи в какой-то сервис, если есть соотвествующий апендер. Я видел для всяких агрегаторов такие апендеры

Которые и не снились скулю)

Я в скале могу любые выборки делать какие захочется)

Причем тут это? Я про логи

а еще вам спасибо в ETL отделе скажут за очередной формат, который потребует постобработки на их стороне

Ну ок, посмотрю как вы без грепа там будете по своим деревьям лазать

греп??? на дворе же логстэшспланкигрейлог пробил

пробил дно

греп??? на дворе же логстэшспланкигрейлог пробил

Ну это кстати да. docker logs mycontainer | grep myrequestid. Это удобно

Ну если один сервис запущен то и греп ок

Причем тут это? Я про логи

и я про логи. выборки в кибане используют те же принцицы, что и скуль - но они слишком примитивны (даже по сравнению со скулем). а некоторые вещи и вовсе не возможно провернуть

Ну ок

Ребят. Филосовский вопрос за жизнь. Объясните дураку, почему логи это все еще длинные списки строк? Почему их постобработкой превращают во что-то удобоваримое вместо того что бы сразу делать их в виде деревьев, с выносом метаданных из сообщения?

У разработчиков systemd в своё время возник тот же вопрос

греп??? на дворе же логстэшспланкигрейлог пробил

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

а еще вам спасибо в ETL отделе скажут за очередной формат, который потребует постобработки на их стороне

за структурированное хранение - именно, что скажут. потому что им не нужно будет делать постобработку вобще. при правильном подходе - это просто структурированные деревья примитивов и списков - и обращаться сразу к нужным полям - сказка. как раз таки строки и требуют постобработки

и я про логи. выборки в кибане используют те же принцицы, что и скуль - но они слишком примитивны (даже по сравнению со скулем). а некоторые вещи и вовсе не возможно провернуть

ты логстэшем можешь в реляционную базу логи закидывать, вопрос только в том как ты будешь их структурировать для него. в elasticsearch можно подтюнить indeces, чтобы данные были в более подходящим формате для запросов, достаточно настроить темплейты

ты логстэшем можешь в реляционную базу логи закидывать, вопрос только в том как ты будешь их структурировать для него. в elasticsearch можно подтюнить indeces, чтобы данные были в более подходящим формате для запросов, достаточно настроить темплейты

реляционку для логов? ухахашки)

вопрос только потребностей

если часть логов имеет жесткую структуру и важны для кого-то, например для аналитики, то почему бы и нет. Иногда лучше так, чем ковыряться с другими вариантами хранения и обработки.

мне не нужны реляционки. как только я пишу log (Item0(name = "dsada", dd=5, gg="dqweqweq", wewe=now()), log(Item1(name="dsada", person="eqweq", id=4343343)) - я их спокойно могу в один стрим сохранить и без всяких проблем построить любой индекс (даже тот который не предусмотрен хранилищем) по подмножеству и тюнить их как угодно - никакая постобработка не нужна.

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

Часто (почти всегда) в месте логирования уже есть нужные структуры, так что производительность не должна страдать

Вопрос защитникам текстовых логов. Как у вас дела с логированием бинарных данных?

если часть логов имеет жесткую структуру и важны для кого-то, например для аналитики, то почему бы и нет. Иногда лучше так, чем ковыряться с другими вариантами хранения и обработки.

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

Вопрос защитникам текстовых логов. Как у вас дела с логированием бинарных данных?

И кейсклассов на 50 полей.

ERROR: S client not available

И кейсклассов на 50 полей.

кейс класс на 50 полей конечно говно. но даже при таком варианте это гораздо лучше чем "field0=${field0}, ..... fieldN=${fieldN}". ))

кейс класс на 50 полей конечно говно. но даже при таком варианте это гораздо лучше чем "field0=${field0}, ..... fieldN=${fieldN}". ))

Обоснуй, почему говно.

Обоснуй, почему говно.

Я не отрицаю, что может быть какая-то примитивная структура у которой вот есть прям зафиксированный в бумажном госте список характеристик - которые совершенно бесполезно дробить на структуры. Но в абсолютном большинстве гораздо грамотнее использовать декомпозицию полей и композицию сущностей. Item ( field0 = Item1 (несколько полей), field1 = Item2 ( field 0 = Item 3 ))

Я не отрицаю, что может быть какая-то примитивная структура у которой вот есть прям зафиксированный в бумажном госте список характеристик - которые совершенно бесполезно дробить на структуры. Но в абсолютном большинстве гораздо грамотнее использовать декомпозицию полей и композицию сущностей. Item ( field0 = Item1 (несколько полей), field1 = Item2 ( field 0 = Item 3 ))

не использовал подобное (в т.ч. для Scala), но вопрос у меня как это будет влиять на allocation rate, когда создаем много классов для логов. всё-таки может дать ощутимую нагрузку на GC.

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

Обычно делали как: описываются форматы логов, которые нужны, к ним лепится "тег" по тегу logstash смотрит что за тег и под него использует нужный парсер и индекс, т.к. логстеш на отдельных серверах влияние на производительность небольшое

не использовал подобное (в т.ч. для Scala), но вопрос у меня как это будет влиять на allocation rate, когда создаем много классов для логов. всё-таки может дать ощутимую нагрузку на GC.

никак. у них микролайф - тебе хватит)

Обычно делали как: описываются форматы логов, которые нужны, к ним лепится "тег" по тегу logstash смотрит что за тег и под него использует нужный парсер и индекс, т.к. логстеш на отдельных серверах влияние на производительность небольшое

Потом это повторяют 50 раз, рефакторят код и получают regex hell

Обычно делали как: описываются форматы логов, которые нужны, к ним лепится "тег" по тегу logstash смотрит что за тег и под него использует нужный парсер и индекс, т.к. логстеш на отдельных серверах влияние на производительность небольшое

как делает большинство - и так все знают. это не значит, что вис из харашо ))

Потом это повторяют 50 раз, рефакторят код и получают regex hell

как-то не вызывало проблем. Есть общие логи, есть с более специфичным форматом, все это направляется в elasticsearch

как-то не вызывало проблем. Есть общие логи, есть с более специфичным форматом, все это направляется в elasticsearch

Зависит от проекта

Плоха сама идея писать что-то в одном месте, а в другом месте разбирать это по спекам. Мало того, что добавляется ещё одна система для сопровождения, так ещё есть риск пропустить что-то важное в промежутке между обновлениями формата логов и парсеров на принимающей стороне

Конечно же, это компенсируется написанием тестов для логов ? Хоть где-то фри монады пригодятся

Плоха сама идея писать что-то в одном месте, а в другом месте разбирать это по спекам. Мало того, что добавляется ещё одна система для сопровождения, так ещё есть риск пропустить что-то важное в промежутке между обновлениями формата логов и парсеров на принимающей стороне

в большой конторе с кучей разных потребителей ты так или иначе вляпаешься (или не ты но хранилище) например, у нас бизнес аналитики любят юзать сас (ладно, не умеют ничего прочего, а уволить сразу всех нельзя) и толку что я логировал ассоциативные массивы, если их ентерпрайзный комбайн не умеет с ними работать etl сидит и разбирает эту структуру и добавляет (по запросу!) новые поля при необходимости, чтобы сранный сас с этим мог работать я не противник бинарного хранения и тем более структурированного, но в мире где еще живы 300 диалектов кобола, нереально (повсеместно) перейти на что-то иное чем тупо строки

черт, глаз прям задергался, как вспомнил

Плоха сама идея писать что-то в одном месте, а в другом месте разбирать это по спекам. Мало того, что добавляется ещё одна система для сопровождения, так ещё есть риск пропустить что-то важное в промежутке между обновлениями формата логов и парсеров на принимающей стороне

можно в одном месте писать что-то и дописывать к нему спеку ( Avro )

в большой конторе с кучей разных потребителей ты так или иначе вляпаешься (или не ты но хранилище) например, у нас бизнес аналитики любят юзать сас (ладно, не умеют ничего прочего, а уволить сразу всех нельзя) и толку что я логировал ассоциативные массивы, если их ентерпрайзный комбайн не умеет с ними работать etl сидит и разбирает эту структуру и добавляет (по запросу!) новые поля при необходимости, чтобы сранный сас с этим мог работать я не противник бинарного хранения и тем более структурированного, но в мире где еще живы 300 диалектов кобола, нереально (повсеместно) перейти на что-то иное чем тупо строки

Да, инструментов нет. А уж о принятии стандартов и речи не идёт

если Avro схему обогатить текстовыми (а то и html) шаблонами для отображения получится идеальный протокол для логов

аналитик работает с массивом данных, ему пофиг на отдельные записи

конкретно в том месте не авро, но очень похожий самопал

проблема то не там проблема в том, что это никак не уменьшило работы другому отделу

проблема то не там проблема в том, что это никак не уменьшило работы другому отделу

но ведь в авро принимающей стороне не нужно думать о том, какие добавились поля

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

но ведь в авро принимающей стороне не нужно думать о том, какие добавились поля

нужно, когда она готовит данные для другого клиента, у которого весьма убогие возможности по работе со структурами

нельзя вот так автоматом добавить еще одну колонку в сас, исходя из входных данных

нужно, когда она готовит данные для другого клиента, у которого весьма убогие возможности по работе со структурами

это выходит за разговор о логах

разговор о логах был в контексте необходимой постобработки в другой системе

Ох нифига у вас тут темы

Бинарные данные логируете)

если Avro схему обогатить текстовыми (а то и html) шаблонами для отображения получится идеальный протокол для логов

И это отлично работает с Hadoop

Причём тут хадуп то вообще?

разговор о логах был в контексте необходимой постобработки в другой системе

да но это уже не пост-обработка, это уже использование постобработанных данных для выгрузки в третью систему. Конкретно о постобоаботке для экстракции в avro думать не нужно