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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общий обзор

Flow map: Pinterest app to JSON logs batch to Logservice — a batch logging endpoint (/log) that handles perf logs, device info(Android) and new JSON log type to json messages to Singer to Pub/Sub with arrows to Logstash, Merced and Other analytics tools. Logstash goes to Open Search. Open Search goes to OpenSearch Dashboards and Metric generator to Statsboard. Merced goes to S3/Hive.
Архитектура конвейера логирования данных в Pinterest

Схема данных

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

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

{ “name” = “network_metrics”; //required, set by users “timestamp” = 2022121512345; //required, set by pipeline “metadata” = { //required, set by pipeline “app_version” = “8.40”; “os_version” = “14.0”; “device_model” = “IPHONE11,2; “build_type” = “Production” // “OTA”, “Development”, “Alpha”, etc “network_type” = “wifi” // or “cellular” “country” = “United States”; “platform” = “Android”; … }; “payload” = { // users reported payload will appear here }; };
Полезная нагрузка лога

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

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

Example on how to visualize network metrics in real-time with six separate graphics: mobile_json)log::platforms, mobile_networking::host, mobile_json_log::total_count_timeline, mobile_networking::req_num_by_ver, mobile_networking::request_latency, and mobile_networking::status.
Пример информационной панели с сетевыми логами, полученными от iOS- и Android-версий приложения

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

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

Example on how to create a log-based metric. “Succeeded. Metric Name: es.mobile_json.story_pin_by_event_type. Query Name: name: story_pin_creation_event AND metadata.build_type:Production. Index Name: mobile_json_log. Begin: -30mins. End: -5min. Term Aggs (optional) Field: payload.eventType.key. Tag Key: event_type. Size: 10. Order: desc. Field: metadata.platform.key. Tag Key: platform. Size: 10. Order: desc.”
Пример создания метрики, основанной на логах

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

Title of Tab: ES Mobile JSON Story Pin Event. sum_aggregator: zimsum:1m-avg-none. Two Stratsboards with red lines and dots titled “iOS story pin event SR” and “Android story pin event SR”.
Пример системы, выдающей оповещения в реальном времени, настроенной с использованием метрик, основанных на логах в Statsboard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О, а приходите к нам работать? ? ?

Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

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

Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.

Присоединяйтесь к нашей команде

Комментарии (1)


  1. VanKrock
    02.07.2024 13:00

    ClickHouse обычно используется для тех же целей вроде как, интересно как OpenSearch в сравнении с ClickHouse в работе с веб метриками