Comments 13
А как быть с трейсами, когда много микросервисов их пишут и они начинают занимать огромное место?
А что еще интересного можно сделать через телеметрию чего нельзя сделать через обычные логи с метаданными? Я для себя увидел автоматическое добавление времени выполнения спана - это удобно. В остальном вроде все также. У меня логи пишутся в stdout, а оттуда собираются вектором и дальше уже отправляются на хранение. А в метаданных хранится и trace_id, и всякое другое.
мне, например, помогает анализировать информацию в разных срезах. Удобнее, чем 100 гб логов
Так логи же тоже могу иметь level=trace. И тогда пусть хоть 100гб будет. А из плюсов - нет дополнительного хранилища еще и для трейсов отдельно.
Я не про level. Я про, например, посмотреть что делал конкртеный пользователь перед тем, как возникла ошибка. Или там, посмотреть на происходящее с разной степенью детализации. Или проверить гипотезу, что ошибка какая-то возникает в определенном браузере.
Иными словами, анализировать логи в условной базе данных удобнее, чем в одном огромном файле без внутренней структуры.
Так ведь и я про то же, под логами с метаданными я имел в виду структурированный формат. Такие логи сохраняются в какой-то условный elastic, loki и т.п., а потом анализируются. Потому и пытаюсь понять, в чем отличие трейсинга от логирования, пока больше похоже на подмножество с более конкретной целью.
Трейсинг и логирование это немного разные инструменты, которые отлично работают в симбиозе друг с другом.
Как правило логи используют для того, чтобы сообщить о том, что случилось какое-то "специальное событие": ошибка / warning / etc. К этому событию прикрепляют какие-то полезные поля для его идентификации, некоторые атрибуты и понятное описание того, что случилось.
Трейсинг же можно использовать, чтобы отслеживать все точки системы, по которым прошёл запрос. И это очень удобно в большой распределенной архитектуре, когда один человек буквально не может разбираться в логике всех сервисов, присутствующих в системе. А ведь количество сервисов в системе может измеряться тысячами... можно представить, насколько много получится уникальных цепочек обработки запроса.
Зато этот человек может в тех же самых логах найти информацию о том, что его сервис отправил запрос в другой сервис, и в ответ получил какую-то ошибку. Он может посмотреть на ID этого запроса и отследить весь его путь. Увидеть, что запрос был отправлен из сервиса A в его сервис B, после чего было много обращений в сервис C, и дальнейшая обработка запроса по пути сервисов D -> E -> F -> ..., пока запрос не дошёл до субд, которая не смогла выполнить запрос, потому что в этот момент вышел из строя старый лидер субд.
Если в системе есть некоторый платформенный слой для проксирования всех запросов (например, запросы перехватываются с помощью прокси сайдкаров, устанавливаемых рядом с каждым сервисом), можно довольно дешёво начать отслеживать все трейсы в системе. И когда разработчики будут менять / добавлять новые обработчики запросов, им не придется думать о том, что нужно не забыть написать логи, чтобы можно было в дальнейшем отслеживать цепочки запросов. А если есть большое наследие, которое сделали 10 лет назад, и никто тогда не думал о том, чтобы нужно логировать что-то? Насколько дорого будет пойти и добавить везде логирование?
Логи пишут, когда разработчик решил, что в этом месте будет полезно что-то залогировать, чтобы иметь дополнительный контекст. Трейсинг спаны пишут всегда (по модулю семплирования).
Да, можно добавить логирование на прокси, обрабатывающих трафик, и сделать какие-то общие entry-point'ы в приложении, которые будут писать логи при поступлении нового запроса. Добавить в эти логи некоторый request_id, единый в рамках одного запроса, и начать прокидывать этот request_id. Подключить к этому всему сквозной поиск в системе по request_id и решить задачу с помощью логирования. Так действительно можно сделать, но в итоге получится, что вы переизобрели трейсинг.
Как уже было упомянуто, логи и трейсинг отлично существуют в симбиозе. При логировании можно всегда указывать trace_id, и в дальнейшем отображать и логи, и трейсы в одном интерфейсе. Будет наглядно видно, по каким компонентам системы прошёл запрос, и какие логи писали сервисы при обработке данного запроса.
У нас мы используем для этих целей логгер и эластик. Т.е. как пример прилетел запрос от пользовател,для него создаётся уникальный ID который прокидывается в контекст живущий пока идёт запрос, далее в коде мы просто логгируем события дописывая уникальный ID к каждой строке. Если нужно вызвать какой то ещё сервис уникальный ID прокидывается в запросе в виде заголовка и уже следующий сервис его использует. Позднее через filebeat или vector данные попадают в logstash и затем в эластик где индексируются и визуализируются через kibana. Т.е. зная например уникальный ID попавший в сентри вместе с ошибкой можно проследить весь путь запроса. Ах да и мы используем структурированные json строки для логов
Трейсинг в Go — это просто