Pinterest: разработка всеобъемлющей JSON-системы логирования для клиентских приложений

В начале 2020 года у приложения Pinterest для iOS часто возникала серьёзная проблема, связанная с нехваткой памяти (у нас есть материал об этом). Тогда мы поняли, что у нас нет ни достаточно подробных сведений о работе приложений, ни хорошей системы, позволяющей анализировать подобные сведения в целях мониторинга приложений и решения проблем.

Обзор существовавшей системы логирования

В то время на стороне клиента имелось несколько механизмов логирования, позволяющих анализировать то, что происходит с приложением во время работы:

• Контекстное логирование: эта система была создана в расчёте на логирование сведений о показах контента и обо всём, что связано с бизнес‑целями приложения. Она, кроме того, могла формировать отчёты по собранным данным. Соответствующая конечная точка имела огромную важность, она должна была нормально работать в жёстком временном режиме. Разработчикам нужно было самостоятельно задавать ключи, которые эта конечная точка потом принимала бы. Данные, не связанные с заранее заданными ключами, не обрабатывались. В некоторых компаниях это называется «логированием аналитических сведений».

• Логирование разных событий: эта система применялась для логирования в локальный файл, хранящийся на диске, или даже для отправки логов (сообщений об ошибках) в сервис для отслеживания сбоев приложения.

С этими механизмами были связаны следующие проблемы:

• Не все логи подпадали под одну из этих категорий, и программисты часто неправильно использовали определённые типы логирования.

• Ни один из этих инструментов не давал хорошего способа для визуализации или агрегирования данных. Например, разработчикам нужно было вносить изменения в код для получения информации, отвечающей на такой вопрос: «Как нужная метрика выглядит в приложении версии А, работающем на устройстве В, подключённом к сети типа С?».

• Не было системы, позволяющей легко, в реальном времени, мониторить логи, не говоря уже о системе, которая позволяла бы задавать оповещения, оперативно выдаваемые на основе неких собственных метрик, основанных на логах.

Цель создания новой системы

Мы решили создать систему непрерывного логирования, нечто вроде конвейера для работы с логами, обладающего следующими характеристиками:

• Он должен быть создан с учётом подхода, предусматривающего минимальные усилия, необходимые для его использования. А именно, содержимое логов должно формироваться без использования некоей схемы данных, это содержимое должно быть достаточно гибким. В сущности — речь идёт о данных, оформленных в виде пар ключ‑значение. Это — одна из причин, по которой мы называем новую систему «JSON‑логированием».

• Он должен быть подготовлен к работе с API логирования на каждой из используемых нами платформ.

• Программистам, при работе с конвейером логирования, не нужно лезть в серверные механизмы.

• Он должен содержать инструменты, позволяющие удобно строить запросы к логам и визуализировать данные.

• Он должен работать в режиме реального времени!

Принимая это во внимание, мы приняли следующие решения, касающиеся важнейших проектных характеристик будущей системы:

• Конечная точка сервиса логирования будет отвечать за проверку корректности логов, за их парсинг и обработку.

• Логи будут постоянно храниться в базе данных Apache Hive, а значит — при работе с ними можно будет пользоваться любыми запросами, основанными на SQL.

• Для всех логов, проходящих по конвейеру логирования, будут использоваться топики Kafka, содержащие один или несколько разделов.

• В систему будет интегрирован сервис OpenSearch (форк Elasticsearch и Kibana, созданный Amazon), играющий роль инструмента для визуализации данных и для выполнения запросов к данным в реальном времени.

• Система будет поддерживать удобный и простой в использовании механизм для создания оповещений, работающих в реальном времени, поддерживающий применение собственных метрик, основанных на логах.

Архитектура решения

Общий обзор

Схема данных

Та часть сервиса, которая интегрирована в клиентское приложение, предоставляет метаданные, а разработчику нужно лишь дать логу имя и сформировать полезную нагрузку — набор данных, включаемых в лог. Больше ничего делать не нужно.

Вот пример полезной нагрузки:

Визуализация данных и выполнение запросов

Визуализация логов в OpenSearch — это сравнительно простая задача, решению которой помогает руководство, подготовленное для пользователей конвейера логирования. Кроме того, разработчики, для работы с данными, могут использовать SQL и любые другие инструменты для выполнения запросов и визуализации данных, поддерживаемые конвейером.

Выдача оповещений в режиме реального времени

Метрики, основанные на логах — это эффективный механизм обобщения данных, поступающих в систему. При использовании этого механизма пользователи могут генерировать метрику логов COUNT, соответствующей запросу Lucene. Для более сложных случаев пользователи могут генерировать метрики на основе возможности OpenSearch, связанной с группировкой документов по некоему полю, что позволяет подробно рассматривать данные логов в разных измерениях.

Метрики, основанные на логах, можно использовать для создания информационных панелей и оповещений, выдаваемых в реальном времени.

Сценарии использования новой системы логирования

Так как описываемый конвейер логирования был создан без какого-либо реального внешнего давления, разработчики в инициативном порядке внедряют его, в основном, для решения следующих задач:

Получение сведений о клиентских приложениях

• Получение метрик, связанных с сетевой работой и со сбоями приложений. Это позволяет разработчикам лучше понимать то, как именно работают клиентские приложения, и получать клиентские сигналы, на основе которых формируется основная метрика Pinner Uptime.

• Сведения о производительности приложений, такие, как те, что предоставляет iOS MetricKit.

• Создание собственных систем сообщений об ошибках, в частности — об исключениях, о программных ошибках, о результатах проверки каких-либо условий. Ранее сообщения о подобных событиях либо не выдавались, либо выдавались, но так, что их неудобно было анализировать.

Получение сведений о работе продукта и его отдельных возможностей

• Некоторые продуктовые команды воспользовались этой системой для формирования сообщений, касающихся правильности работы отдельных возможностей продукта. Среди них, например, сведения о результатах создания пина. Это позволяет наблюдать за соотношением удачных и неудачных операций в реальном времени. Благодаря такому подходу часто удаётся обнаруживать проблемы гораздо раньше, чем при использовании обычных метрик, получаемых по данным, собранным за сутки. И это особенно полезно при возникновении проблем, которые системы мониторинга API обнаруживают не сразу.

Логирование сведений, необходимых разработчикам

• Разработчикам нравится использовать этот конвейер для того, чтобы наблюдать за некоей логикой или за некоей ветвью кода в продакшне. Благодаря этому они получают ответы на множество вопросов, на которые ничто, кроме данных, ответить не может. Среди этих вопросов, например, такие: «Запускается ли когда-либо этот код?», «Как часто это происходит?».

• Разработчики используют логирование в качестве инструмента, помогающего бороться со странными ошибками, которые очень сложно воспроизвести в локальном окружении. То же самое касается и решения проблем, возникающих лишь на устройствах определённых моделей, на определённых версиях ОС и в прочих подобных ситуациях.

Выдача оповещений в реальном времени

• Лёгкость создания отчётов и настройки оповещений привела к тому, что продуктовые команды часто используют новую систему только ради выдачи уведомлений в реальном времени.

О будущем системы логирования

Будущее рассмотренной здесь системы логирования видится в создании индексов подуровней по имени в OpenSearch, что может повысить производительность запросов и улучшить изоляцию логов. Кроме того, нуждается в исследовании функционал OpenSearch, касающийся выдачи оповещений.