[1/x] Как сделать правильное логгирование
Разрозненные логи довольно сложно анализировать, поэтому первое что надо сделать — это пробрасывать в логи сквозной идентификатор.
Проще объяснить по картинке: trace_id — это сквозной идентификатор, который либо передаётся на вход в вашу систему, которая первая принимает вызов от других систем вне контура либо от пользователя. Если на вход не передан trace_id, то система A его генерирует и дальше сохраняет в каждой записи своего лога и передает в вызовах в другие системы (B, C, D и E).
trace_id удобно сделать GUID'ом, для экономии места убрать дефисы. На входе проверять, что trace_id — это валидный гуид, и норм. Если не валидный — генерировать свой.
При возврате ответа на синхронный вызов система A (и другие, которыми вы управляете) должна вернуть значение trace_id, который использовался в ходе обработки вызова.
Применение
Тестировщик проверяет вашу систему, вызывает постманом один из эндпоинтов. Получает в ответе trace_id, и по нему ищет в GrayLog или ELK все записи, относящиеся к этой операции. Особенно это удобно, когда задействовано несколько систем и логи сохраняются в общее хранилище; если у вас нет центрального хранилища логов, то самое время его завести.
Как передавать и как возвращать
Можно в теле запроса и ответа, можно в HTTP-заголовках. Обычно я проектирую исходя из привычек команды и стиля, принятого на проекте. Если стиля никакого нет — то прививаю :)
trace_id можно передавать и в сообщениях через брокер, хотя тимлиды и архитекторы иногда сопротивляются, мол, лишнее, есть и технические заголовки. Я обычно выслушиваю киваю, и делаю по-своему (если хватает полномочий).
А что там за span_id такой
Этот параметр похитрее, удобен если в контуре несколько (много) систем, которые вызывают друг друга разными хитроумными способами. Тогда первая система, обрабатывающая вызов, генерирует span_id равный нулю «0». При вызове других систем эта первая система A добавляет к span_id порядковый номер вызова, начиная с «1».
Проще опять по картинке понять: получается что в логе вы увидите что-то вроде «0.4.2» и сможете понять, что запись сделала третья система в цепочке, но вызвана она была далеко не первой по порядку обработки.
Подробнее об этой технике можно почитать например в документации OpenTelemetry. Если заморочиться, то можно даже визуализировать такие вызовы в дерево и осчастливить техподдержку. Им и так нелегко разгребать всё это.
#логгирование
Разрозненные логи довольно сложно анализировать, поэтому первое что надо сделать — это пробрасывать в логи сквозной идентификатор.
Проще объяснить по картинке: trace_id — это сквозной идентификатор, который либо передаётся на вход в вашу систему, которая первая принимает вызов от других систем вне контура либо от пользователя. Если на вход не передан trace_id, то система A его генерирует и дальше сохраняет в каждой записи своего лога и передает в вызовах в другие системы (B, C, D и E).
trace_id удобно сделать GUID'ом, для экономии места убрать дефисы. На входе проверять, что trace_id — это валидный гуид, и норм. Если не валидный — генерировать свой.
При возврате ответа на синхронный вызов система A (и другие, которыми вы управляете) должна вернуть значение trace_id, который использовался в ходе обработки вызова.
Применение
Тестировщик проверяет вашу систему, вызывает постманом один из эндпоинтов. Получает в ответе trace_id, и по нему ищет в GrayLog или ELK все записи, относящиеся к этой операции. Особенно это удобно, когда задействовано несколько систем и логи сохраняются в общее хранилище; если у вас нет центрального хранилища логов, то самое время его завести.
Как передавать и как возвращать
Можно в теле запроса и ответа, можно в HTTP-заголовках. Обычно я проектирую исходя из привычек команды и стиля, принятого на проекте. Если стиля никакого нет — то прививаю :)
trace_id можно передавать и в сообщениях через брокер, хотя тимлиды и архитекторы иногда сопротивляются, мол, лишнее, есть и технические заголовки. Я обычно выслушиваю киваю, и делаю по-своему (если хватает полномочий).
А что там за span_id такой
Этот параметр похитрее, удобен если в контуре несколько (много) систем, которые вызывают друг друга разными хитроумными способами. Тогда первая система, обрабатывающая вызов, генерирует span_id равный нулю «0». При вызове других систем эта первая система A добавляет к span_id порядковый номер вызова, начиная с «1».
Проще опять по картинке понять: получается что в логе вы увидите что-то вроде «0.4.2» и сможете понять, что запись сделала третья система в цепочке, но вызвана она была далеко не первой по порядку обработки.
Подробнее об этой технике можно почитать например в документации OpenTelemetry. Если заморочиться, то можно даже визуализировать такие вызовы в дерево и осчастливить техподдержку. Им и так нелегко разгребать всё это.
#логгирование