Трейсинг и логирование это немного разные инструменты, которые отлично работают в симбиозе друг с другом.
Как правило логи используют для того, чтобы сообщить о том, что случилось какое-то "специальное событие": ошибка / warning / etc. К этому событию прикрепляют какие-то полезные поля для его идентификации, некоторые атрибуты и понятное описание того, что случилось.
Трейсинг же можно использовать, чтобы отслеживать все точки системы, по которым прошёл запрос. И это очень удобно в большой распределенной архитектуре, когда один человек буквально не может разбираться в логике всех сервисов, присутствующих в системе. А ведь количество сервисов в системе может измеряться тысячами... можно представить, насколько много получится уникальных цепочек обработки запроса.
Зато этот человек может в тех же самых логах найти информацию о том, что его сервис отправил запрос в другой сервис, и в ответ получил какую-то ошибку. Он может посмотреть на ID этого запроса и отследить весь его путь. Увидеть, что запрос был отправлен из сервиса A в его сервис B, после чего было много обращений в сервис C, и дальнейшая обработка запроса по пути сервисов D -> E -> F -> ..., пока запрос не дошёл до субд, которая не смогла выполнить запрос, потому что в этот момент вышел из строя старый лидер субд.
Если в системе есть некоторый платформенный слой для проксирования всех запросов (например, запросы перехватываются с помощью прокси сайдкаров, устанавливаемых рядом с каждым сервисом), можно довольно дешёво начать отслеживать все трейсы в системе. И когда разработчики будут менять / добавлять новые обработчики запросов, им не придется думать о том, что нужно не забыть написать логи, чтобы можно было в дальнейшем отслеживать цепочки запросов. А если есть большое наследие, которое сделали 10 лет назад, и никто тогда не думал о том, чтобы нужно логировать что-то? Насколько дорого будет пойти и добавить везде логирование?
Логи пишут, когда разработчик решил, что в этом месте будет полезно что-то залогировать, чтобы иметь дополнительный контекст. Трейсинг спаны пишут всегда (по модулю семплирования).
Да, можно добавить логирование на прокси, обрабатывающих трафик, и сделать какие-то общие entry-point'ы в приложении, которые будут писать логи при поступлении нового запроса. Добавить в эти логи некоторый request_id, единый в рамках одного запроса, и начать прокидывать этот request_id. Подключить к этому всему сквозной поиск в системе по request_id и решить задачу с помощью логирования. Так действительно можно сделать, но в итоге получится, что вы переизобрели трейсинг.
Как уже было упомянуто, логи и трейсинг отлично существуют в симбиозе. При логировании можно всегда указывать trace_id, и в дальнейшем отображать и логи, и трейсы в одном интерфейсе. Будет наглядно видно, по каким компонентам системы прошёл запрос, и какие логи писали сервисы при обработке данного запроса.
Спасибо за интересный материал и хороший доклад. Многие из проблем откликаются, и многие выводы перекликаются с собственными мыслями :)
Трейсинг и логирование это немного разные инструменты, которые отлично работают в симбиозе друг с другом.
Как правило логи используют для того, чтобы сообщить о том, что случилось какое-то "специальное событие": ошибка / warning / etc. К этому событию прикрепляют какие-то полезные поля для его идентификации, некоторые атрибуты и понятное описание того, что случилось.
Трейсинг же можно использовать, чтобы отслеживать все точки системы, по которым прошёл запрос. И это очень удобно в большой распределенной архитектуре, когда один человек буквально не может разбираться в логике всех сервисов, присутствующих в системе. А ведь количество сервисов в системе может измеряться тысячами... можно представить, насколько много получится уникальных цепочек обработки запроса.
Зато этот человек может в тех же самых логах найти информацию о том, что его сервис отправил запрос в другой сервис, и в ответ получил какую-то ошибку. Он может посмотреть на ID этого запроса и отследить весь его путь. Увидеть, что запрос был отправлен из сервиса A в его сервис B, после чего было много обращений в сервис C, и дальнейшая обработка запроса по пути сервисов D -> E -> F -> ..., пока запрос не дошёл до субд, которая не смогла выполнить запрос, потому что в этот момент вышел из строя старый лидер субд.
Если в системе есть некоторый платформенный слой для проксирования всех запросов (например, запросы перехватываются с помощью прокси сайдкаров, устанавливаемых рядом с каждым сервисом), можно довольно дешёво начать отслеживать все трейсы в системе. И когда разработчики будут менять / добавлять новые обработчики запросов, им не придется думать о том, что нужно не забыть написать логи, чтобы можно было в дальнейшем отслеживать цепочки запросов. А если есть большое наследие, которое сделали 10 лет назад, и никто тогда не думал о том, чтобы нужно логировать что-то? Насколько дорого будет пойти и добавить везде логирование?
Логи пишут, когда разработчик решил, что в этом месте будет полезно что-то залогировать, чтобы иметь дополнительный контекст. Трейсинг спаны пишут всегда (по модулю семплирования).
Да, можно добавить логирование на прокси, обрабатывающих трафик, и сделать какие-то общие entry-point'ы в приложении, которые будут писать логи при поступлении нового запроса. Добавить в эти логи некоторый request_id, единый в рамках одного запроса, и начать прокидывать этот request_id. Подключить к этому всему сквозной поиск в системе по request_id и решить задачу с помощью логирования. Так действительно можно сделать, но в итоге получится, что вы переизобрели трейсинг.
Как уже было упомянуто, логи и трейсинг отлично существуют в симбиозе. При логировании можно всегда указывать trace_id, и в дальнейшем отображать и логи, и трейсы в одном интерфейсе. Будет наглядно видно, по каким компонентам системы прошёл запрос, и какие логи писали сервисы при обработке данного запроса.
Если асимптотика алгоритма O(n), то O(n^2) тоже является асимптотикой данного алгоритма.
Если рассматривать join, а не left join, то возможна же ситуация, когда этот
джоин даст в результате 0 записей. Хотя если убрать LIMIT 1, то записи найдутся.
Нам было по фану решать их все.