да, в таком разрезе задача становится сложнее. для подобного кейса действительно простой фильтр-перекладывалку не написать. А валить всё в один топик — неправильно, из-за разных пачек логстешей, им придётся читать много лишнего.
У меня идея такая, что если запрос успешно завершился, то это можно понять, вычитав логи по данному запросу из кафки максимум за минуту после запроса, ведь так? Соответственно можно написать относительно простой фильтр-консьюмер, который будет фильтровать логи трассировок из входящей очереди (фильтры можно легко пошардить по reqid, чтоб можно было масштабировать по числу ядер) и перекладывать уже в очередь из которой вычитывает логстеш. Если попало под паттерн семплирования (500я ошибка/время выполнения большое/req_id кратен 1000, итд) — оставляем весь трейс, не попало — выкидываем в мусорку. ЕМНИП Cloudflare про что-то подобное рассказывали.
С другой стороны — это лишнее копирование трейсов из очереди в очередь, и я не знаю, есть ли готовые кирпичики, чтоб это быстро сделать.
А были какие-то мысли, как уменьшить количество записываемых и сохраняемых логов?
Первая мысль, которая приходит ко мне в голову — сэмплирование трассировок для проверки производительности. Раз логи проходят через кафку, то можно большую часть успешно выполненных запросов просто выкидывать (выкинуть всё межсервисное взаимодействие, логи БД итд, оставляя только запись на входящий nginx), не записывая никуда, они не очень нужны.
Не на любых смартфонах есть, зачастую там только светодиод стоит, т.е. нельзя взять и просканить неизвестный ИК-пульт.
Также большинство приложений довольно ограничены фичами.
Пожалуй соглашусь с тем, что как правило проще написать под себя маленькую обёртку в Promise над уже существующим http клиентом, чем брать библиотеку.
Но вот про то, что пятисотка от сервера и исключения из-за обращения к неопределенной переменной — это принципиально разное, не соглашусь. И то, и другое — ошибки выполнения, и те и другие нуждаются в обработке.
Сама идея промисов подразумевает, что у нас есть две цепочки выполнения кода, нормальная и обработки ошибок.
Это целый подход к потоку выполнения, и он заразен из-за асинхронной природы, т.к. расползается по всему коду — почти все места должны быть готовы к тому, что тебе из функции сразу придёт промис и нужно будет выстраивать цепочку выполнения для обработки результатов.
Здорово прочищает мозги статья Railway oriented programming, где примеры даны на F#, но во многом перекликаются с нынешней реализацией промисов.
там полгода подписки дают не на я.музыку, а весь я.плюс.
т.е. полгода 10% скидки на я.такси в комфорте.
ещё я.музыку можно юзать в оффлайне и это тоже хорошо.
в общей сложности подписочных плюшек там тысячи на две наберётся. Если грамотно абузить, то возможно побольше.
к несчастью, да. мне нужны и те, и другие.
я.карты я юзаю для навигации в россии, гуглокарты — за рубежом.
а еще, например, шаринг геопозиции в той же тележеньке не работает (по крайней мере раньше не работал) без гуглокарт.
до меня гуглокарты точно также докапываются всё время.
отключал. через полгода снова началось — галка слетела.
недавно я.карты тоже стали с этими вопросами докапываться, тоже отключил это.
Работу иногда хочется сменить и сложности с продажей/покупкой в другом районе — останавливающий фактор. в масштабах москвы жить на съёмной квартире удобнее кмк. // хотя тут вылазят другие тонкости, если ты семейный человек с детьми.
в Ижевске, в отличие от Москвы не такая плотность транспорта, даже в час пик вряд ли придётся сидеть в машине больше часа — устать от вождения просто не успеваешь.
Вне часа пик поездка через весь город занимает около получаса и довольно приятна.
в ижевске радует только то, что такси из одного конца города в другой стоит 200р, т.е. отсутствие транспорта в позднее время неприятно, но не фатально.
Хорошо, где у MS SQL транзакционный DDL?
Мне сильно нравится возможность Postgres в отдельной транзакции, никому не мешая (почти), накатить непростой апдейт на схему БД и откатиться, если что-то пойдёт не так.
для динамических массивов емнип всё равно это не помогает.
В любом случае, защита в примитивном одноразовом коде без подложенной в нужных местах соломки, скорее всего, приведёт к вылету из программы.
Наши математики очень любили объявлять внутри функции локальный статический массив для одной итерации, а потом его оттуда вернуть. Такие расчёты на сетках работали на явных методах и с треском сходили взрывались на неявных — это буквально с ума сводит людей, не понимающих модель памяти.
Строго говоря, мне неоднократно приходилось править вылетающий чужой расчетный код на Delphi именно из-за неаккуратной работы с памятью. В поведении с динамическими массивами Delphi почти ничем не отличается от C++, кстати проверка границ работает только для статических массивов и выполняется ЕМНИП только на этапе компиляции, в рантайме можно легко напороться и на use after free и на вылет за границы.
Python не очень хорош, т.к. быстро работающие расчётные библиотеки тоже могут иметь свои протекающие абстракции и взрывы из-за недостатка точности etc. Но с другой стороны, ученые уже к нему привыкли как к инструменту, могут быстро его освоить и худо-бедно читать/писать.
да, в таком разрезе задача становится сложнее. для подобного кейса действительно простой фильтр-перекладывалку не написать. А валить всё в один топик — неправильно, из-за разных пачек логстешей, им придётся читать много лишнего.
У меня идея такая, что если запрос успешно завершился, то это можно понять, вычитав логи по данному запросу из кафки максимум за минуту после запроса, ведь так? Соответственно можно написать относительно простой фильтр-консьюмер, который будет фильтровать логи трассировок из входящей очереди (фильтры можно легко пошардить по reqid, чтоб можно было масштабировать по числу ядер) и перекладывать уже в очередь из которой вычитывает логстеш. Если попало под паттерн семплирования (500я ошибка/время выполнения большое/req_id кратен 1000, итд) — оставляем весь трейс, не попало — выкидываем в мусорку. ЕМНИП Cloudflare про что-то подобное рассказывали.
С другой стороны — это лишнее копирование трейсов из очереди в очередь, и я не знаю, есть ли готовые кирпичики, чтоб это быстро сделать.
А были какие-то мысли, как уменьшить количество записываемых и сохраняемых логов?
Первая мысль, которая приходит ко мне в голову — сэмплирование трассировок для проверки производительности. Раз логи проходят через кафку, то можно большую часть успешно выполненных запросов просто выкидывать (выкинуть всё межсервисное взаимодействие, логи БД итд, оставляя только запись на входящий nginx), не записывая никуда, они не очень нужны.
Не на любых смартфонах есть, зачастую там только светодиод стоит, т.е. нельзя взять и просканить неизвестный ИК-пульт.
Также большинство приложений довольно ограничены фичами.
ИК-порт ещё, кмк, мастхэв, чтоб безобразничать с кондиционерами и телевизорами в барах =)
Пожалуй соглашусь с тем, что как правило проще написать под себя маленькую обёртку в Promise над уже существующим http клиентом, чем брать библиотеку.
Но вот про то, что пятисотка от сервера и исключения из-за обращения к неопределенной переменной — это принципиально разное, не соглашусь. И то, и другое — ошибки выполнения, и те и другие нуждаются в обработке.
Сама идея промисов подразумевает, что у нас есть две цепочки выполнения кода, нормальная и обработки ошибок.
Это целый подход к потоку выполнения, и он заразен из-за асинхронной природы, т.к. расползается по всему коду — почти все места должны быть готовы к тому, что тебе из функции сразу придёт промис и нужно будет выстраивать цепочку выполнения для обработки результатов.
Здорово прочищает мозги статья Railway oriented programming, где примеры даны на F#, но во многом перекликаются с нынешней реализацией промисов.
интересно, получится ли ловить также водителей под веществами.
а контактный телефон был указан ваш?
в природе существуют случаи, когда перекупы пытаются протащить чужое объявление и заработать денег на этом.
там полгода подписки дают не на я.музыку, а весь я.плюс.
т.е. полгода 10% скидки на я.такси в комфорте.
ещё я.музыку можно юзать в оффлайне и это тоже хорошо.
в общей сложности подписочных плюшек там тысячи на две наберётся. Если грамотно абузить, то возможно побольше.
к несчастью, да. мне нужны и те, и другие.
я.карты я юзаю для навигации в россии, гуглокарты — за рубежом.
а еще, например, шаринг геопозиции в той же тележеньке не работает (по крайней мере раньше не работал) без гуглокарт.
до меня гуглокарты точно также докапываются всё время.
отключал. через полгода снова началось — галка слетела.
недавно я.карты тоже стали с этими вопросами докапываться, тоже отключил это.
Работу иногда хочется сменить и сложности с продажей/покупкой в другом районе — останавливающий фактор. в масштабах москвы жить на съёмной квартире удобнее кмк. // хотя тут вылазят другие тонкости, если ты семейный человек с детьми.
в Ижевске, в отличие от Москвы не такая плотность транспорта, даже в час пик вряд ли придётся сидеть в машине больше часа — устать от вождения просто не успеваешь.
Вне часа пик поездка через весь город занимает около получаса и довольно приятна.
в ижевске радует только то, что такси из одного конца города в другой стоит 200р, т.е. отсутствие транспорта в позднее время неприятно, но не фатально.
если верить этому, то изменения видны ещё до коммита
https://stackoverflow.com/a/3364466/1049821
или это поведение уже изменено в более свежих версиях?
Хорошо, где у MS SQL транзакционный DDL?
Мне сильно нравится возможность Postgres в отдельной транзакции, никому не мешая (почти), накатить непростой апдейт на схему БД и откатиться, если что-то пойдёт не так.
есть. я под blackfin немного трогал 8 лет назад.
для динамических массивов емнип всё равно это не помогает.
В любом случае, защита в примитивном одноразовом коде без подложенной в нужных местах соломки, скорее всего, приведёт к вылету из программы.
Наши математики очень любили объявлять внутри функции локальный статический массив для одной итерации, а потом его оттуда вернуть. Такие расчёты на сетках работали на явных методах и с треском сходили взрывались на неявных — это буквально с ума сводит людей, не понимающих модель памяти.
Строго говоря, мне неоднократно приходилось править вылетающий чужой расчетный код на Delphi именно из-за неаккуратной работы с памятью. В поведении с динамическими массивами Delphi почти ничем не отличается от C++, кстати проверка границ работает только для статических массивов и выполняется ЕМНИП только на этапе компиляции, в рантайме можно легко напороться и на use after free и на вылет за границы.
Python не очень хорош, т.к. быстро работающие расчётные библиотеки тоже могут иметь свои протекающие абстракции и взрывы из-за недостатка точности etc. Но с другой стороны, ученые уже к нему привыкли как к инструменту, могут быстро его освоить и худо-бедно читать/писать.
ну вот примерно об этом и речь.