ElasticSearch ради логов?
Ну как бе можно, но это типа карьерного экскаватора, когда мне нужен траншеекопатель
простите вам логи "зачем"?
чтобы по ним потом искать и структурировать как то ??
ну так вот монга это будет делать через aggregation framework ХУЖЕ чем Elastic
Slach
Мерль
У меня вопрос в другом:
делать ли это изнутри приложения или снаружи как-то ловить выхлоп, разбирать его и пихать в СУБД?
Мерль
простите вам логи "зачем"?
чтобы по ним потом искать и структурировать как то ??
ну так вот монга это будет делать через aggregation framework ХУЖЕ чем Elastic
Зато ES будет гарантировано дороже
Для меня это важнее
Slach
делать ли это изнутри приложения или снаружи как-то ловить выхлоп, разбирать его и пихать в СУБД?
если приложение на GO возьмите нормальную какую то либу , у которой логи асинхронные
https://github.com/sirupsen/logrus
и логируйте сразу куда надо
Slach
Зато ES будет гарантировано дороже
Для меня это важнее
в каком плане "дороже"?? ;) память и монга и еластик жрут как не в себя
Мерль
в каком плане "дороже"?? ;) память и монга и еластик жрут как не в себя
По деньгам, лол
У меня есть две коробки "забесплатно", на которых у нас всё крутится
И если я сейчас скажу, что-то типа "давайте купим кусок облако под логи", это будет ну такое
Мерль
если приложение на GO возьмите нормальную какую то либу , у которой логи асинхронные
https://github.com/sirupsen/logrus
и логируйте сразу куда надо
Ну ты как бы понимаешь, что:
a) меня не особо интересует библиотека для логирования
б) проблема не в библиотеке для логирования?
:3
Slach
По деньгам, лол
У меня есть две коробки "забесплатно", на которых у нас всё крутится
И если я сейчас скажу, что-то типа "давайте купим кусок облако под логи", это будет ну такое
простите причем тут "облако"?
apt-get install elasticsearch
делается почти в слепую
но в целом надо было сразу сказать "у нас уже есть Монга, мы хотим срать в нее еще и логами"
=) это нормальное желание
если у вас в монге уже какие то данные и вы знаете как бороться с ее недостатками
то бороться с недостатками эластика вам абсолютно незачем =)
Slach
и соответсвенно городить инфраструктуру по "доставке логов" в монгу смысла нету...
https://github.com/weekface/mgorus
этого вполне будет достаточно =)
Мерль
простите причем тут "облако"?
apt-get install elasticsearch
делается почти в слепую
но в целом надо было сразу сказать "у нас уже есть Монга, мы хотим срать в нее еще и логами"
=) это нормальное желание
если у вас в монге уже какие то данные и вы знаете как бороться с ее недостатками
то бороться с недостатками эластика вам абсолютно незачем =)
мдааа
У меня почему-то сейчас в голове скрестились elastic search и elastic storage
Мерль
и соответсвенно городить инфраструктуру по "доставке логов" в монгу смысла нету...
https://github.com/weekface/mgorus
этого вполне будет достаточно =)
Ладно, вы не совсем поняли мой вопрос ^3
Но спасибо за усердие
Slach
дак вроде понял =)
вопрос дословно был
плохо ли писать изнутри приложения логи в монгу?
ответ
если монга в проекте уже есть
если умеете бороться с ее недостатками
если сможете потом писать запросы на поиск по этим логам
если приложение на GO
тогда НЕТ, не плохо, ОЧЕНЬ ХОРОШО и вполне разумно
или под логами имеется ввиду не логи приложения
а некие write once данные ?
Slach
IMHO наверное стоит подумать не только над тем как писать логи
но и что потом с ними надо делать ПОТОМ и каким именно образом
и от этого уже отталкиваться
Мерль
Вопрос был в следующем: "плохо ли возлагать ответственность по записи логов в СУБД (наверное зря сделал акцент на монгу) на само приложение, а не перехватывать его вывод, как-то агрегировать, обрабатывать снаружи и только потом класть в СУБД? ".
То есть по сути, стоит ли мне разделять обязанности?
Я повторюсь, несмотря на то, что я упомянул монгу, проблема вовсе не стоит в выборе СУБД, как и в выборе пакета для логов, а так же формата логов.
Проблема именно в следующем: должно ли приложение само отвечать за запись логов в субд?
nvkv
Мерль, ты про 12 factor app слышал?
nvkv
Идеальный вариант это когда приложение пишет лог в stdout
nvkv
А дальше ты уже решаешь, что с ним делать
Slach
если так ставить вопрос, тогда ДА, надо разделять и отдельный "доставщик" снаружи приложения
nvkv
Заруливаешь его в бд, вроде эластика, или пишешь в файл или ещё что
nvkv
В общем приложение не должно париться о персистентности логов
nvkv
Его задача лог сгенерировать максимально простым способом
Мерль
Спасибо
Примерно это я и хотел услышать
Мерль
(А что касается mongodb - то в данном случае асбсолютно эквиписуально, это дело всё равно потом раз в неделю анализирует специально обученный скрипт, который выставляет регулировки термостата и прочей херни)
nvkv
Изопенисуально говорить надо
nvkv
Будто теоркат не учил!
Мерль
Не у учил, и ваще, бурбакисты не нужны и должны страдать!
nvkv
Мерль
Ещё один роутер, да сколько можно
https://violetear.org/
ainu
Посмотрим
ainu
Смотрел я на fasthttp, такая шляпа
ainu
В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10
ainu
И стартует медленно
ainu
И игнорит некоторые http заголовки
igor
Смотрел я на fasthttp, такая шляпа
я не смотрел его исходники, в чем там прикол? он на си вызовах?
ainu
Он не использует map[], он использует []byte вместо string
ainu
В заголовке даты последнего изменения статического файла отдавал утреннее время в 12 дня. Хотя файл менялся часто
Kirill
Он не использует map[], он использует []byte вместо string
а ты не думал, что именно поэтому он работает адекватно?
ainu
Одно дело скорость она есть не спорю
ainu
За счет []byte и так далее
ainu
Другое дело время компиляции - оно выше сильно.
ainu
Другое дело некая бажность. Его задачей было отдавать js файл, скомпиленный вебпаком.
ainu
Он отдавал заголовки заставляющие браузер кешировать. При этом иногда отдавал пустой файл.
Kirill
В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10
ты явно написал крайнюю дичь.
ainu
Причем датой изменения ставит левую дату. Что мешает отладке.
Kirill
Он отдавал заголовки заставляющие браузер кешировать. При этом иногда отдавал пустой файл.
ты что, в инспекторе смотрел, что ли?
ainu
В инспекторе заголовок даты изменения, да. Обычный заголовок, любой http сервер его отдвет
ainu
Через stx.response.header.set можно поставить pragma: no csche
ainu
Но дата будет скакать, неизменная
ainu
Т.е. не поставить допустим далекое прошлое чтобы запретить кеширование
Kirill
Смотрел я на fasthttp, такая шляпа
ну — что я тебе скажу. у меня весь прод на fasthttp и ни одной проблемы с ним не было. ты написал полную дичь, которая работает неадекватно, так что не надо втирать людям что то, в чем ты не разобрался настолько, что не смог отдать файлик — шляпа.
Kirill
другой вопрос — покажи конкретно код, который ты написал и используемый коммит fasthttp, как и git status в нем.
ainu
Мне как бы все равно у кого что на прод работает
ainu
Я заменил на net/http и кейс ctrl + s, alt + tab, f5 стал работать в 100% случаев, а не 95.
Kirill
ainu
Но так как такая движуха, я подниму старую версию, и сделаю воспроизведение того, про что говорю
ainu
Суть простая там сервинг одного статического файла, яваскрипт скомпиленный вебпаком
ainu
Мы же говорим про https://github.com/valyala/fasthttp ?
Yura
В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10
А на хрена ж вы fasthttp для страничек используете? Он для API, а не для полновесных страниц.
Kirill
А на хрена ж вы fasthttp для страничек используете? Он для API, а не для полновесных страниц.
у меня там и полновесные страницы
Yura
у меня там и полновесные страницы
Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README:
net/http handles more HTTP corner cases.
И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках?
А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.
Yura
Повторюсь: я могу быть не прав.
Yura
Все уже видели? http://www.tapirgames.com/blog/golang-syntax-sugars-and-exceptions
Kirill
Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README:
net/http handles more HTTP corner cases.
И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках?
А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.
отличие слишком значительное. поэтому пилю свой фреймворк на fasthttp и пилю на нем всё подряд. но, опять же, публичная версия отстает от моей.
Nikolay
Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README:
net/http handles more HTTP corner cases.
И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках?
А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.
разделяю твое мнение частично. для api стоит использовать в случаях высокой нагрузки ради экономии ресурсов, времени и то без фанатизма, чтобы не заниматься преждевременной оптимизацией. в остальных случаях смысла не вижу брать это. Отдавать статику, странички и прочее лучше через штатный http - там хоть http2 есть, кроме этого много сторонних библиотек и фреймворков используют штатный. Лично я брать это буду в крайнем случае, когда приспичит и не смогу ни горизонтально отмаштабироваться и ничего другого, когда трата времени на использование этой штуки и всех рисков с этим связанных будет оправдана. А так когда работы мало, а времени много можно брать и это, писать свои фреймворки поверх и пилить на нем все подряд, замеряя наносекунды и радуясь как все быстро, только как правило задержки на сети, на базе и тд на практике съедают больше времени чем реализация http и разницы там использовать http или fasthttp особо то и никакой.
Kirill
разделяю твое мнение частично. для api стоит использовать в случаях высокой нагрузки ради экономии ресурсов, времени и то без фанатизма, чтобы не заниматься преждевременной оптимизацией. в остальных случаях смысла не вижу брать это. Отдавать статику, странички и прочее лучше через штатный http - там хоть http2 есть, кроме этого много сторонних библиотек и фреймворков используют штатный. Лично я брать это буду в крайнем случае, когда приспичит и не смогу ни горизонтально отмаштабироваться и ничего другого, когда трата времени на использование этой штуки и всех рисков с этим связанных будет оправдана. А так когда работы мало, а времени много можно брать и это, писать свои фреймворки поверх и пилить на нем все подряд, замеряя наносекунды и радуясь как все быстро, только как правило задержки на сети, на базе и тд на практике съедают больше времени чем реализация http и разницы там использовать http или fasthttp особо то и никакой.
в целом соглашусь, но мне проще так — я так могу код спокойно переиспользовать между проектами и не париться о переносе
Anonymous
Доброе утро)
Как поведут себя тысячи спящих горутин?
Я создаю горутину, ложу её в сон на NN минут.
Через NN минут горутина должна удалить объект, если он не удален ранее.
Или какой есть еще способ отслеживания жизнь кучи объектов поминутно?
Anonymous
Другой способ - для кучи создать доп. поле с датой "когда удалить". Далее таймером перебирать допустим, каждые 5 сек, все объекты и смотреть дату.
Anonymous
Даже если поставить перебор каждую минуту - неужели будет ефективней перебор тысячи объектов, чем запускать горутины, которые должны будут удалять через НН минут объект?
Anonymous
Я просто предложил другой способ, об эффективности не знаю...
Nikolay
Даже если поставить перебор каждую минуту - неужели будет ефективней перебор тысячи объектов, чем запускать горутины, которые должны будут удалять через НН минут объект?
перебор эффективней. но, чтобы не делать перебор я делал несколько иначе в похожей задачке
Nikolay
Anonymous
конечно интересно
Yura
А почему не добавлять элемент в список (слайс) со временем удаления? Как я понимаю, время удаления будет монотонно расти. Тогда одной горутиной можно спокойно этот список обрабатывать.
Также можно тупо использовать time.AfterFunc .
Yura
Но таймер - это на случай, если время удаления растет не монотонно. В монотонном случае список лучше.
Nikolay
конечно интересно
для своей задачи, хоть она и отличается несколько от твоей я делал следующее: взял обычную реялизацию сбалансированного дерева, описал функцию сортировки дерева (дерево хранится всегда в отсортированном виде) в которой у меня было несколько полей еще кроме времени - фактически ключ индекса был составной. так вот тк дерево отсортировано встаем в начало дерева и берем первый элемент - если время пришло то удаляем его из дерева, если не пришло то дальше и не бежим по дереву а спим какое-то время. можно прибить эту горутину которая это делает к системному треду с помощью LockOSThread чтобы не думать что где-то что-то затупило и горутинка не проснулась во время после сна, но и плюсом я делал очень просто: бежал по дереву до тех пор пока время «протухания» было истинным, но это нужно если время сна например 5сек а обьекты могут протухать с частотой в 1 сек.
Nikolay
из минусов мы имеем более долгие операции вставки, удаления и тд с деревом если сравнивать с слайсом, но если нужена конкурентная вставка и большого кол-ва а-ля сотни-миллионы, то это работает