Оптимизация хранения логов и сокращение объёма сканируемых данных
Оптимизация хранения логов и сокращение объёма сканируемых данных
Хранилище данных способно сканировать петабайты данных логов с высокой производительностью. Однако чем больше вы сканируете, тем выше потребление запросов к логам. Это верно даже в том случае, если запрос не возвращает никаких данных, поскольку каждая просканированная запись лога вносит вклад в общий объём просканированных байтов. Следуйте этому руководству, чтобы сократить объём хранимых и сканируемых данных логов, сохраняя при этом ожидаемые результаты. В этом руководстве показано, как применить некоторые из лучших практик для управления логами и аналитики в реальном сценарии.
Для кого это руководство
Это руководство предназначено для администраторов Ключ-АСТРОМ, настраивающих мониторинг логов.
Что вы узнаете
Примените некоторые из лучших практик для управления логами и аналитики, чтобы оптимизировать хранение и сканирование логов. В этом руководстве вы узнаете, как:
- Настроить загрузку логов.
- Использовать выделенные бакеты логов.
- Фильтровать логи при загрузке.
- Настроить разрешения пользователей с помощью границ.
Предварительные требования
Вот несколько моментов, которые стоит продумать перед началом, чтобы составить эффективный план оптимизации логов в Ключ-АСТРОМ.
Понимание источников и объёмов загрузки логов
Разные источники используют разные способы отправки данных логов. Оценив ваш ежедневный объём загрузки, вы сможете лучше определиться с разделением и сегментацией данных. Подробнее о сборе и загрузке данных см. в разделе Загрузка логов.
Определение шаблонов использования, типов логов и потребностей в хранении
Классифицируйте свои данные логов и подумайте о требованиях соответствия и конфиденциальности.
Классификация: какие типы логов вы будете использовать? Распространённые типы логов:
- Логи приложений: часто используются, как правило, для устранения неполадок или оповещений.
- Логи аудита: должны храниться в течение длительного периода для выполнения требований соответствия. Они не используются регулярно, и обычно доступ к ним есть только у нескольких человек.
- Сетевые логи: могут быть логами вашего веб-сервера, CDN, сетевых устройств. Они имеют очень большой объём, поэтому их важно агрегировать. В основном они используются через дашборды и потенциально могут быть хорошими кандидатами для извлечения метрик на основе логов для экономичного мониторинга и оповещения.
- Другие типы логов: любые другие логи, создаваемые вашей системой, например используемые для устранения неполадок, расследований, дашбордов, бизнес-аналитики или автоматизации.
Соответствие: как долго вам нужно хранить логи? Срок хранения определяется на уровне бакета.
Конфиденциальность: есть ли особые требования, которые требуют маскирования данных? Вы можете маскировать данные при захвате с помощью ЕдиногоАгента или во время обработки при загрузке с помощью OpenPipeline.
Планирование бакетов и моделей разрешений
Хранилище данных организует данные в бакеты. Бакеты ведут себя как папки в файловой системе и предназначены для записей, которые следует обрабатывать вместе. Это могут быть, например, данные, которые:
- Имеют одинаковый срок хранения.
- Должны запрашиваться/анализироваться вместе.
- Доступны одной и той же группе пользователей.
- Обслуживают один и тот же вариант использования.
- Должны быть удалены одновременно.
Справочная информация
Предположим, что ваша организация уже подготовила план сегментации данных, но ещё ничего не настроила в Ключ-АСТРОМ. Ваша организация имеет две основные группы пользователей:
- Разработчики: отвечают за приложения электронной коммерции, работающие в Kubernetes и бессерверных функциях.
- Команда CloudsOps: отвечает за все облачные ресурсы, включая бессерверные функции и CDN.
- Команда платформы: отвечает за Kubernetes и On-Prem.
- Команда безопасности: отвечает за все логи аудита и безопасности.
Ключ-АСТРОМ загружает и хранит следующие типы данных логов, описанные в таблице ниже.
| Тип лога | Источник | Ежедневный объём загрузки | Имя бакета | Срок хранения | Ответственная группа пользователей |
|---|---|---|---|---|---|
| Инфраструктурные логи | Системные логи Kubernetes, мониторимые ЕдинымАгентом (journald) | 2 ТБ | infra_logs | 90 дней | Команда платформы |
| Логи приложений | Kubernetes, мониторимые ЕдинымАгентом | 2 ТБ | app_logs | 60 дней | Разработчики и команда платформы |
| Логи приложений | Бессерверные функции, мониторимые слоем бессерверных функций | 1 ТБ | app_logs | 60 дней | Разработчики и CloudOps |
| Логи доступа | Логи CDN, отправляемые через потоковую передачу | 3 ТБ | access_logs | 365 дней | CloudOps |
| Логи аудита | Логи аудита облачных ресурсов | 2 ГБ | audit_logs | 3650 дней (10 лет) | Команда безопасности |
Настройка загрузки логов и применение лучших практик
Сначала вам нужно настроить загрузку логов. После этого вы примените некоторые из лучших практик для управления логами и аналитики.
1. Настройте загрузку логов
Чтобы настроить загрузку логов, следуйте инструкциям в разделе Загрузка логов. По умолчанию все данные логов загружаются в бакет default_logs. В идеале, после того как вы внедрите все лучшие практики, только администраторы должны иметь доступ к этому бакету. Разрешения бакетов должны следовать принципу наименьших привилегий, при котором отдельные пользователи имеют доступ только к тем бакетам, которые им необходимы для запросов или визуализации.
2. Проверьте, что вы загружаете и храните данные логов
Существует два способа проверить, что данные загружаются и хранятся. Готовый дашборд Обзор загрузки логов, доступный в Дашбордах, позволяет проверить объёмы загруженных логов. Используйте Логи или Блокноты, чтобы получить логи из любого бакета и убедиться, что загруженные данные поступают правильно и выглядят как ожидалось. Выполните приведённый ниже запрос DQL.
fetch logs | filter dt.system.bucket == "default_logs"
Если вы не видите данных логов, см. раздел Устранение неполадок управления логами и аналитики для получения советов по диагностике.
3. Используйте выделенные бакеты
Этот шаг создаёт выделенный бакет для определённых данных. Чтобы создать бакет, перейдите в Настройки > Управление хранилищем и выберите + Бакет. Установите имя бакета и отображаемое имя. В этом примере установите оба значения равными access_logs. Установите срок хранения в днях. В этом примере установите срок 365 дней. Установите тип таблицы бакета. В этом примере установите тип logs. Необязательно: выберите Хранение с включёнными запросами и определите срок хранения включённых запросов. Подробнее о хранении с включёнными запросами см. в разделе Контроль затрат на запросы логов с помощью хранения с включёнными запросами. Выберите Создать, чтобы сохранить бакет.
4. Фильтруйте логи при загрузке
OpenPipeline обрабатывает загрузку логов из всех источников и позволяет выполнять обработку, преобразование и назначение бакетов до того, как логи будут сохранены в хранилище данных. В этом примере давайте использовать OpenPipeline для фильтрации логов при загрузке. Мы настроим пайплайн, который обрабатывает логи CDN и сохраняет их в бакете access_logs.
1. Настройте пайплайн
Перейдите в OpenPipeline и выберите Логи. На вкладке Пайплайны выберите + Пайплайн, чтобы создать новый пайплайн. Назовите пайплайн Логи CDN. Добавьте процессоры технологических пакетов.
- На вкладке Обработка выберите + Процессор > Технологический пакет.
- Откройте группу Облачные и выберите Общие облачные.
- Выберите Выбрать.
- Снова выберите + Процессор > Технологический пакет.
- Откройте группу Облачные и на этот раз выберите CDN.
- Выберите Выбрать.
- Выберите Сохранить, чтобы сохранить конфигурацию.
Получите ID пайплайна, который понадобится вам позже для фильтрации логов.
- На вкладке Пайплайны выберите пайплайн
Логи CDN. В зависимости от количества настроенных пайплайнов вам может потребоваться выбрать >, чтобы перейти на нужную страницу. - ID пайплайна отображается сразу под названием пайплайна. В нашем примере ID может быть
pipeline_cloud_cdn_logs_5498. - На вкладке Пайплайны выберите пайплайн.
2. Настройте динамическую маршрутизацию
Оставаясь в OpenPipeline, откройте вкладку Динамическая маршрутизация и выберите + Динамический маршрут.
- Введите имя.
- Установите условие сопоставления в
matchesValue(cloud.log_stream, "CDN_*"). - Используйте раскрывающееся меню, чтобы выбрать пайплайн
Логи CDN, который вы только что создали. - Выберите Добавить, чтобы создать динамический маршрут.
- Выберите Сохранить, чтобы сохранить изменения в таблице.
3. Проверьте загрузку
Чтобы проверить конфигурацию, перейдите в Логи или Блокноты и выполните следующий запрос. Это проверит, обрабатывает ли пайплайн последние загруженные логи.
fetch logs
| filter dt.openpipeline == {pipeline_cloud_cdn_logs_5498}
4. Назначьте логи бакету
Оставаясь в OpenPipeline, откройте вкладку Хранилище и выберите + Процессор > Назначение бакета. Установите имя бакета. В этом примере установите имя Логи доступа к облаку. Оставьте условие сопоставления установленным в true. В раскрывающемся меню Хранилище выберите бакет access_logs, который вы уже создали. Выберите Сохранить.
5. Настройте разрешения пользователей с помощью границ
Этот шаг предоставляет пользователям доступ только к определённым бакетам.
1. Создайте новую границу
Откройте Управление аккаунтом > Управление идентификацией и доступом > Управление политиками и выберите вкладку Границы. Выберите + Граница, чтобы создать новую границу.
- Введите имя границы. В этом примере используйте
access_log read. - Установите запрос границы. В этом примере используйте
storage:bucket-name = "access_logs";. - Введите имя границы. В этом примере используйте
access_log read. - Выберите Сохранить.
2. Создайте новую группу пользователей
Откройте Управление аккаунтом > Управление идентификацией и доступом > Управление группами. Выберите + Группа, чтобы создать новую группу. В этом примере назовите новую группу CloudOps. Выберите Создать, чтобы создать группу. Появится страница Просмотр группы. Выберите + Разрешение, чтобы добавить новое разрешение.
- Используйте раскрывающееся меню, чтобы выбрать разрешение Чтение логов.
- В разделе Область действия установите соответствующую область на уровне аккаунта или среды.
- В разделе Границы используйте раскрывающееся меню, чтобы выбрать границу
access_logs read, созданную ранее. - Выберите Сохранить.
3. Назначьте пользователей группе
Откройте Управление аккаунтом > Управление идентификацией и доступом > Управление пользователями. Для каждого пользователя, которого вы хотите назначить в группу CloudOps, выберите > Редактировать. Установите флажок рядом с группой CloudOps. Возможно, вам потребуется найти группу с помощью текстового поля Фильтр групп. Выберите Сохранить, чтобы сохранить назначение пользователя. Продолжите для всех остальных пользователей, как необходимо. Когда вы назначите всех соответствующих пользователей, вы можете закрыть окно или продолжить работу с Ключ-АСТРОМ.
Поздравляем!
Вы завершили это руководство. Теперь у вас эффективная настройка логов:
- Вы сократили объём данных, которые нужно сканировать, используя выделенные бакеты.
- Нерелевантные логи либо отправляются в другой бакет, либо удаляются.
- Ваши пользователи теперь имеют доступ только к соответствующим бакетам.