Мониторинг работоспособности источников логов с помощью SFM-событий

Материал из Документация Ключ-АСТРОМ

Мониторинг работоспособности источников логов с помощью SFM-событий

Версия ЕдиногоАгента 1.333+

Модуль логов обладает встроенной функцией самоконтроля и диагностики. Эта функция называется событиями самоконтроля модуля логов (SFM-события). Модуль логов предоставляет список мониторируемых источников логов вместе с их статусами и метаданными. Статус источника лога показывает, правильно ли обнаружен источник лога и настроена ли его загрузка, а также сообщает о типе источника (например, был ли источник лога обнаружен автоматически или предоставлен пользователем). Функция также предупреждает о подозрительных проблемах и неисправностях. В случае появления такой проблемы предоставляется контекст (например, имя источника лога или ID хоста) вместе с информацией о том, где найти дополнительную помощь и как изучить и решить проблему. Каждый тип неисправности сообщается с помощью определённого типа SFM-события.

Доступность и состояние

Функция общедоступна и включена по умолчанию в ЕдиномАгенте версии 1.339+ и SaaS версии 1.340+. Дополнительная нагрузка на производительность от этой функции незначительна.

Предварительные требования

  • Модуль логов развёрнут либо с помощью ЕдиногоАгента, либо с помощью Оператора.
  • Для доступа к полной функциональности SFM-события должны быть включены (см. раздел «Настройка SFM-событий через API»).

Настройка SFM-событий через API

SFM-события включены по умолчанию. Чтобы настроить эту функцию, обновите конфигурацию через API настроек. Используйте идентификатор схемы builtin:logmonitoring.log-sfm-settings. Если вы знакомы с настройкой правил загрузки логов, здесь применяется тот же рабочий процесс.

Предварительные требования для настройки SFM-событий

  • Токен доступа с разрешениями settings.write и settings.read.
  • API-клиент по вашему выбору (в примерах ниже используется cURL).

Области конфигурации

Вы можете настроить правила SFM-событий для следующих областей:

  • tenant: объект конфигурации влияет на все хосты в данной среде.
  • host_group: объект конфигурации влияет на все хосты, назначенные данной группе хостов.
  • kubernetes_cluster: объект конфигурации влияет только на данный кластер Kubernetes.
  • host: объект конфигурации влияет только на данный хост.

Рекомендуется настраивать правила SFM-событий на максимально широкой подходящей области для упрощения управления. Используйте меньше широких правил вместо множества мелких пересекающихся.

Исключение определённого типа SFM-события

Если вы включили все SFM-события, но нужно исключить определённый тип, создайте дополнительное правило исключения SFM-событий. Это правило исключения должно иметь более высокий приоритет, чем правило, включающее все SFM-события. Чтобы добавить правило исключения в начало списка правил, установите для параметра insertAfter пустое значение в полезной нагрузке. Если не включить параметр insertAfter, правило будет размещено в конце списка и может быть переопределено всеми другими правилами в данной области конфигурации.

Отключение определённого типа SFM-события

Чтобы отключить определённый тип SFM-события, добавьте новое правило с более высоким приоритетом, которое исключает этот тип события.

Категории SFM-событий

SFM-события делятся на две категории с разными объёмами и последствиями для стоимости.

  • События операционных проблем: timestamp.*, data_loss.*, ingest.* и pgi.*. Они предупреждают о реальных проблемах модуля логов, таких как потеря данных, отсутствующие шаблоны временных меток или заблокированные источники логов. Они генерируются только при возникновении проблемы, поэтому их объём обычно невелик.
  • События статуса источника лога: log_source.status. Они генерируются для каждого источника лога, известного модулю логов, включая работоспособные. Они предоставляют метаданные покрытия, такие как статус файла, статус загрузки и происхождение источника лога. Поскольку они генерируются для каждого источника лога в каждом цикле отчётности, они могут создавать значительно больший объём событий. Если вы хотите минимизировать затраты на загрузку, но при этом обнаруживать проблемы, включите только события операционных проблем, подавив log_source.status.

Влияние на путь данных и лимиты

После включения:

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

Запрос SFM-событий

В приложении «Логи» используйте атрибут event.type для фильтрации определённых SFM-событий. Чтобы найти все события потери данных:

event.type = "data_loss.network"

Чтобы найти события для конкретного источника лога:

event.type = "log_source.status" AND log.source = "/var/log/app.log"

Дополнительные атрибуты, доступные в SFM-событиях:

  • event.type: конкретный тип SFM-события, например data_loss.network или timestamp.no_pattern.
  • log.source: источник лога.

Обнаружение проблем с помощью предварительно настроенного дашборда

Ключ-АСТРОМ предоставляет предварительно настроенный дашборд для мониторинга работоспособности модулей логов и статусов обнаруженных источников логов. Дашборд также содержит ссылки на руководства по диагностике. Вы можете использовать его для быстрого обнаружения пробелов в сборе логов, диагностики проблем с парсингом и временными метками, а также для проверки того, что все необходимые источники логов мониторятся.

Дашборд Мониторинг работоспособности модулей логов доступен в разделе Дашборды > Готовые.

Типы SFM-событий

Полный список типов SFM-событий и их описаний см. в разделе Типы SFM-событий.

Источник — https://doc.ruscomtech.ru/index.php?title=Мониторинг_работоспособности_источников_логов_с_помощью_SFM-событий&oldid=7003