Комментарии 9
Я могу показаться ретроградом и гегельянцем, но вот это:
[2019-03-18 22:48:32.999] canonical-log-line alloc_count=9123 auth_type=api_key database_queries=34 duration=0.009 http_method=POST http_path=/v1/charges http_status=200 key_id=mk_123 permissions_used=account_write rate_allowed=true rate_quota=100 rate_remaining=99 request_id=req_123 team=acquiring user_id=usr_123… подозрительно напоминает обычную метрику прома или VicMet
В целом структурированные логи — это хорошо, но не в виде знака "равно".
Вот логгируете вы имена пользователей. А тут приходит пользователь с именем "canonical-log-line alloc_count=9123", и что?
Да, это может быть проблемой, но пожалуй её можно решить. Как минимум валидация через google protobuf позволит не пропускать некорректные значения, а наличие ошибок валидации будет сигнализировать о проблемах либо в заполнении данных, либо в их парсинге.
Валидация отклонит такие данные. Валидация отклоняет валидные логи? Ой.
Правильно использовать структурированный формат данных. В котором содержимое поля может полностью напоминать запрос в СУБД, но СУБД это не волнует, потому что она знает, что это текст.
Валидация отклонит такие данные. Валидация отклоняет валидные логи? Ой.
Попробую объяснить подробнее то, что я имел в виду. Здесь же речь идёт про конвейер, каждая часть которого делают часть работы:
Сначала сервис/приложение пишет логи, в текст которых добавляются структурированные данные. Здесь задача положить так, чтобы это потом можно было вытащить.
Возможная проблема тут — это сформировать какую-то некорректную строку с какими-то лишними данными или без необходимых. Google protobuf тут позволяет проверить, а все ли данные есть. Если чего-то нет, то это не повод не писать логи совсем, а повод дать знать, что есть проблема в запаковке данных (бросить какую-то ошибку, записать специальное сообщение в лог или как-то иначе сигнализировать о проблеме).
В статье про это сказано так:
Наша реализация годами оттачивалась, чтобы канонические строки генерировались для каждого запроса даже при возникновении внутренних сбоев и неожиданном поведении.… Этот инструмент настолько важен для нас, что любые проблемы с ним должны максимально быстро устраняться (иначе реагирование на инциденты будет похоже на полёт вслепую).
В конце эти логи собираются со всех машин и загружаются в какое-то центральное хранилище (в статье сказано про Presto, Redshift и Kafka). И вот тут уже структурированные данные должны извлекаться из текста строк. Данные извлекаются, проверяются той же схемой Google protobuf и пишутся в хранилище распакованными. Если данные тут некорректны, то не получится их распаковать (а значит и записать) и об этой проблеме тоже нужно сигнализировать (т.к. проблема может быть не только в запаковке, но и при передаче "в центральную систему для поиска и анализа", например).
Понятно, что это всё мои догадки, построенные на базе статьи, а правду знает только её автор и его коллеги...
Почему бы не выводить логи в действительно структурированном формате? https://github.com/nin-jin/slides/blob/master/tree/readme.md#%D0%BB%D0%BE%D0%B3%D0%B8
Честно говоря, не знаю что ответить. В статье же рассказ о том, что использует конкретная компания. Плюс кажется, что тут немного разные задачи. По вашей ссылке — описание формата, который будет читаем и машиной, и человеком. В статье же не идет речи о чтении человеком сырых логов, а скорее о машинной их обработке...
Преднамеренная обфускация. Корысть в переводе.
Быстро и гибко настраиваем наблюдаемость с помощью канонических строк логов