Создание комплексной системы ведения JSON логов для клиентских приложений Pinterest

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

Состояние логов

В то время в клиентских приложениях было несколько способов логирования повседневной работы:

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

Проблемы

• Не все логи попадали в эти категории, и люди часто злоупотребляли определенными типами логирования.
• Ни один из этих инструментов не обеспечивал хорошего способа визуализации или агрегирования. Например, разработчикам необходимо было внести изменения в код, чтобы получить такую информацию — «как выглядит метрика в версии приложения A на устройстве B и в сети типа C».
• Не существовало системы, которая может легко отслеживать логи в режиме реального времени, не говоря уже о создании системы оповещения в реальном времени о пользовательских метриках на основе логов.

Цель

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

• Он построен на наименьшем сопротивлении: полезные данные логов не имеют схемы и являются гибкими, в основном это пары ключ-значение. Это одна из причин, по которой мы называем это JSON логированием.
• Он готов к использованию API-интерфейсов ведения логов на каждой платформе.
• Разработчикам не нужно трогать какие-либо бэкэнд-системы.
• Легко запрашивать и визуализировать логи.
• Работает в режиме реального времени!

С учетом этого были приняты следующие ключевые проектные решения:

• Конечная точка службы ведения логов будет выполнять валидацию, парсинг и обработку журналов.
• Логи будут храниться в улье, что позволит поддерживать любые запросы на основе SQL.
• Единая и общая тема Kafka будет использоваться для всех журналов, проходящих через этот конвейер.
• Он интегрирован с OpenSearch (форк Elasticsearch и Kibana от Amazon) в качестве инструмента визуализации и запросов в реальном времени.
• Будет легко настроить оповещения в режиме реального времени с помощью кастомных метрик  на основе логов.

Архитектура

На высоком уровне

Схема

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

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

Визуализация и запросы

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

Оповещения в режиме реального времени

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

Метрики на основе логов можно использовать для создания дашбордов и оповещений в реальном времени:

Примеры использования

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

Видимость клиентов

• Получение сетевых метрик и метрики сбоев, чтобы лучше понимать, как работают клиенты и передавать эти клиентские сигналы на стороне клиента в главную метрику Pinner Uptime.
• Анализ производительности, например на основе информации, предоставленной iOS MetricKit.
• Создание кастомных отчетов об ошибках, таких как исключения, программные ошибки и утверждения, которые ранее либо не сообщались, либо сообщались где-то и не имели хорошего инструмента для анализа.

Продукт/работа фич

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

Логи разработчиков

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

Оповещение в режиме реального времени

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

Будущее

• На стороне Opensearch мы хотим создать индексы подуровня по именам, что может повысить производительность запросов, а также лучше изолировать журналы.
• Хотим изучить функцию оповещения, предоставляемую Opensearch

Источник