SY
Size: a a a
2020 March 18
SY
Но это откровенный костыль
AB
Вот я сейчас сталкиваюсь с децентрализованой разработкой и блин столько времени прокакал уже
так это твои персональные проблемы, чо там.
ничего, за децентрализованной разработкой даже не будущее, а уже настоящее, а пользоваться докер-композом уже давно пора уметь
ничего, за децентрализованной разработкой даже не будущее, а уже настоящее, а пользоваться докер-композом уже давно пора уметь
СИ
Ну, например в ковбой пришел запрос. При обработке запроса вызывается куча функций, многие из которых что-то логгируют. Требуется идентифицировать запрос и протащить идентификатор через эти функции.
пробрасывание метаинформации лучше предусматривать сразу. причем лучше какую-нибудь сложную структуру (map). вы ведь предметную логику описываете.
в конечном счете в logger еще добавляется необходимое meta и нужно будет сделать свой форматтер, для того, чтобы в нужной форме выводить эту информацию
в конечном счете в logger еще добавляется необходимое meta и нужно будет сделать свой форматтер, для того, чтобы в нужной форме выводить эту информацию
AK
так это твои персональные проблемы, чо там.
ничего, за децентрализованной разработкой даже не будущее, а уже настоящее, а пользоваться докер-композом уже давно пора уметь
ничего, за децентрализованной разработкой даже не будущее, а уже настоящее, а пользоваться докер-композом уже давно пора уметь
Ну отлиный аргумент про персональные проблемы
AB
Получается другим процессам надо передавать отдельно идентификатор запроса?
да.
в принципе, в эрланговом мире с этим не так уж плохо, потому что запатчить, скажем, пул бд, чтобы он подхватывал мету от вызывающего - довольно несложно
в принципе, в эрланговом мире с этим не так уж плохо, потому что запатчить, скажем, пул бд, чтобы он подхватывал мету от вызывающего - довольно несложно
AB
Ну отлиный аргумент про персональные проблемы
а других проблем и не бывает, ахаха
SY
пробрасывание метаинформации лучше предусматривать сразу. причем лучше какую-нибудь сложную структуру (map). вы ведь предметную логику описываете.
в конечном счете в logger еще добавляется необходимое meta и нужно будет сделать свой форматтер, для того, чтобы в нужной форме выводить эту информацию
в конечном счете в logger еще добавляется необходимое meta и нужно будет сделать свой форматтер, для того, чтобы в нужной форме выводить эту информацию
именно
СИ
Получается другим процессам надо передавать отдельно идентификатор запроса?
а так вообще вроде простая идея - всегда знать цепочку parent у процессов и получать нужный с нужного уровня. но сам по себе pid не интересен, всё равно нужны поинформативнее данные в логе. даже для простой агрегации
но даже если такой хук можно сделать - он будет тормозить
но даже если такой хук можно сделать - он будет тормозить
AB
да.
в принципе, в эрланговом мире с этим не так уж плохо, потому что запатчить, скажем, пул бд, чтобы он подхватывал мету от вызывающего - довольно несложно
в принципе, в эрланговом мире с этим не так уж плохо, потому что запатчить, скажем, пул бд, чтобы он подхватывал мету от вызывающего - довольно несложно
потому что делать это в джави, например, будет заметно неприятнее
ML
Всем привет.
Коллеги, подскажите, как вы логгируете? Что я имею ввиду.
В книги Франческо Чезарини в своей книги про OTP рекомендует заводить некий идентификатор.
Идентификатор логически связан с конкретным запросов на сервере.
Этот идентификатор автор рекомендует протаскивать во внутренние функции, чтобы было понятно к какому запросу относится вызов функции.
Вы используете эту стратегию?
Если да, как вы ее реализуете? Это же устать можно - протаскивать идентификатор к каждой функции, которая что-то логирует.
Коллеги, подскажите, как вы логгируете? Что я имею ввиду.
В книги Франческо Чезарини в своей книги про OTP рекомендует заводить некий идентификатор.
Идентификатор логически связан с конкретным запросов на сервере.
Этот идентификатор автор рекомендует протаскивать во внутренние функции, чтобы было понятно к какому запросу относится вызов функции.
Вы используете эту стратегию?
Если да, как вы ее реализуете? Это же устать можно - протаскивать идентификатор к каждой функции, которая что-то логирует.
если есть строгое ограничение process-per-request, то это кладется в logger:set_process_metadata
ML
Получается другим процессам надо передавать отдельно идентификатор запроса?
у нас в флюссонике ещё кое где есть и возврат метаданных ответа =)
А как иначе хедеры проставлять
А как иначе хедеры проставлять
s
у нас в флюссонике ещё кое где есть и возврат метаданных ответа =)
А как иначе хедеры проставлять
А как иначе хедеры проставлять
Немного не понял, откуда возврат?
ML
Немного не понял, откуда возврат?
из функции
ML
кое где не
{ok, Result}, а {ok, Metadata, Result}s
Ну, тоже выход. Правда надо сразу проектировать формат ответов.
На счет формата ответов, я так понимаю, что в целом принята такая стратегия - если результат успешный, то возвращается кортеж {ok, Result} или {error, Reason}.
Это негласная общепринятая практика?
Потому что я слышал от некоторых разработчиков "Покажи мне, где в коде OTP возвращается кортеж {ok...}? Там сразу возвращается результат в случае успеха".
На счет формата ответов, я так понимаю, что в целом принята такая стратегия - если результат успешный, то возвращается кортеж {ok, Result} или {error, Reason}.
Это негласная общепринятая практика?
Потому что я слышал от некоторых разработчиков "Покажи мне, где в коде OTP возвращается кортеж {ok...}? Там сразу возвращается результат в случае успеха".
AK
я завел себе {err, {Code::atom(), Reason::term()}}. потому что иногда надо делать логику на Code. Просто {error, Reason} не хватает
VS
граждане из OpenCensus
пытались этот вопрос (трассировка, метрики)подвести под унификацию,
почти получилось,
теперь они OpenTracing,
переделывают заново,
может, что получится.
пытались этот вопрос (трассировка, метрики)подвести под унификацию,
почти получилось,
теперь они OpenTracing,
переделывают заново,
может, что получится.