Лучшие практики управления логами и аналитики

Лучшие практики управления логами и аналитики

Эта страница содержит лучшие практики для управления логами и аналитики логов на базе Grail. После её прочтения вы будете знать, как оптимизировать хранение и сканирование логов, а значит — сократить расходы, не теряя ожидаемых результатов. Следуя этим практикам, вы сможете:

• Экономить время в будущем: эффективно использовать возможности и архитектуру платформы Ключ-АСТРОМ, применяя новые концепции, обеспечивая наилучший опыт аналитики и масштабируемость.
• Раскрыть ценность: получить наилучший пользовательский опыт работы с логами, оптимизируя производительность и стоимость запросов.
• Обеспечить безопасность по проекту: гарантировать соответствие требованиям и безопасность с первого дня.
• Избежать ограничений в будущем.

Чтобы узнать, как применить некоторые из этих практик в реальном сценарии, см. Оптимизация хранения логов и сокращение объёма сканируемых данных. Также рекомендуется ознакомиться с предварительными требованиями перед применением описанных практик. Дополнительно можно посмотреть записанный вебинар, где обсуждаются эти практики: Вебинар | Лучшие практики оптимизации производительности и затрат | Управление логами и аналитика.

Используйте выделенные бакеты

Используя выделенные бакеты для разделения данных, вы можете сократить объём данных, которые нужно сканировать для получения релевантных результатов. По умолчанию один запрос может сканировать до 500 ГБ данных. Но сколько записей логов это составляет?

• Если вы запрашиваете неоптимизированный бакет, который хранит 100 ТБ данных в день, 500 ГБ — это лишь несколько минут записей логов.
• Однако если вы оптимизировали стратегию бакетов и создали один бакет, выделенный для конкретного варианта использования или команды, он может хранить всего 2–3 ТБ записей логов в день. Те же 500 ГБ внезапно покрывают целых 12 часов данных логов в этом бакете.

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

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

Используйте бакет default_logs как площадку для экспериментов

По умолчанию все записи логов отправляются в бакет default_logs. Как только вы начнёте создавать другие бакеты, вы сможете направлять определённые записи логов в них. Тогда в бакете default_logs останутся только те записи, которые вы не направили в другой бакет. Обычно — но не всегда — это означает, что в default_logs находятся записи, которые вам не нужно сохранять. На этом этапе вы можете рассматривать бакет default_logs как площадку для экспериментов:

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

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

Оптимизируйте размер бакета

Для большинства вариантов использования старайтесь поддерживать объём ежедневно сохраняемых данных в одном бакете на уровне около 2–3 ТБ. Это особенно важно для часто запрашиваемых бакетов. (Однако обычно это невозможно для бакетов, используемых для соответствия требованиям, где вы, скорее всего, будете хранить петабайты записей логов в одном бакете.) Это поможет обеспечить наилучший пользовательский опыт и производительность, особенно если пользователи не следуют лучшим практикам DQL (например, не применяют конкретные фильтры по временным диапазонам или бакетам, или не увеличивают лимит объёма запроса с помощью параметра scanLimitGBytes).

Разделяйте бакеты по направлению бизнеса, а не по приложению

Разделяйте бакеты логов по направлению бизнеса, а не по отдельным приложениям. Слишком детальное разделение по приложениям может исчерпать лимит в 80 бакетов на среду, прежде чем у вас появится достаточно бакетов для бизнес-группировок. Примеры группировок по направлениям бизнеса:

• Логи приложений Kubernetes
• Логи выполнения Lambda
• Логи доступа CloudFront

Такой подход позволяет поддерживать управляемое количество бакетов, снижает операционные издержки и обеспечивает осмысленное разделение для управления доступом и распределения затрат. Если конкретному приложению внутри направления бизнеса требуется отдельная обработка — например, из-за требований соответствия или необычно высокого объёма — создайте для него выделенный бакет как исключение, а не как правило. Команды, мигрирующие из Splunk, часто пытаются воспроизвести подход «один индекс на приложение» с помощью бакетов Grail. Индексы Splunk и бакеты Grail служат похожим целям, но прямое сопоставление не всегда является правильным решением. Начните с группировок по направлениям бизнеса и добавляйте бакеты уровня приложения только там, где это оправдано объёмом или требованиями соответствия.

Цель: 1–3 ТБ/день на бакет

Проектируйте стратегию бакетов так, чтобы каждый бакет получал от 1 до 3 ТБ данных логов в день. Этот диапазон обеспечивает хороший баланс между производительностью запросов и стоимостью. Ключ-АСТРОМ применяет лимиты запросов по умолчанию, которые влияют на объём данных, сканируемых запросом:

• 500 ГБ сканируется на запрос
• 1 000 записей возвращается на результат
• 1 МБ — размер полезной нагрузки результата

При загрузке 1–3 ТБ/день на бакет запрос, сканирующий 500 ГБ, покрывает примерно 4–12 часов логов. Это полезный временной диапазон для большинства операционных запросов. При 100 ТБ/день в одном бакете те же 500 ГБ сканирования покрывают лишь несколько минут логов, что делает исторические запросы непрактичными без увеличения лимитов сканирования. Увеличить лимиты сканирования возможно, но это повышает как время выполнения запроса, так и стоимость DPS. Проектируйте стратегию бакетов так, чтобы лимитов по умолчанию было достаточно для наиболее распространённых шаблонов запросов.

Группируйте данные, которые запрашиваются вместе и имеют одинаковый срок хранения

Помещайте данные логов в один бакет, когда они соответствуют всем следующим условиям:

