Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • N noc
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 446
    • Issues 446
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 29
    • Merge requests 29
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • noc
  • noc
  • Issues
  • #1593
Closed
Open
Issue created May 22, 2021 by Andrey Vertiprahov@aversantDeveloper

Структура для таблиц событий (Event) в Clickhouse

Проблема

На текущий момент для хранения событий FM (Event) используется коллекция Mongo и это влечёт за собой следующие расходы:

  • При значительном потоке событий отбирает ресурсы на расчёт индекса
  • Рост размера коллекции
  • Замедление работы классификатора, поскольку требуется ожидание вставки данных
  • Отдельный скрипт для очистки старых событий.

На текущий момент события имеют ценность в двух сценариях:

  • Как источник аварий. В этом случае они поступаются в коррелятор минуя базу.
  • Как возможность проведения аналитики по структурированным данным

В итоге может быть правильно отправлять их напрямую в аналитическую БД (Clickhouse) миную основную базу системы.

Предложение

Для описания способа хренения событий есть несколько вопросов:

  1. В событиях есть поля с переменными (vars). У Clickhouse есть необходимые функции для работы с JSON сохранённым как строка: Функции для работы с JSON. При необходимости развернуть Json в столбцы для удобства работы можно использовать View.
  2. В событиях есть поле repeat, фиксирующее число срабатываний RepeatSupression. Есть 2 варианта его конвертации:
    • Добавление поля RepeatHash. При выборках можно проводить по нему группировку
    • Писать отправлять события без учёта повторов, при необходимости подсчёта повторов делать группировку по интересующим полям
  3. Сохранение структуры EventLog. На текущий момент это поле используется в двух местах:
    • Добавление комментариев из интерфейса
    • Работа механизма RepeatSupression

Видимо, сохранять его в Clickhouse смысла нет.

Определить в Clickhouse таблицу для отправки в неё событий следующей со следующей структурой:

  • date (DateField)
  • ts (DateTimeField) - время регистрации события системой
  • start_ts (DateTimeField) - время начало события
  • event_id (StringField) - ID события
  • event_class (ReferenceField) - класс события
  • source (StringField) - источник события: syslog, SNMP Trap, system, other
  • raw_vars (MapField) - json поля raw_vars в текстовом представлении
  • repeat_hash (StringField) - подсчитанный hash повторов
  • resolved_vars - (StringField) - json поля resolved_vars в текстовом представлении
  • vars - (MapField) - json поля resolved_vars в текстовом представлении
  • managed_object (ReferenceField) - ссылка на устройство (ManagedObject)
  • pool (ReferenceField) - Пул
  • ip (IPv4Field) - IP адрес источника события
  • profile (ReferenceField) - Профиль SA
  • vendor (ReferenceField) - производитель
  • platform (ReferenceField) - платформа
  • version (ReferenceField) - версия
Edited Nov 27, 2022 by Andrey Vertiprahov
Assignee
Assign to
Time tracking