Оптимизация производительности и затрат дашбордов, выполняющих запросы логов

Оптимизация производительности и затрат дашбордов, выполняющих запросы логов

Логи — это важный сигнал мониторинга. Многие команды создают собственные дашборды, которые полагаются на логи. Рассмотрим следующий дашборд, который анализирует логи ошибок, создаваемые рабочими нагрузками Kubernetes, работающими в пространстве имён.

Дашборд для анализа логов ошибок, создаваемых рабочими нагрузками Kubernetes в пространстве имён

Этот дашборд использует два типа запросов логов:

• Запросы, агрегирующие записи логов с помощью команды makeTimeseries.

fetch logs
| filter k8s.namespace.name == "obslab-log-problem-detection"
| filter status == "ERROR"
| makeTimeseries count = count()

• Запросы, агрегирующие записи логов с помощью команды summarize.

fetch logs
| filter k8s.namespace.name == "obslab-log-problem-detection"
| filter status == "ERROR"
| summarize count = count(), by: { k8s.deployment.name }
| sort count desc

• Запрос, извлекающий логи для получения записей логов в необработанном виде.

fetch logs
| filter k8s.namespace.name == "obslab-log-problem-detection"
| filter status == "ERROR"

Команда хочет узнать:

• Какие компоненты создают больше всего ошибок.
• Как ошибки распределены во времени.
• Каковы примеры записей.

В этом руководстве вы узнаете различные методы получения этой информации при одновременной оптимизации дашборда для производительности и затрат.

Как оптимизировать запросы

Давайте рассмотрим, что можно сделать для оптимизации различных типов запросов.

Преобразование запросов в метрики на основе логов

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

• Имя: errors in obslab-log-problem-detection
• Условие сопоставления: k8s.namespace.name == "obslab-log-problem-detection" AND status == "ERROR"
• Ключ метрики: log.k8s.obslab.errors
• Измерения: k8s.workload.name

Затем вам нужно скорректировать инструкцию DQL на плитке дашборда.

timeseries count = count(log.obslab.errors)

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

Не всегда возможно извлечь метрики из любого запроса DQL. Помните о кардинальности измерений и таких командах, как dedup или join. Если вы не можете извлечь метрики, вам нужно оптимизировать запрос DQL и конфигурацию дашборда.

Оптимизация запросов DQL, которые нельзя преобразовать в метрики

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

• Задать временной диапазон: выберите переключатель Пользовательский временной диапазон и выберите временной диапазон из раскрывающегося меню.
• Задать сегмент: выберите переключатель Пользовательские сегменты и выберите сегмент из раскрывающегося меню.
• Задать бакет: добавьте следующую строку в запрос DQL.

| filter dt.system.bucket == "default_logs"

Оптимизация порядка команд запроса

Глядя на наш запрос, мы также можем выполнить фильтрацию как можно раньше и задать поля.

fetch logs
| filter dt.system.bucket == "default_logs"
| filter k8s.namespace.name == "obslab-log-problem-detection"
| filter status == "ERROR"
| fields timestamp, content, k8s.workload.name

Если ваш вариант использования позволяет, вы также можете задать лимиты запроса. Прокрутите до Редактировать плитку > Лимиты запросов. Затем можно настроить:

• Лимит читаемых данных (ГБ).
• Лимит записей.
• Лимит размера результата (МБ).
• Выборка.

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

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

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

Настройка бакета для использования хранения с включёнными запросами

Если многие пользователи часто открывают дашборд и запрашивают более короткие временные диапазоны (данные, которым меньше 35 дней), рассмотрите возможность использования модели ценообразования «Хранение с включёнными запросами» и настройте соответствующие разрешения IAM. Подробные инструкции по настройке бакета см. в разделе Контроль затрат на запросы логов с помощью хранения с включёнными запросами.

Отключение автообновления

Когда ваш дашборд автоматически обновляется каждую минуту, выполняются все ваши запросы. Если вы используете запросы логов, с вас взимается плата за каждое выполнение. Рассмотрите возможность отключения функции автообновления через раскрывающееся меню, выбрав Выкл.

Заключение

Используя описанные выше методы, мы сократили объём сканируемых данных для 24-часового временного диапазона с 12,3 ГБ до 147 МБ. Ваши результаты могут отличаться.

Лучшие практики:

• Если возможно, используйте метрики на основе логов, как описано в разделе Настройка пользовательских оповещений на основе метрик, извлечённых из логов. Метрики работают быстрее, имеют более длительное и дешёвое хранение, запросы к метрикам не тарифицируются, вы можете удалить записи логов, contributing к метрике, и сэкономить на затратах на хранение, а также использовать метрики для оповещения. Для извлечения метрик используйте разбор строк логов и извлечение метрик с помощью OpenPipeline.
• Если ваш вариант использования требует, чтобы содержимое логов (или другие данные с высокой кардинальностью) отображалось на дашбордах, оптимизируйте ваши запросы DQL, задав временной диапазон, сегменты, бакеты, лимиты запросов и отключив автообновление.

Дополнительная литература

• Стратегии дашбордов логов
• Обработка логов, если вам нужно извлечь дополнительные атрибуты из логов.
• Замените команду PARSE в вашем запросе на правило обработки логов.
• Использование метрик логов для оповещения.