Умная обработка логов
Для диагностики приложения пишут журналы работы. Но для анализа недостаточно просто иметь такие журналы, их нужно хранить и удобно обрабатывать. Для этого журналы отправляют в системы хранения: 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, где выполнить маскирование или любую другую обработку передаваемых данных.
После обработки журналы работы можно отправить сразу в несколько систем назначения: журналы с маскированными персональными данными открыть всем сотрудникам, а полные журналы только администраторам.
Настройка
Чтобы настроить умную обработку логов:
-
Создайте поток данных Data Streams.
-
Настройте агрегатор логов: fluentd или logstash или другой агрегатор с поддержкой Kinesis Data Streams API.
-
Настройте Yandex Data Transfer для передачи данных в выбранную систему хранения.
Пример настройки поставки данных из Data Streams приведен в практическом руководстве по сохранению данных в ClickHouse®.
-
Подключите произвольную функцию обработки данных к Yandex Data Transfer. Код функции приведен в примере.
ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.