Умная обработка логов

Для диагностики приложения пишут журналы работы. Но для анализа недостаточно просто иметь такие журналы, их нужно хранить и удобно обрабатывать. Для этого журналы отправляют в системы хранения: Hadoop, ClickHouse, Elasticsearch или в специализированные облачные системы типа Cloud Logging.

Обычно приложения не пишут журналы работы в системы хранения напрямик, вместо этого они их отправляют тем или иным образом в промежуточные приложения-агрегаторы. Приложения-агрегаторы могут получать журналы, перехватывая stdout/stderr, читать файлы журналов с диска, получать их через syslog или по HTTP и еще множеством других способов.

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

Типовыми системами поставки журналов являются: fluentd, fluentbit, logstash, а также множество других.

Хотя приложения-агрегаторы могут записывать данные в системы хранения напрямик, для увеличения надежности данные отправляют сначала в промежуточный буфер (шину потоков данных, message broker) — Yandex Data Streams, а уже оттуда в системы хранения.

Часто логи содержат слишком много данных, либо данные, доступ к которым должен быть ограничен. Лишнюю или конфиденциальную информацию можно маскировать с помощью дополнительной обработки, например в Cloud Functions.

Преимущества

Надежность

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

Несколько систем хранения

Часто одни и те же журналы работы хранят сразу в нескольких системах хранения: в ClickHouse для быстрой аналитики и в Object Storage для долговременного хранения. Для этого приложения-агрегаторы можно настроить, чтобы они отправляли два потока данных: один в ClickHouse, а второй в Object Storage.

С помощью шин данных это можно решить проще: достаточно отправлять журнал один раз в шину, а уже оттуда внутри Yandex Cloud запустить два процесса переноса данных. Это же решение позволит в любой момент добавить третью систему хранения, например Greenplum® или Elasticsearch.

Подход с несколькими системами хранения очень удобен для соответствия compliance: ФЗ-152, PCI DSS и других — где нужно хранить журналы работы не менее года. В этом случае журналы работы за последний месяц для оперативного доступа можно отправлять в одну систему хранения, а данные для долгого хранения отправлять в «холодное» хранилище Object Storage.

Маскирование и обработка логов

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

Передаваемые журналы можно отправить в Cloud Functions, где выполнить маскирование или любую другую обработку передаваемых данных.

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

Настройка

Чтобы настроить умную обработку логов:

1. Создайте поток данных Data Streams.

2. Настройте агрегатор логов: fluentd или logstash или другой агрегатор с поддержкой Kinesis Data Streams API.

3. Настройте Yandex Data Transfer для передачи данных в выбранную систему хранения.

   Пример настройки поставки данных из Data Streams приведен в практическом руководстве по сохранению данных в ClickHouse.

4. Подключите произвольную функцию обработки данных к Yandex Data Transfer. Код функции приведен в примере.