• Одинаковый срок хранения: данные, которые должны быть удалены одновременно, принадлежат одному бакету.
• Запрашиваются или анализируются вместе: данные, к которым обращается одна и та же группа пользователей или которые служат одному варианту использования, выигрывают от совместного размещения.
• Принадлежат одной команде или бизнес-функции: совместное размещение упрощает настройку управления доступом, поскольку одна политика бакета охватывает все соответствующие данные.

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

Используйте default_logs как catch-all или держите его пустым

Бакет default_logs должен выполнять одну из двух ролей:

• Catch-all: принимать весь трафик логов, не соответствующий определённому правилу маршрутизации, подобно тому, как почтовый ящик catch-all получает нефильтрованные сообщения. Это подходит, когда вы ожидаете небольшой, управляемый объём неклассифицированных логов.
• Пустой (околонулевой трафик): направлять весь трафик логов в именованные бакеты через OpenPipeline, поддерживая default_logs пустым. Этот подход даёт наибольший контроль над тем, куда попадают данные, и упрощает управление доступом.

Избегайте накопления в default_logs большого, растущего объёма смешанных данных логов. Как только бакет заполнится разнородными логами из множества источников, настройка управления доступом и оптимизация запросов станут значительно сложнее. Лимит в 80 бакетов на среду можно увеличить в зависимости от объёма загрузки, обратившись в команду вашего аккаунта Ключ-АСТРОМ. Запрашивайте увеличение только после того, как оценка объёма продемонстрирует, что текущего лимита действительно недостаточно для вашей стратегии бакетов, а не в качестве предосторожности.

Настройте сроки хранения бакетов

Вы можете установить разные сроки хранения для каждого бакета. Это позволяет оптимизировать бакеты для отдельных сроков хранения, соответствия требованиям и затрат. Например:

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

Записи логов можно хранить от одного дня до 10 лет. Срок хранения определяется при создании бакета и может быть перенастроен в любое время. Подробнее о сроках хранения см. Сроки хранения данных: управление логами и аналитика.

Фильтруйте логи при загрузке

Вы можете фильтровать логи так, чтобы нерелевантные логи либо отправлялись в другой бакет, либо удалялись. Для фильтрации логов при загрузке используйте либо OneAgent (см. Правила загрузки логов), либо OpenPipeline (см. Примеры обработки OpenPipeline).

Используйте фильтры бакетов

Фильтры бакетов похожи на разрешения на уровне запроса. Добавив фильтр бакета к запросу, вы можете ограничить запрос DQL сканированием одного бакета, независимо от того, к каким бакетам имеет доступ пользователь. Это сокращает объём сканируемых данных и связанные с этим затраты, особенно для запросов, используемых в автообновляемых дашбордах. Дополнительно можно использовать сегменты для удобной фильтрации по бакету, см. Сегментация логов по бакету. Подробнее о фильтрах бакетов см. Запрос и фильтрация логов.

Настройте разрешения доступа

По умолчанию запрос DQL сканирует все бакеты, к которым у пользователя есть доступ. Чтобы ограничить количество и типы бакетов, к которым у пользователя есть доступ, используйте политики IAM для настройки разрешений доступа на уровне отдельного бакета. Так вам не придётся определять фильтры бакетов вручную для каждого запроса. Границы политик в Ключ-АСТРОМ — это модульный и многоразовый способ определения условий доступа для разрешений на уровне ресурсов и записей. Они действуют как дополнительный уровень контроля, уточняя область разрешений, предоставленных политиками IAM, без необходимости создавать дополнительные специальные политики. Вынося условия доступа наружу, границы политик упрощают управление, обеспечивают единообразное применение и повышают масштабируемость в больших средах. Так вы можете назначать отдельные политики IAM нескольким бакетам одновременно. Подробнее о разрешениях доступа см. на следующей странице: [Разрешения доступа].

Используйте события и метрики на основе логов

Вы можете создавать события и метрики из записей логов. Чтобы преобразовать запросы логов в метрики на основе логов, см. Оптимизация производительности и затрат дашбордов, выполняющих запросы логов. После извлечения метрик вы можете удалить записи логов — это особенно полезно для агрегированной информации, где доступ к исходной записи не важен. Вы можете использовать события и метрики на основе логов для оповещений вместо запросов логов. Подробнее см. Настройка оповещений на основе событий, извлечённых из логов и Настройка пользовательских оповещений на основе метрик, извлечённых из логов.

Используйте приложения с логами в контексте

Некоторые приложения, например Kubernetes, позволяют видеть логи в контексте. Это позволяет сканировать только те логи, которые релевантны конкретному варианту использования. Подробнее см. Использование логов в контексте для устранения проблем Kubernetes (K8s). Просмотр логов в контексте с помощью приложений Ключ-АСТРОМ тарифицируется по нулевому тарифу и, следовательно, бесплатен. Это включает такие функции, как окружающие логи (просмотр связанных записей логов) и представления с детализацией, например переход из представления трассировки в представление топологии. Для ваших записей логов вы дополнительно можете использовать следующие приложения Ключ-АСТРОМ: [список приложений].

Следуйте лучшим практикам DQL

Поскольку для доступа к записям логов вы используете DQL, следуйте лучшим практикам DQL для создания оптимизированных запросов. Подробнее см. Лучшие практики DQL.

Отслеживайте внедрение и использование

Лучший способ узнать об использовании и внедрении — с помощью готовых дашбордов Ключ-АСТРОМ. Их можно найти в разделе Дашборды > Готовые.

• Обзор загрузки логов и Использование — логи
• Обзор использования OpenPipeline

Используйте дашборды, чтобы узнать больше о потреблении, объёмах загруженных и сохранённых данных, шаблонах запросов, использовании бакетов и многом другом.