Когда логи кричат, а ты не слышишь: как я приводил логи в порядок в ETL‑коннекторе

[BogdanPetrov]

Лично я на практике скорее встречаюсь с проблемами от того, что в логах чего-то нет, чем от слишком раздутых логов. Как соотносится количество строк в логе с временем, затраченным на поиск ошибки (пишете, что полчаса ищете ошибку в логе на 15к строк) - непонятно. Про разные поля в логах и карту логов совсем не понял. Ощущение, что пытаетесь в логи перенести то, что должно жить в каких-то других форматах. Например, ошибки трансформаций не лучше было ли в какую-то служебную таблицу складывать для последующего разбора? Зачем это в логах? А количество таких ошибок - это уже метрика.

[LunarBirdMYT]

Сложность поиска поиска была в том, что одна и та же запись фигурировала на этапе запроса из бд, потом на этапе трансформации и потом при загрузке в api, что велось фактически в одном журнале логов простыми не формализованными строками. Параллельно в логи залетали ошибки о других записях, успешные запросы и всё намешивалось в кашу. Приходилось сначала отыскивать среди всех строк с ошибками искомую проблемную запись, а потом искать на каком этапе возникла проблема именно с этим объектом. Требованием было, чтобы загрузка не падала. Нет ключевого поля - допустим, идем дальше. Было бы логичным бросить исключение, если всё равно в итоге ни один объект не загрузится, но тз есть тз.

Понял, слишком скомкано получилось про карту и поля. Думал сначала раскрыть подробнее, потом показалось, что это получится либо слишком много, либо что-то уже само собой разумеющееся в отрасли, и я слишком подробно подхожу к этому. Спасибо за ваше мнение, учту это на будущее. Я постараюсь коротко передать идею. Карта логов - чтобы понять что, где и на каком уровне логируется и убедиться, что этого достаточно и хватает. Как вы сначала написали, что на практике часто скорее не хватает чего-то. Карта выступает в роли некоторого документа, который покажет без анализа всего кода проекта на каком этапе, в какой функции или методе, что логируется и для чего. По сути это таблицы с этапами и перечислениями каждого лога. Это позволяет увидеть, чего не хватает или что излишне. Нейминг поля описывает функцию и её проблему в общих чертах, типа короткого `transform.validation_error` или `extract.fetch_null`, в отдельные поля логгера передаются дополнительные атрибуты для разбора ошибки, если нужно (идентификатор конкретного объекта, предметной области в которой этот объект находится и т.п.). Это позволяет фильтровать ошибки по ключевым событиям, а не просто все `error` какой-то отдельной функции или содержащие какой-то текст.

Интересная идея на счет отдельной таблицы для трансформаций. Подумаю в эту сторону. Базовая задача была, что всё в одном месте - зашли в лог airflow и там сразу видно все ошибки, не нужно отдельно переходить в БД. Типа ошибка трансформации это отправляем тем, ошибка в каком-то поле самого объекта - другим. Пожелание от коллег было такое.