r3code

У нас есть метрики, логи и распределенная  трассировка — 3 основных столпа наблюдаемости. Если связь логов с трейсами это просто, так как мы добавляем в логи trace_id, но с метриками такого в большинстве случаев нет. 

Однако в Prometheus сделали предложение и улучшение по поддержке exemplars — метаданные к метрике. Ребята предложили возможность добавления в метрику trace_id, сделали плагин для Grafana, который умеет показывать это и давать ссылку на переход к трейсу. 

Это умеет только Prometheus, в VictoriaMetrics эта работа стоит в беклоге.

Ниже ссылка на доклад «Deep Linking Metrics and Traces with OpenTelemetry, OpenMetrics and M3 - Rob Skillington» (2020г.)

Откуда начинать внедрять трассировку в микросервисе?

Чтобы минимальное представление иметь о работе системы хорошо иметь трейсы на всех граничных точках сервиса ( входных и выходных ). Так мы видим, через какой “порт” входят данные и через какие “выходы”  уходят. Это касается как внутренних, так и внешних сервисов. Во внутренние сервисы мы передаем трейс и вызываемый сервис встраивается в него, потому мы можем видеть вызовы через все наши сервисы. Для внешних сервисов - это позволяет отслеживать уход данных в другую систему, а также замерять задержку обработки запроса внешней системой и определять ошибки (указывает, что внешняя система сломала всю цепочку или из-за нее мы тормозим).

Пример: трейс для “входа” запрос веб-сервера или grpc-сервера, трейс для “выхода” оборачиваем http-клиент или grpc-клиент (в параметрах важно указывать имя того сервиса в котором находиться клиент, а не куда он смотрит)

Что покрывать трейсами далее?

Проблема

Попадаются иногда в очереди тикеты давно застрявшие в одном из статусов, например Need Review, и никто уж найти их не может, так как они выпали из спринта. То же самое может быть и с готовыми задачами, которые никак не попадут в статус  Released из Ready to release. Человек сам их не найдет и не вспомнит, от этого задачу могут начать решать повторно, напрасно затрачивая ресурсы.

Решение
Для поиска и уведомления о таких задачах создаем автоматизацию для проекта в Jira Cloud. Задача найти тикеты чей статус Need Review и не изменялся более 10 дней — забыли взять в код ревью. Создаем правило, которое запускаться по расписанию каждый рабочий день или 2 раза в неделю (ПН, ЧТ).
Создаем Automation: Remind about task which Needs Review more than 7d

Эта книга о жизни одного человека вплетенной в город. После прочтения захотелось туда поехать, и я там был дважды.
Больше всего запомнилось описание старых особняков ялы. И таковые там действительно еще есть.
Из книги запомнилось про продавцов сорбета, которые приезжали на место пожара в деревянных ялы -тогда это было развлечение в начале и середине 20 века.

Лет 5 назад, я прослушал аудио версию книги https://akniga.org/vern-zhyul-otkrytie-zemli - это замечательно и интересно поданная история великих географических открытий. Я будто был там!
А женщина чтец просто потрясающе передала атмосферу и энциклопедичность.
Советую всем, но детям особенно!

Это выжимка техник из книги
книги Мортимер Адлер – Как читать книги. Эта информация попадалась мне и в видео на YouTube от некоторых авторов. Замечу, эти техники применимы к добыче информации и не касаются чтения для удовольствия, когда мы читаем художественную литературу.

Техники:
0) не читаем от корки до корки, если вам нужно быстро получить информацию по конкретной теме.
1) Просматриваем быстро книгу. Листаем. Что хочу найти? Как это организовано в этой книге. Выглядит интересным? Если да - Идем дальше.
2) снимаем сливки, берем самое нужное. Читаем те куски, которые нужны прямо сейчас, пропускаем словесный мусор, вводные слова, маркетинговые куски, "воду" - все, что написал автор, чтобы сделать книгу толще
3) Интенсивно и внимательно перечитываем те же места, но захватываем окружение.
Применяя эти техники, делаем пометки в блокноте и на полях книги. Ставим закладки.
Если попалось что-то сложное, применяем бритву Окамма, перефразирует так, чтобы ребенок мог понять, в несколько подходов очищает от лишнего.

В поисках электронной версии книги “Hands-On Software Architecture with Golang. Design and architect highly scalable and robust applications using Go” by Jyotiswarup Raiturkar, которую прочел весной, наткнулся на интересный список книг. Многие из них читал сам, и часть еще на полке "прочитать".

Потому оставлю ссылку на этот полезный список https://emacsway.github.io/ru/self-learning-for-software-engineer/

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

Вопрос же в том, может ли команда возвращать как результат сущность или ее данные.

Thredotlabs в своей статье по CQRS предлагают для веб-приложений такие варианты:
1) после успешного выполнения команды на создание ресурса вернуть http код 200, далее сделать запрос на чтение этого ресурса.
2) в ответе на команду возвращать http код ответа 204 и http заголовок content-location, в котором указать адрес созданной сущности.
Как узнать ID сущности? Лучше всего сгенерировать uuid и передать прямо в запросе. Если не хотите работать с uuid, можете вернуть сгенерированный id в ответе - мир от этого не перевернется.

В блоге https://emacsway.github.io/ru/cqrs-command-and-result/#cqrs автор произвел анализ обсуждений этой темы и вот вывод:

"Итак, ответ прост - если вы не используете асинхронное исполнение Команды посредством инфраструктуры (Command Bus), то ничто не препятствует вам получить идентификатор вновь созданной записи БД в возвращаемом командой результате, и реализацию можно существенно упростить. Впрочем, возвратить результат можно даже используя Command Bus, но тут вопрос к потреблению ресурсов (все зависит от конкретного случая).

Вопрос не в том, возвращает ли команда результат (при этом нужно отличать результат от служебной информации, например, от успешности валидации и принятия команды), а в том, можно ли получить информацию о ресурсе без abstract side effect, т.е. смогут ли другие клиенты получить ту же информацию, если она им нужна."